The CIO's hardest decision of 2026 is not which model to standardize on. It is whether to let every team keep wiring up its own copilots, or to stand up one place where every agent is routed, governed, monitored and accounted for.
Model selection used to be the architecture question. Now it is a purchasing detail. The real architecture question is the control plane: the layer between what the company knows and what it does. Almost no CIO has finished building it.
The reason is structural:
- Frontier models are converging with every release, and prices are falling the way they do for any commodity.
- Any advantage from picking a model is temporary, because the gap closes before the integration work pays back.
- So the model is the one part of the stack a CIO should deliberately not bet on. Bet on it and you rebuild the workflow every time the market moves. Keep it swappable, and falling prices work for you instead of against you.
Working with any model is the only position that lasts
In an architecture that works with any model, the provider is a swappable input:
- Each task goes to the cheapest model that clears its quality bar.
- A higher-stakes task goes to a stronger one.
- A data-residency rule sends a task to a model that meets it.
When a provider ships something cheaper or better, you change a routing rule, not a workflow. The model becomes a dial. What you build and own (the routing, the tools, the policies, the evidence) is the part that compounds.
Most companies have this backwards. They spend months choosing a model and wire it into their applications, then find the choice is out of date two releases later and the integration is holding everything up. The harness turns that around: the model is disposable, the control plane is the asset.
The control plane is seven building blocks
Put these seven layers in place and an agent has somewhere safe to run. Skip any one and you have a demo, not a capability you can deploy.
| Layer | Purpose |
|---|---|
| Model gateway | One front door to every provider. Route each call by cost, speed, capability, risk tier and client preference, and switch providers without touching the workflow. |
| Tool registry | Register every tool, MCP server, API and data product the company exposes, with its permissions and audit requirements attached. |
| Policy engine | Write down the rules as rules: human-approval requirements, restricted actions, data-sensitivity classes, role-based access, segregation of duties and materiality thresholds. |
| Approval service | Send a material action to a person to approve, reject, change or escalate before it commits. |
| Evidence ledger | Record the prompt, sources, retrieved context, tool calls, approvals, outputs and model versions for every run. |
| Observability | Trace each run: speed, cost, failure rate, how often people accept or override it, and policy exceptions. |
| Value telemetry | Attribute the impact on revenue, margin, working capital, productivity and risk, by agent and by process. |
Read the layers in three groups:
- The first two make an agent able to act.
- The middle three make it safe to act.
- The last two make its actions visible to the CFO funding it and the auditor signing off on it.
A control plane with the first two and not the other five is exactly the trap most companies are in: agents that can do things, with no governed way to let them.
MCP is the plumbing; the registry is the discipline
The Model Context Protocol (MCP), the open standard that connects assistants to tools, data and code repositories, is becoming the standard plumbing of the agentic company. That is good news and a hazard at once.
- The good news: MCP makes it easy for any team to connect any agent to any system.
- The hazard: left ungoverned, that is exactly how sprawl spreads. Dozens of MCP connections get wired up ad hoc, each with its own permissions, none visible to security or audit.
The discipline is to govern MCP through the tool registry, not team by team. Every MCP server is registered once, with its permissions and audit requirements declared, and agents reach it only through that governed entry, never through a connection a developer pasted into a notebook.
Five principles that hold under pressure
A control plane is only as good as the rules it enforces when a team is in a hurry to ship. Five hold:
- Works with any model: no workflow is tied to a single provider; routing is a rule, not an integration.
- Evidence first: if a run left no evidence record, it did not happen in a way the company can defend.
- Policy-driven: what an agent may do is written in the policy engine, not kept in the heads of the team that built it.
- Observable: every run can be traced on cost, quality and exceptions, or it is not in production.
- A person is accountable: a named person owns each agent's results, and material actions clear an approval before they commit.
None of these is exotic. They are the same disciplines enterprise architecture already applies to data, identity and change management, extended to a new kind of actor that reasons and acts for the company.
The failure mode has a name: agent sprawl
The alternative to a control plane is not having no agents. It is agent sprawl: every team standing up its own copilots, tool connections, prompts and scripts, with nothing shared underneath. The costs pile up:
- Spend is duplicated as teams buy overlapping tools.
- Quality drifts because no two agents are tested the same way.
- Ownership blurs until no one can say who is accountable when an agent moves money or sends a customer the wrong thing.
- The security exposure grows unseen, one ungoverned MCP connection at a time.
Sprawl is what happens by default when the CIO treats agents as a thousand local tooling decisions instead of a portfolio that needs a control plane. You do not fix sprawl with a policy memo. You fix it by making every agent run through the seven building blocks to reach production.
The CIO's job has moved up the stack. It is no longer to choose the intelligence; that is increasingly a commodity, and choosing it is a routing rule. It is to build the platform on which intelligence acts safely, owned by the company and indifferent to which model is winning this quarter.
This is the fourth essay in the eight-part series The Harness Era. The full-length analysis, with the build order for each building block, the MCP governance pattern and the economics of sprawl, is linked below. The next piece moves from architecture to operation: From AI News to AI Action, on how the news that reaches a CIO becomes a governed agent that does something about it.