DM Explains · No. 002 · Orchestration
Agent control plane: how enterprises will govern thousands of AI agents
As companies go from a dozen AI agents to tens of thousands, a new governance layer is emerging to watch and stop agents nobody on the risk team built.
· 13 min read
Read me first
The agent control plane genuinely does answer "who let that agent do that", but only once every vendor's agents are inventoried and wired into it; a governance layer nobody connected an agent to governs nothing.
An invoice-reconciliation agent from one vendor is mistakenly given payments-agent tool access from another → 1 inventory shows both agents and their allowed tools → 2 policy defines payments scope once, for all vendors → 3 runtime enforcement blocks the fund-transfer call in-path → 4 monitoring flags the anomalous attempt → 5 coordination stops a duplicate payment agent from also acting → 6 audit records the blocked call for compliance review
A bank runs agents from three different vendors: one drafts loan memos, one files support tickets, one moves money between internal accounts. Nobody in risk can say, on demand, exactly how many agents exist or what each is allowed to touch. Forrester reports the average Fortune 500 company ran fewer than 15 AI agents in 2025; Gartner's April 2026 research, cited by vendor guides, projects that figure could exceed 150,000 per enterprise by 2028. Governance built for fifteen does not survive contact with a hundred and fifty thousand.
Everyday picture. Amma keeps one notebook listing every errand each family member has been asked to run and what they may buy with the household card. Papa's fuse box can cut power to any room the instant a device from any shop draws too much current, whichever shop it came from. The school library logs who borrowed which book, whatever publisher printed it.
Where the picture breaks. Amma's notebook is updated by her alone, after the fact, and the fuse box only trips on one kind of signal. A real control plane intervenes on many kinds of policy, in real time, before the action completes — which no single household object does.
Why it exists now
Forrester formally named "agent control plane" an emerging market category in December 2025, describing it as an enterprise control plane that inventories, governs, orchestrates and assures heterogeneous AI agents across vendors and domains (Forrester). The naming matters because it draws a line between three separate jobs that had been blurring together: a build plane (the tools used to create an agent), an orchestration plane (the tools that route work through agentic and non-agentic steps), and now a control plane that sits above both, watching agents regardless of which vendor built them.
What changed to make this urgent is scale, not sophistication. The problem is not that agents got smarter; it's that a handful of pilot agents became a fleet before anyone built the plumbing to supervise a fleet. Forrester expects the space to solidify into a clearer market with distinct offerings and evaluation criteria over the next twelve to twenty-four months, which is itself a sign of how unsettled this still is — vendors are shipping products against a category definition that is only months old. Galileo launched an open-source policy layer called Agent Control in March 2026 under the Apache 2.0 licence, built to wrap model or tool calls in a decorator that checks a centralised policy store (Galileo). LangGuard built its platform around three named components — inventory, runtime decisions and audit — designed to work independently of whichever framework built the agent (LangGuard).
How it works
Inventory & identity
You cannot govern what you cannot list
What it is. A single catalogue of every agent across every vendor: who owns it, what tools it can call, what data it can touch.
Why it exists. Forrester names agent inventory and identity as a core feature of a control plane, because without a baseline record of what exists, there is nothing to check behaviour against.
Where it breaks. An inventory only reflects what was registered. An agent deployed outside the process, or spun up quickly to solve a one-off problem, does not appear in the catalogue until someone notices it acting.
How that's handled. Registration is treated as a gate: an agent that has not been catalogued is not given production tool access in the first place, rather than trusting teams to register agents voluntarily after the fact.
In technical terms
In technical terms: the control plane maintains identity and permission records for each agent independent of the framework that built it, which is the starting inventory Forrester describes as foundational to the category.
Policy definition
One rule, written once, applied everywhere
What it is. The place where business, risk and technical rules about agent behaviour are written down once, centrally, instead of being reimplemented inside each build tool.
Why it exists. Rules that are written per-team and per-tool drift; a spending limit set inside one vendor's agent builder means nothing to an agent built on a different stack.
Where it breaks. Centralising the rule does not resolve disagreement about what the rule should say. Two teams with conflicting business requirements still need a human decision before the plane can encode anything.
How that's handled. Policy authorship stays a people problem, arbitrated by risk and business owners; the control plane just guarantees that whatever is agreed gets enforced everywhere at once rather than department by department.
In technical terms
In technical terms: policies are stored centrally and applied uniformly regardless of the vendor or framework an agent was built with, closing the gaps that appear when each team writes its own guardrails.
Runtime enforcement
Watching after the fact stops nothing
What it is. The point where an agent's decision or tool call is actually routed through the control plane before it completes, so the plane can allow it, block it, or step in.
Why it exists. A log entry written after money has already moved is a record of a failure, not a prevention of one.
Where it breaks. Putting enforcement in the path of every action adds latency, and it adds a new single point of failure: if the enforcement layer stalls or goes down, agents either wait or, depending on how the fallback was designed, act unchecked.
How that's handled. Galileo pairs its runtime intervention with Luna-2 evaluator models built specifically to make sub-200ms guardrails viable at full production traffic, so the check does not become the bottleneck (Galileo). LangGuard's Arbiter component is built to sit in the same in-path position, making the runtime assurance decision at the moment of the call (LangGuard).
In technical terms
In technical terms: a decorator or sidecar wraps each model or tool call and checks it against a centralised, hot-reloadable policy store — meaning the rule can change without redeploying the agent — before the call is allowed to proceed.
Monitoring & insight
You see what agents do, not just what they were told
What it is. Continuous visibility into what a fleet of agents is actually doing, across vendors, aggregated into one view.
Why it exists. An agent's own logs describe its intentions in its own vendor's terms; an operator needs one consistent view across a mixed fleet to spot patterns a single vendor's dashboard would never show.
Where it breaks. Monitoring is only as informative as the telemetry that feeds it. An agent that bypasses instrumented tool calls, or acts through an unmonitored path, is invisible to the plane even while it is invisible to nobody else.
How that's handled. Monitoring here is closer to a compliance loop than plain observability: what it sees is interpreted against policy and can trigger the runtime enforcement step, rather than sitting as a dashboard nobody acts on.
In technical terms
In technical terms: telemetry from agent activity across processes and platforms is aggregated centrally and checked against policy, distinguishing this from observability tools that only report data without acting on it.
Coordination
Uncoordinated agents duplicate and collide
What it is. Shared protocols that let agents built on different stacks work together in a controlled sequence rather than tripping over each other.
Why it exists. As agent counts grow into the thousands, agents built independently by different teams and vendors start reaching for the same tools and data without knowing about one another.
Where it breaks. Coordination protocols only work if every vendor's agents actually speak them. A stack that does not integrate with the shared protocol simply sits outside the coordinated fleet, invisible to the others.
How that's handled. Vendors increasingly build against shared protocols for agent-to-agent communication and tool access — often referenced under names like the Model Context Protocol — as the layer where cross-vendor governance gets applied consistently rather than per-integration.
In technical terms
In technical terms: agent-to-agent communication and tool access routed through a common protocol becomes a natural point where the control plane can apply the same policy check no matter which vendor originated the call.
Audit & compliance
If it wasn't logged, it didn't happen
What it is. A record of every decision, block and policy change, kept independently of the agent's own logs.
Why it exists. Forrester points to precedents already trusted in other domains for this kind of out-of-band oversight: Airbnb's experimentation platform runs independent guardrails outside the service under test and halts experiments automatically when metrics drift beyond thresholds; JPMorgan's model risk governance function validates and monitors AI and ML models independently of the teams that build them (Forrester). Agent audit extends the same logic to agent fleets.
Where it breaks. A record is history, not prevention. It explains an incident after the fact; the enforcement step earlier in the sequence is what actually stops the incident happening.
How that's handled. LangGuard names this component GRAIL, built to keep the record independent of the agent's own instrumentation, so an audit does not rely on the very system being audited to have told the truth about itself (LangGuard).
In technical terms
In technical terms: decisions, interventions and policy changes are logged centrally so high-level risk frameworks can be mapped onto concrete, evidenced controls rather than onto self-reported agent activity.
Compared with what came before
| Per-vendor native controls | Agent control plane | |
|---|---|---|
| Scope | Governs only agents built inside that vendor's own ecosystem | Governs agents across vendors and frameworks |
| Enforcement point | Inside the agent's own build tool | Centralised, in the path of the action |
| Policy consistency | Rewritten per team, per tool | Written once, applied uniformly |
| Audit trail | Relies on the agent's own logs | Independent record, kept outside the agent |
| Fit | A handful of agents on one stack | Thousands of agents across many stacks |
The judgement is not that native, vendor-specific controls are wrong; for a small deployment on one stack they may already suffice. The control plane earns its place at the point where an enterprise cannot answer, for any one agent picked at random, who owns it and what it is allowed to do — which is a scale problem, not a sophistication problem.
Where it breaks
If an enterprise runs a handful of agents on one vendor's stack, a control plane is overhead without a matching payoff; informal review still works at that scale.
Not a substitute for agreeing what the policy should say
Centralising enforcement does not resolve disagreement between teams about what an agent should be allowed to do. Two conflicting business rules still need a person to arbitrate before the plane has anything correct to enforce.
The runtime enforcement step is also, unavoidably, a new dependency sitting in the path of every agent action. Sub-200ms evaluator checks, as Galileo describes them, are built to keep that dependency from becoming a bottleneck, but the dependency itself does not disappear: if the enforcement layer is unavailable, the design choice of "fail closed" versus "fail open" decides whether agents stall or run unchecked, and that choice carries real cost either way. And inventory, coordination and monitoring all share the same weak point — an agent that never registers, never speaks the shared protocol, or acts through an uninstrumented path stays outside the plane's view no matter how well the plane is built.
Numbers to carry
| Figure | Detail |
|---|---|
| Fewer than 15 | Average number of AI agents run by a Fortune 500 company in 2025, per a vendor guide |
| 150,000 by 2028 | Projected AI agents per enterprise, per Gartner's April 2026 research as cited by a vendor guide |
| December 2025 | Month Forrester named "agent control plane" as an emerging market category |
| 12–24 months | Forrester's expected window for the market to solidify into distinct offerings and evaluation criteria |
| March 2026 | Galileo's launch of Agent Control, an open-source policy layer under Apache 2.0 |
| Sub-200ms | Guardrail latency target for Galileo's Luna-2 evaluator models at full production traffic |
Myths worth killing
| Commonly repeated | What is actually true |
|---|---|
| "A control plane is just another observability dashboard" | Observability tools report telemetry; a control plane interprets that telemetry against policy and can act on it before an action completes |
| "This replaces the tools we build agents with" | It sits above the build plane and the orchestration plane, governing agents made by either, not replacing either |
| "One vendor's agent guardrails cover the whole fleet" | Native guardrails only govern agents inside that vendor's own ecosystem; a mixed fleet needs a layer that works the same way across vendors |
| "Logging what happened is governance" | A log explains an incident afterwards; only enforcement in the path of the action stops it happening |
Worked example
- The vendor teams each build and deploy their own agent: one vendor's agent reconciles invoices, another vendor's agent handles payments between internal accounts.
- The control plane's inventory registers both agents on deployment, recording which tools and accounts each is permitted to touch.
- Someone misconfigures access, and the invoice-reconciliation agent is granted the same tool access as the payments agent — illustratively, a shared credential intended for a batch job gets reused across both.
- The reconciliation agent attempts a transfer outside its remit, following the pattern it was built to follow, unaware that this action sits outside its stated purpose.
- Runtime enforcement intercepts the call before it completes, checking it against the centrally defined policy for that agent's registered permissions, and blocks it.
- The audit record logs the blocked call, the policy that triggered it and the timestamp, independently of the reconciliation agent's own logs.
- Risk reviews the log, corrects the misconfigured access, and updates the policy — closing the loop that the inventory and enforcement steps opened.
Should you use it?
Reach for a control plane once agents are being built by more than one team or vendor, once nobody can answer "how many agents do we run" without a meeting, or once risk needs an audit trail that does not depend on the agent's own word for what it did. Skip it if the whole deployment lives on one vendor's stack with a handful of agents that one team can review by hand — the overhead of a separate governance layer buys nothing yet.
The cheapest first experiment is not enforcement; it's inventory. Before wiring anything into runtime blocking, build the single catalogue: every agent, its owner, its permitted tools. Most enterprises discover the gap is not "we need better guardrails" but "we cannot currently answer how many agents exist."
Say it in the room
"Start with the inventory, not the enforcement layer — you cannot write a policy for an agent you didn't know existed."
Lines to carry
- "You cannot govern what you cannot list."
- "Watching after the fact stops nothing."
- "One rule, written once, applied everywhere."
- "If it wasn't logged, it didn't happen."
- "Governance built for fifteen agents won't survive a hundred thousand."
FAQ
Is an agent control plane a product I buy, or an architecture I build?
Both, depending on the vendor. Some ship it as an open-source policy layer to integrate, like Galileo's Agent Control; others ship it as a platform with named components for inventory, enforcement and audit, like LangGuard. Either way it is a layer, not a single box.
Does this replace the agent frameworks we already use to build agents?
No. Forrester's own framing separates a build plane (the tools that create agents), an orchestration plane (the tools that route work through them) and the control plane, which governs agents from either regardless of how they were made.
What happens if the control plane itself goes down?
That depends on how enforcement was designed to fail. Some designs stall agents until the plane is back; others let agents proceed unchecked. Either choice carries a cost, which is exactly why it needs to be a deliberate decision, not a default nobody examined.
Do small companies need this yet?
Probably not. The case for a control plane strengthens with the number of vendors and agents involved; a handful of agents on one stack is still governable by a team reviewing logs directly.
How mature is this category right now?
Young. Forrester only named it in December 2025 and expects the market to take twelve to twenty-four months to settle into distinct offerings and evaluation criteria — buying decisions made today are buying into a category still being defined.
Glossary
- Agent — a software system that can take actions, such as calling tools or making decisions, on behalf of a user or process with some autonomy.
- Agent control plane — a governance layer above however agents are built or orchestrated, providing inventory, policy enforcement, monitoring and audit across vendors.
- Build plane — the layer of tools used to create agents: model access, frameworks, tool integration, evaluation pipelines.
- Orchestration plane — the layer that models business processes and routes work through agentic and non-agentic steps.
- Guardrail — a rule or mechanism that constrains what an agent is allowed to do.
- Runtime enforcement — applying a policy decision at the moment an agent tries to act, rather than only reviewing it afterwards.
- Agent sprawl — rapid, often unmanaged growth in the number of agents an organisation runs.
- Model Context Protocol (MCP) — a protocol some vendors use for connecting agents to tools and data, and a point where control planes can apply governance.
- Hot-reloadable policy — a rule that can be changed and applied to running agents without redeploying them.
Sources
- Announcing Our Evaluation Of The Agent Control Plane Market — Forrester, 2025
- AI Governance Tools Across the Stack — Galileo, 2026
- LangGuard Platform: Deterministic Runtime AI Governance — LangGuard, undated