The model is the part of the AI stack a CIO should refuse to bet on. It is the most powerful component and the least defensible — interchangeable with a competitor's by the end of the quarter, cheaper next quarter, and stronger the quarter after that on terms available to everyone. For a decade the CIO's AI job was, in effect, model selection: pick the platform, standardize on it, integrate it. That job is ending. Frontier capability is converging and commoditizing, and any architecture whose advantage depends on which model it picked is borrowing time it has not earned. The durable work has moved one layer out — to the control plane that sits between enterprise intelligence and enterprise action.
This is the long-form case behind the series' fourth entry. It argues that the CIO's mandate is now to stand up an agent control plane that is model-agnostic, policy-driven, observable, and integrated through governed tools — and that the primitives of that plane are no longer science projects but enterprise-architecture standards. It names the seven primitives, the integration substrate, the principles, and the failure mode they exist to prevent.
1. Why model selection stopped being the architecture question
Three facts about the model layer make it the wrong place to anchor an architecture.
Capability converges. The gap between frontier providers narrows with each release. A capability that was a single vendor's moat for one quarter is table stakes across all of them by the next. An architecture tuned to one model's particular strength is tuned to an advantage with a short half-life.
Price falls. Token prices follow the curve every commoditizing input has followed — down and to the right, steeply. A cost-based reason to standardize on one provider is undone by the next price cut, which may come from the provider you did not pick.
Switching is expensive only if you let it be. The cost of moving between models is not inherent to the models; it is a function of how tightly the workflow is wired to one. Hard-wire a provider into applications and a swap is a re-engineering project. Abstract it behind a gateway and a swap is a configuration change.
Put together, these say something specific: the model is a fast-moving, converging, cheapening input, and the only way to benefit from that motion rather than be stranded by it is to refuse to bet the architecture on any single instance of it. The CIO who spends 2026 running a model bake-off is optimizing the one layer that will be a commodity before the integration pays back. The CIO who spends 2026 building the layer that makes the model swappable is building the part that compounds.
2. Model-agnostic, defined operationally
Model-agnostic is not a slogan about vendor neutrality. It is a concrete runtime behavior: every model call passes through a gateway that selects the provider per task, and no workflow contains a hard reference to a specific model.
In practice the gateway routes on five axes:
- Cost — send the task to the cheapest model that clears its quality bar. Most enterprise tasks do not need the frontier; routing them to it is a recurring overpayment.
- Latency — an interactive task and a batch task have different tolerances; route accordingly.
- Capability — a task that genuinely needs frontier reasoning gets it; the rest do not.
- Risk tier — a high-materiality action can be pinned to a model with the required assurances, or routed for stronger review.
- Client preference — a regulated client or a data-residency constraint can require a specific provider or region, satisfied by a routing rule rather than a separate codebase.
The payoff is that the model becomes a dial. When a provider ships a cheaper tier or a stronger model, the CIO changes a routing rule and the entire estate benefits at once — no application is rewritten, no integration is reopened. The engineering the enterprise owns and maintains is the routing, the tools, the policies, and the evidence. The model is the one thing it deliberately does not own, because owning it is owning a depreciating asset.
This inverts the common posture. Most enterprises spent the last cycle selecting a model and embedding it, and now carry integration debt to a choice that aged out. The harness treats the model as disposable and the control plane as the asset. That is the whole shift in one sentence.
3. The seven control-plane primitives
A control plane is the set of layers every agent runs through to reach production. Seven primitives compose it. Each has a single job, and the value of the set is that no agent can skip any of them on its way to acting on the enterprise's behalf.
| Layer | Purpose | What it prevents |
|---|---|---|
| Model gateway | Provider abstraction; route each call by cost, latency, capability, risk tier, and client preference; swap providers without touching the workflow. | Lock-in to a depreciating model; rewriting workflows when the frontier moves. |
| Tool registry | Register every tool, MCP server, API, and data product, with the permissions and audit requirements attached to each. | Ad hoc, invisible integrations; permission surfaces no one is tracking. |
| Policy engine | Encode human-approval rules, restricted actions, data-sensitivity classes, RBAC, segregation of duties, and materiality thresholds as rules. | Governance living in the heads of the team that built an agent. |
| Approval service | Route a material action to a human to approve, reject, modify, or escalate before it commits. | Autonomous action on irreversible or high-materiality steps with no human in the loop. |
| Evidence ledger | Capture the prompt, sources, retrieved context, tool calls, approvals, outputs, and model versions for every run. | Unauditable actions; an inability to reconstruct what an agent did and why. |
| Observability | Trace each run on latency, cost, failure rate, acceptance and override rate, and policy exceptions. | Silent quality drift; spend with no attribution; exceptions no one sees. |
| Value telemetry | Attribute revenue, margin, working capital, productivity, and risk impact by agent and by process. | Agents measured by usage instead of outcome; budgets that cannot be defended. |
The seven sort into three jobs. The gateway and registry make an agent able to act — they give it models and tools through governed entry points. The policy engine, approval service, and evidence ledger make it safe to act — they bound what it may do, insert a human where one is required, and record what happened. The observability and value telemetry layers make the action legible — to the CIO who must keep it healthy, the CFO who funds it, and the auditor who signs off on it.
The diagnostic this enables is blunt. Most enterprises have built the first job and skipped the second and third: they have agents that can reach models and tools, and no governed, evidence-producing, value-attributed way to let those agents act in production. That is why pilots stall on the way to deployment. The missing five primitives are not optional polish; they are the difference between a thing that can act and a thing the enterprise is willing to let act.
4. MCP is the integration substrate — govern it through the registry
The Model Context Protocol is rapidly becoming the open standard that connects assistants to tools, data products, and code repositories. It matters to the control plane for one reason: it is the substrate through which agents will reach the enterprise's systems. Standardizing the integration layer is genuinely useful — it means the registry has one protocol to govern rather than a dozen bespoke connectors.
It is also where sprawl enters. MCP lowers the cost of connecting an agent to a system to nearly zero, which means any developer on any team can wire any agent to any data source in an afternoon. Each such connection is a permission surface and an audit obligation. Do it ad hoc, per team, and the enterprise accumulates dozens of ungoverned integrations that security cannot see and audit cannot reconstruct — the classic shadow-IT failure, re-run with agents that act rather than merely read.
The discipline is to route every MCP server through the tool registry. A server is registered once, with its scope, permissions, and audit requirements declared at registration. Agents reach it through that governed entry, not through a connection a developer pasted into code. The protocol is open and the connection is cheap, but the governance is centralized. MCP is the substrate; the registry is the control point that keeps the substrate from becoming the next sprawl vector. A CIO who adopts MCP without the registry has simply made sprawl faster to create.
5. The five architecture principles
Primitives describe what to build. Principles describe what the build must enforce when a team is under deadline pressure and tempted to route around it. Five hold under that pressure.
Model-agnostic. No workflow is bound to a single provider. Routing is a rule in the gateway, not an integration in an application. Convergence and price cuts become the enterprise's advantage rather than its stranding risk.
Evidence-first. A run that produced no evidence record did not happen in a way the enterprise can defend. The ledger is not an afterthought logged for compliance; it is the condition of an action counting at all. Build it first, not after the first incident.
Policy-driven. What an agent may do — which actions are restricted, what data it may touch, where a human must approve, what materiality threshold triggers escalation — lives in the policy engine as rules. It does not live in the judgment of the team that shipped the agent, because that judgment does not scale and cannot be audited.
Observable. Every agent in production is traceable on cost, quality, acceptance, override, and policy exceptions. An agent you cannot observe is an agent you cannot govern, and an agent you cannot govern does not belong in production.
Human-accountable. A named person owns each agent's outcomes, and material actions clear an approval before they commit. Accountability does not transfer to the model or the vendor; it stays with a human the enterprise can name.
None of these is novel to enterprise architecture. They are the disciplines already applied to identity, data governance, and change management, extended to a new class of actor — one that reasons and takes action, not merely stores or serves. The CIO's task is not to invent new governance. It is to recognize that an agent is an actor and to extend the governance an enterprise already trusts to a thing that now acts.
6. The failure mode: agent sprawl
The alternative to a control plane is not an enterprise with fewer agents. It is an enterprise with the same agents and no common layer beneath them — agent sprawl, the default state any enterprise drifts into without deliberate architecture.
Sprawl shows up as four costs:
- Duplicated spend. Teams independently buy or build overlapping capabilities — three copilots that do the same thing, each with its own contract and its own integration — because no one can see what already exists.
- Drifting quality. No two agents are evaluated the same way, so quality is uneven and unknowable. There is no shared eval, no shared bar, no way to compare.
- Blurred ownership. When an agent moves money, sends a customer the wrong message, or takes an action it should have escalated, no one can say who owned the outcome. Accountability dissolved the moment the agent was stood up outside any common layer.
- An expanding, invisible security surface. Every ad hoc tool connection — increasingly, every ungoverned MCP server — is a permission surface security never reviewed and audit cannot reconstruct.
Sprawl is not a discipline problem to be solved with a memo about best practices. It is an architecture vacuum, and the only thing that fills it is architecture. The conversion from sprawl to a managed estate is mechanical: route every agent through the gateway, register every tool and MCP server in the registry, encode every rule in the policy engine, gate every material action through the approval service, record every run in the evidence ledger, trace every run in observability, and attach value telemetry to every agent. An agent that cannot pass through those seven primitives does not reach production. That single gate is what turns a thousand local tooling decisions into a portfolio.
7. What the CIO should do now
The mandate has moved up the stack, and the work order follows from the primitives. Stand up the gateway first — it is the cheapest primitive to deliver and it immediately ends model lock-in and starts the cost routing that pays for the rest. Stand up the registry next, and make registration the only sanctioned way to expose a tool or an MCP server, so sprawl has nowhere to start. Then the policy engine and approval service, so the first agent to take a material action does so under rules and with a human in the loop. Then the evidence ledger and observability, without which nothing in production is defensible. Value telemetry closes the loop back to the CFO, who funds the next agent against the proven impact of the last.
Done in that order, the control plane is not a platform program that delivers value in eighteen months. Each primitive earns its keep the day it ships — the gateway in routed cost, the registry in visibility, the policy engine in safe autonomy, the ledger in auditability. The CIO who builds it spends 2026 compounding an owned, governed estate while peers are still running model bake-offs on a layer that will be a commodity before the comparison finishes.
The model was never the architecture. The control plane is — model-agnostic, evidence-first, policy-driven, observable, human-accountable — and it is the one part of the agentic enterprise the CIO both owns and can defend, indifferent to which provider is winning this quarter.