What an AI Agent Control Plane Actually Does

What an AI Agent Control Plane Actually Does

There is a moment in almost every agent project where the demo looks brilliant and the roadmap looks doomed at the same time.

The demo works because someone asked the agent one clean question and it did one clean thing. The roadmap looks doomed because everyone in the room quietly knows the real job is not one question. It is twenty steps, across half a dozen systems, on behalf of a real customer, with money and permissions and other agents all in play at once. And nobody is quite sure what the agent will do when all of that arrives together.

That gap between the demo and the real work is not a model problem. Bigger models do not close it. It is an infrastructure problem, and it lives in the space between the agent deciding to act and the action actually happening. That space is what a control plane governs. Here is what it has to do.

1. Work out what is actually being asked, and who wins when requests collide

Start with the problem nobody plans for: two agents wanting different things at the same time.

A customer's agent wants the cheapest available room. Your revenue agent wants to protect margin on the last few. An internal operations agent is halfway through re-pricing the same inventory. Three perfectly reasonable requests, one system, and no obvious winner. Most setups have no answer to this. They let whoever calls first act, and hope the others sort themselves out.

The first job of a control plane is intent arbitration: understanding what each request is really asking for, deciding whose request takes priority, and resolving the collision against your rules before anything executes. This is unglamorous and it is the difference between agents that behave predictably under load and agents that produce race conditions with real business consequences. If you have ever seen an agent programme get strange and flaky the moment it scaled past one user, this is usually why.

2. Narrow the tools before the model chooses

Here is a fact that surprises people the first time they hit it: giving an agent more tools makes it worse.

When an agent has to choose from a large surface of tools and APIs, two things happen at once. It burns inference reasoning over options it will never use, and its accuracy drops as the surface grows. The industry has spent the last year rediscovering this the expensive way, with pilots whose cloud bills nobody can explain and accuracy that falls off a cliff once the tool count climbs.

The fix is not fewer tools. It is route selection. A routing layer narrows the field before the model acts, collapsing a surface of roughly 150,000 tokens of tool definitions down to about 2,000, around 98% smaller, in under two seconds. The agent only ever reasons over the handful of candidates that matter for the request in front of it. The payoff is the part people do not expect: you can keep adding capability without the usual accuracy tax, because the model never has to hold your entire estate in its head. At small scale you will not notice. At real scale, this is what separates an agent programme that gets cheaper as it grows from one that gets more expensive and less reliable at the same time.

3. Check permission per user, per agent, per action

"Can this agent do this?" is the wrong question. It is too coarse to keep you safe.

The right question is longer, and answering it is most of the work: can this agent, acting for this specific user, take this specific action, on this system, right now? Most agent setups cannot answer that. Permissions are broad, identity is fuzzy, and an agent trusted for one job quietly inherits trust for all of them. That is exactly how an agent ends up doing something nobody authorised, at machine speed, with nobody watching.

A control plane checks policy, identity and risk on every request, per user, per agent, per action, before it runs. A read-only lookup passes lightly. Anything that can move money, touch sensitive data, or do something irreversible has to clear the controls that match its risk, or it does not execute. This is what governance-first actually means, and it is worth being clear that it is the opposite of locking everything down. You set the trust boundary to the action. The safe things stay fast. The consequential things stay controlled. Gartner's own recent guidance makes the same point from the other direction: applying one blanket policy to every agent, harmless or high-stakes alike, is now a leading cause of failure, not a form of safety.

4. Carry the context across the whole job

Real work is not a single call. It is a chain. Check availability, hold it, confirm identity, take payment, update three systems, tell the customer. The failures that look baffling from the outside almost always come from an agent losing the thread somewhere in that chain. A booking held but never confirmed. A payment taken against the wrong hold. A job left half-done that cannot say where it stopped.

Context continuity is the capability that carries state across the task: what has been done, what is still pending, what this particular request is a part of, so that step four knows what steps one to three actually did. It is how a job that spans several systems completes as one coherent action instead of a series of hopeful, disconnected calls. Hardly anyone talks about this, which is exactly why so many pilots shine on a single question and fall apart on a real workflow. The demo is one turn. The business is twenty. If an agent cannot reliably finish what it started across your systems, it is not ready for the work you actually want from it.

5. Make every action reviewable after the fact

Ask a team running an agent pilot what their agent did yesterday and watch the question land. Usually nobody can say. The logs show inputs and outputs. The decisions in between, which tool, which permission, which system, and why, are a black box.

That is survivable in a demo. It is fatal at the compliance review, which is where a lot of otherwise good agent projects quietly die before they ever reach production. Audit and observability is the capability that closes the gap: every action attributable, every decision reviewable, every step reconstructable afterwards, without slowing the build down. You can replay what an agent did and prove it was allowed to do it.

This is the capability that flips governance from a brake into an enabler. When you can account for every action, the compliance conversation stops being the thing that blocks the rollout and becomes the thing that signs it off. Which is why observability cannot be the piece you bolt on at the end. It has to be designed in from the first capability, not the last.

The point of all five

Notice that none of these five is about the model, and none is about connecting to tools. Intent arbitration, route selection, policy and identity, context continuity, and audit. They all live in the same place: the layer between the agent's request and the action. Inbound agents arriving from your customers or internal agents your own teams are building, it is the same five capabilities either way, seen from two directions.

Miss one and you get a recognisable version of the failure pattern. Unpredictable behaviour under load. Costs that climb as you add capability. Actions nobody signed off. Jobs that do not finish. A compliance review that kills the launch. Put all five in one control plane and agents stop being a risky pilot and start being operating infrastructure you can actually run a business on.

That is the whole idea behind KPATH, and it is built to work with the systems you already run rather than replace them. No rip-and-replace, no big-bang migration. A layer that sits above your APIs, your MCP servers and your existing agent frameworks, and gives every agent one governed path to act.

Where to start

You do not need to solve all five at once. You need to know which one is most likely to break your programme first, and that is usually a thirty-minute conversation, not a six-month study.

If you are building agents and any of the five above just made you wince, that is a good sign you are asking the right questions. We run a free 30-minute working session on your highest-stake decision. No pitch, no prep, just a straight conversation about where your agent programme is most exposed and what to do about it.

Book a free 30-minute consultation →

KPATH is a strategy, architecture and technology practice for the agentic web. We help organisations govern inbound agent traffic and internal agent projects, working with the systems they already run, and we build secure AI with national research partners including the UK Government's AI Collaboration Centre (AICC) and the Centre for Secure Information Technologies (CSIT).