Our clients are telling us that trust, safety and transparency will be critical to scaling AI across their businesses. AI governance is as much an engineering challenge as a policy one, and a market of agent control planes is emerging to address it.
I wanted to understand what an agent control plane actually is, and whether it described something genuinely new or simply gave a name to things we were already doing. The answer, it turned out, was both.
What became clearer along the way is that the label is less important than the reason it’s being raised in the first place.
The questions underneath the question
At the executive level, solution architecture is rarely the starting point. The questions are more fundamental. Are agents leaking intellectual property or confidential information? Does an agent signed off two months ago still behave the way it did then? Who is managing drift and lifecycle, including retiring an agent nobody owns any more? Can someone turn it off?
Underneath all of that is accountability. If an agent resolves a bug in a way that introduces a vulnerability into your enterprise architecture, who owns that outcome? A vendor agreement does not settle who inside your organisation is accountable. That has to be designed into the system: what the agent is allowed to do, what evidence exists of what it did, and who owns the response when something goes wrong.
That article is all about the gap raised by these questions. The architecture follows the conversation.
What the layer is, and what it is not
It is useful to think of an agentic control plane as the shared layer that governs agents across an organisation. It moves things like policy, identity, observability and evaluation out of individual applications and gives them somewhere consistent to live.
An individual agent will usually already have some kind of harness around it: instructions, tools, permissions and checks on what it produces. An orchestration framework manages how agents and workflows interact. A control plane becomes relevant when some of those controls need to apply consistently across multiple agents, applications or teams.
It works in two directions. It helps you observe and evaluate what agents did, and it can also enforce rules at the tool or credential boundary before an action happens.
Agents put extra pressure on some familiar controls, particularly identity and accountability for non-human actors, permissions that can change at runtime, and verification before an action happens.
In practice, that can include agent inventory and identity, policy enforcement and audit trails, deployment, versioning and rollback, cost visibility, and continuous evaluation.
Caption: The control plane provides shared governance across agentic systems. Each agent retains its own execution logic and harness, while enterprise controls remain part of the architecture.
Do you need one yet?
This question has no neat threshold, but as a useful test I would ask five questions all underpinned by the degree of customer or system impact.
- What could the agent do if it behaved badly?
- What data could it expose?
- How quickly could you see what happened?
- How easily can you revoke its permissions?
- Who owns the response?
If you can answer all five confidently, more control tooling can probably wait. If you can’t, the weakest answer tells you where to invest first.
The number of agents tells you very little on its own. One of the projects I looked at had moved from a multi-agent architecture back to a single agent because it made the system easier to debug and allowed more deterministic, hand-coded orchestration. Others were going the other way, splitting one agent into several as the use case expanded. Counting agents would have told you nothing useful about either.
What matters is what the agents can do, what they can reach, and how difficult their behaviour is becoming to understand, which is what the five questions can help to bring out.
A proof of concept working against public data needs very little around it. An agent running in production against sensitive information is a different proposition, particularly if it can update a customer record, commit code or trigger another system.
Productionisation is an obvious trigger, but in a large organisation the more important change can be the move from multi-agent inside a single solution to agentic systems being built independently across the enterprise. That is where duplicated controls, different approaches to evaluation and unclear ownership start to appear. It becomes harder to answer a basic question: what agents do we have running, who owns them, and what can they reach?
Regulated environments bring those concerns forward because you need clearer evidence of how the system behaves and who is accountable for it.
There are also cases where the control layer becomes part of what makes the architecture feasible. Take a group with several operating businesses under it, each with its own systems, data and customers, wanting to put one agent in front of a customer that can answer across all of them. Orchestration alone won’t get you there. First you need a control layer that knows which agents are running in each business, what systems and data each can reach, and what commitments each is allowed to make in the group’s name. Without that, a single customer-facing agent is more likely to be a liability rather than an asset.
It is also worth separating different classes of agent because the controls that matter most can be very different depending on the context.
An agent writing code creates a software supply-chain problem that usually arrives through a pull request. An agent in front of a customer creates a runtime and regulatory problem, often in real time. Review gates, test coverage and behavioural logging may do much of the work in the first case.The second is more likely to need runtime policy and a clear boundary around what the agent is authorised to do. The five questions apply to both; what changes is which answer is weakest.
Why the category appeared now
Control planes tend to appear once running a maturing technology becomes a solved problem but controlling it is hard. Kubernetes is the comparison people often reach for with containers, Docker made them simple to run then Kubernates emerged as the control plane to schedule, scale and govern them.
What has changed over the last six to twelve months is the amount of product activity around this space. The hyperscalers now bundle more of the runtime, memory, identity, observability, evaluation and governance capability into managed agent platforms, while specialist tools cover narrower parts of the problem.
One caution before looking at the market: much of what is written about agentic control planes is published by companies selling one.
That does not make the category meaningless, but it is worth separating the problem you need to solve from the product boundaries vendors choose.
The large cloud platforms are an obvious place to start looking if you already operate heavily within one ecosystem. Their approaches differ in areas such as policy enforcement, enterprise identity integration, modularity and how much of the agent lifecycle they manage for you.
Specialist tools may solve only one part of the picture, such as runtime policy, observability or evaluation. That can be exactly what you need. A tool does not have to be an all encompassing control plane to be useful.
The important distinction is knowing what problem you need to solve, what a product actually solves and what remains yours to own.
What it costs
The pricing structures differ more than the prices, and the structure is the part to look at.
You will see modular consumption pricing, per-seat subscriptions combined with metered usage, tiered monthly subscriptions, and models where token and tool usage is billed separately from governance features. Structure also matters as agents grow, a per-seat model behaves very differently from a consumption model if agents begin to outnumber people using them.
Anything I quote here will be out of date quickly, so I would treat the pricing model as the durable part and check the current numbers when you are making the decision.
The first question is about what the platform costs. The second cost question, what agentic work costs and what it delivers, tends to get asked later than it should. Agentic spend is itemised to the token while the value is spread across teams and hard to attribute. The same traces that let you govern an agent can help you answer what a piece of agentic work cost and what it produced.
Governance and cost attribution are not two separate projects.
What to put in early, whatever else you decide
If I had to choose one thing to have in place from the start, it would be observability.
That came through consistently in every conversation I had because you need to be able to reconstruct what happened during an agent run. What did it receive? Which tool did it call? What came back? Where did it fail? What did it cost?
Without that, it is difficult to improve the system or decide which additional controls you need. The exact tooling matters less than having the capability. The teams I spoke to were using different platforms depending on the environment, what they already knew, and what the client was comfortable supporting.
There is an important data consideration here. Agent traces can contain sensitive information, so making everything observable does not mean making everything visible to everyone. The tracing and logging layer needs its own access controls and PII handling. Treat observability as part of the production architecture rather than something added later, once debugging has already become difficult.
The second thing is to stop treating governance as a one-time pre-production exercise. Agentic systems change as models are upgraded, prompts are refined, tools are added and the data around them evolves. A set of evaluations that gave you confidence four months ago may not cover the system you have today.
The same goes for guardrails because you learn about new failure modes once people start using the system in ways you did not predict.
That is close to how we already think about testing and operational monitoring. For structured outputs in particular, fairly traditional techniques still work well. Unit tests, schema validation and behavioural logging give you deterministic checks around parts of an otherwise probabilistic system.
Not every problem created by agents needs an entirely new answer.
What to buy
If you are already deep in one cloud, the managed platform is an obvious option to assess first.
Where the platform already solves a commodity problem well, rebuilding it yourself needs a good reason. Managed services can reduce the amount of infrastructure your team has to own and maintain, and they can give you a faster route to some of the controls you need.
As always, the trade-off is control. You are adopting that platform’s conventions, capabilities and constraints, and how well that works depends on the environment.
Buying also does not have to mean adopting a whole platform. One team used the memory capability of a managed platform because it solved that problem well and left the rest of the architecture alone because other parts of the governance picture already existed elsewhere in the organisation.
What to build
On-premise is the clearest case. One of the projects I looked at ran fully offline, on laptops, with no network available at all, which rules out managed cloud services entirely.
Other reasons include unusual security requirements, integration with enterprise controls you already have, hardware constraints and portability.
The underrated reason is debuggability. A managed framework lets you move quickly, but when something goes wrong you are operating inside somebody else’s abstractions. A simpler custom implementation can give you much more direct visibility into what is actually happening.
Against that, you are choosing to own more code and more infrastructure.
One thing worth saying about our own work is that most of it was built before the fully managed platforms existed, which is why so much of it is assembled from parts. Those were sound decisions against the options available at the time.
The options have changed, so the decision is worth making again on each engagement rather than inheriting the last answer.
What to leave alone
Of the three, this is the one that gets the least attention, and it is where I would take the most care.
Agentic systems become complicated quickly, so every new layer of architecture needs a reason. There is no prize for having the most complete control-plane architecture if it does not add any extra value. In practice, there are three things to consider leaving alone.
The first is a well-contained agent, with narrow permissions, a human approval point before anything consequential, and enough observability to understand how it behaves, may already be governed well enough for the problem in front of you.
The second is controls that already work. Most organisations already have identity platforms, code review gates, testing pipelines and access management, and many of these can apply to agents as well as to people and services. A coding agent whose changes arrive through a pull request is already passing through a control point. Adding another control layer or product there may give you more architecture without materially reducing the risk.
The third is standardising too early. There is a strong case for centralising the patterns that keep coming up, so every engineer or team does not have to rediscover the same safe path for themselves. The right time is when a pattern has proved itself and the cost of not standardising is starting to show in duplicated controls, different approaches to evaluation, or teams re-solving problems another team has already solved. Start with the controls that carry the most risk, such as agent identity, permissions and audit trails. To stop teams building their own workarounds, any standard needs to be easy to use and have an owner for when things change.
What you cannot leave alone is knowing what controls are in place and who owns each one. In several of the environments I looked at, responsibility for controls was already spread across security, data science, platform and product teams, and nobody held the whole picture.
Most real architectures are a mix
The projects I looked at did not divide neatly into managed or bespoke. They did some of each.
One might use an existing identity platform, a managed service for memory, a specialist observability tool and custom orchestration around the agent itself. Another might need a largely self-hosted stack because of where it has to run.
This is why I find the agentic control plane more useful as a way of thinking about an architecture than as a product category.
What you build, buy, or leave alone depends on the project, but the questions you need to answer stay fairly consistent. What is running? What can it do? How do we see what it did? How do we keep the right controls in place as the system changes?
Where to start
Map what you already have. Find the agents, understand their permissions, make their behaviour visible and work out where responsibility for the controls already sits. In most organisations, that exercise turns up more than people expect, spread across more teams than anyone had counted.
After that, build, buy, and leave alone becomes an ordinary architecture decision, made against a real picture rather than a category.
Further reading
Cloud Security Alliance: Securing the agentic control plane
Forrester: Announcing our evaluation of the agent control plane market
