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, picking the model: choose the platform, standardize on it, integrate it. That job is ending. Frontier capability is converging and becoming a commodity, and any architecture whose advantage depends on which model it picked is living on borrowed time. The lasting work has moved one layer out, to the control plane that sits between what the company knows and what it does.
This is the long-form case behind the series' fourth entry. It argues that the CIO's job is now to stand up an agent control plane that:
- works with any model,
- is driven by policy,
- can be observed, and
- connects through governed tools.
It also argues that the layers of that control plane are no longer experiments but standard enterprise architecture. It names the seven layers, the connection standard, the principles, and the failure they exist to prevent.
1. Why picking the model stopped being the architecture question
Three facts make the model layer the wrong place to anchor an architecture.
- Capability converges. The gap between frontier providers narrows with every release. Something that was one vendor's edge for a quarter is standard across all of them by the next. An architecture tuned to one model's strength is tuned to an advantage that fades fast.
- Prices fall. Token prices follow the curve every commodity input has followed: down, and steeply. A cost 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 only expensive if you let it be. The cost of moving between models is not built into the models. It depends on how tightly the workflow is wired to one. Hard-wire a provider into applications and a swap becomes a re-engineering project. Put it behind a gateway and a swap becomes a configuration change.
Taken together, these point to something specific. The model is a fast-moving input that keeps converging and getting cheaper, and the only way to benefit from that, rather than be stranded by it, is to refuse to bet the architecture on any one model.
- 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. Working with any model, in practice
"Model-agnostic" is not a slogan about vendor neutrality. It is a specific behavior at runtime: every model call passes through a gateway that picks the provider for each task, and no workflow refers to a specific model directly.
In practice the gateway routes on five factors:
- Cost: send the task to the cheapest model that clears its quality bar. Most company tasks do not need the frontier, and sending them there is a recurring overpayment.
- Latency: an interactive task and a batch task tolerate different delays, so route them differently.
- 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 rule can require a specific provider or region, handled 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 every agent benefits at once. No application is rewritten and no integration is reopened.
- What the company builds and maintains: the routing, the tools, the policies and the evidence.
- What it deliberately does not own: the model, because owning it means owning a depreciating asset.
This reverses the common approach. Most companies spent the last cycle choosing a model and embedding it, and now carry integration debt tied to a choice that has aged out. The harness treats the model as replaceable and the control plane as the asset. That is the whole shift in one sentence.
3. The seven layers of the control plane
A control plane is the set of layers every agent passes through to reach production. It has seven. Each has one job, and the value of the set is that no agent can skip any of them on its way to acting for the company.
| 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 fall into three jobs:
- The gateway and the registry make an agent able to act. They give it models and tools through governed entry points.
- The policy engine, the approval service and the evidence ledger make it safe to act. They limit what it may do, put a human in where one is required and record what happened.
- Observability and value telemetry make the action visible to the CIO who keeps it healthy, the CFO who funds it and the auditor who signs off on it.
What this reveals is blunt. Most companies 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-tracked way to let those agents act in production. That is why pilots stall on the way to deployment. The missing five layers are not optional polish. They are the difference between something that can act and something the company is willing to let act.
4. MCP is the connection standard; govern it through the registry
The Model Context Protocol is quickly 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 how agents will reach the company's systems. Standardizing the connection layer genuinely helps, because the registry has one protocol to govern instead of a dozen custom connectors.
It is also where sprawl gets in. MCP drops the cost of connecting an agent to a system to nearly zero, so any developer on any team can wire any agent to any data source in an afternoon.
- Each connection is a permission surface and an audit obligation.
- Done ad hoc, team by team, the company piles up dozens of ungoverned connections that security cannot see and audit cannot reconstruct.
- It is the classic shadow-IT failure, run again with agents that act rather than just 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 point, not through a connection a developer pasted into code.
The protocol is open and connecting is cheap, but the governance is centralized. MCP is the connection standard; the registry is the control point that keeps it from becoming the next source of sprawl. A CIO who adopts MCP without the registry has simply made sprawl faster to create.
5. The five architecture principles
The layers describe what to build. The principles describe what the build must enforce when a team is on a deadline and tempted to route around it. Five hold under that pressure.
- Works with any model. No workflow is tied to a single provider. Routing is a rule in the gateway, not an integration in an application. Converging models and falling prices become the company's advantage rather than a risk of being stranded.
- Evidence first. A run that left no evidence record did not happen in a way the company can defend. The ledger is not an afterthought logged for compliance; it is the condition for an action to count at all. Build it first, not after the first incident.
- Driven by policy. What an agent may do lives in the policy engine as rules: which actions are restricted, what data it may touch, where a human must approve, and what materiality threshold triggers escalation. 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 can be traced 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.
- Accountable to a person. A named person owns each agent's outcomes, and material actions clear an approval before they commit. Accountability does not pass to the model or the vendor. It stays with a human the company can name.
None of these is new to enterprise architecture. They are the disciplines already applied to identity, data governance and change management, extended to a new kind of actor: one that reasons and acts, not just stores or serves. The CIO's job is not to invent new governance. It is to recognize that an agent is an actor and extend the governance the company already trusts to something that now acts.
6. The failure: agent sprawl
The alternative to a control plane is not a company with fewer agents. It is a company with the same agents and no shared layer underneath them. That is agent sprawl, the default state any company drifts into without deliberate architecture.
Sprawl shows up as four costs:
- Duplicate spend. Teams separately buy or build overlapping capabilities (three copilots doing 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 tested the same way, so quality is uneven and unknowable. There is no shared test, no shared bar and 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 disappeared the moment the agent was stood up outside any shared layer.
- A growing, invisible security surface. Every ad hoc tool connection, and more and more every ungoverned MCP server, is a permission surface security never reviewed and audit cannot reconstruct.
Sprawl is not a discipline problem you solve with a memo about good habits. It is an architecture gap, and only architecture fills it. Moving 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.
- Send every material action through the approval service.
- Record every run in the evidence ledger.
- Trace every run in observability.
- Attach value telemetry to every agent.
An agent that cannot pass through those seven layers does not reach production. That one gate is what turns a thousand local tool decisions into a portfolio.
7. What the CIO should do now
The job has moved up the stack, and the order of work follows from the layers:
- Stand up the gateway first. It is the cheapest layer to deliver. It ends model lock-in right away and starts the cost routing that pays for the rest.
- Stand up the registry next, and make registration the only approved way to expose a tool or an MCP server, so sprawl has nowhere to start.
- Then the policy engine and the approval service, so the first agent to take a material action does it under rules and with a human in the loop.
- Then the evidence ledger and observability, without which nothing in production can be defended.
- 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 layer pays for itself the day it ships:
- the gateway in routed cost,
- the registry in visibility,
- the policy engine in safe autonomy, and
- the ledger in auditability.
The CIO who builds it spends 2026 building an owned, governed estate that compounds, 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: working with any model, evidence first, driven by policy, observable and accountable to a person. It is the one part of the agent-run company that the CIO both owns and can defend, whichever provider is winning this quarter.