Multi-agent orchestration is here
Multi-agent is no longer a research paper topic. Gartner predicts 40% of enterprise applications will feature task-specific AI agents by the end of 2026, up from less than 5% in 2025. LangGraph powers multi-agent systems at Klarna, Lyft, LinkedIn, and Cloudflare. CrewAI has role-based agent teams with integrations across Gmail, Salesforce, and HubSpot. Microsoft's Agent Framework unifies Semantic Kernel and AutoGen for enterprise-grade orchestration.
Real use cases are running now: research teams where one agent searches and another synthesizes, customer support chains where triage delegates to specialists, and data pipelines where extraction, transformation, and loading agents coordinate through shared state. This is not speculative. It is production software.
What top resources miss in production
The best sources explain how to orchestrate agents. The missing layer is governance under delegation pressure. That is where incidents happen in real fleets.
| Source | What it covers well | Gap for fleet governance |
|---|---|---|
| Microsoft Learn: AI Agent Orchestration Patterns | Strong pattern taxonomy for single, sequential, parallel, and hierarchical orchestration. | No concrete policy-evaluation contract at delegation boundaries before tool execution. |
| LangChain Docs: Multi-Agent Overview | Clear execution model for multi-agent routing, planning, and task partitioning. | No fleet-level approval routing or immutable decision evidence across agent chains. |
| CrewAI Docs: Introduction + Architecture | Good mental model for Crews and Flows, including role specialization. | No standardized governance envelope for inherited policy constraints in deep delegation. |
A practical fix is a governance envelope on every delegated action. If you cannot reconstruct delegation path, policy version, decision, and approval outcome from one immutable record, you do not have operational governance.
{
"run_id": "run_01JTRTQY2EEX5PXJ7M4S3DV0F2",
"delegation_path": ["agent-a", "agent-b", "agent-c"],
"action": "job.customer.export.external",
"decision": "require_approval",
"policy_version": "v1.22.0",
"approval": {
"status": "denied",
"reviewer": "[email protected]",
"reason": "PII export outside approved processor list"
}
}The governance gap in multi-agent systems
Frameworks solve coordination. They handle message passing, state management, task delegation, and result aggregation. What none of them solve:
- - Policy inheritance across delegation. When Agent A delegates to Agent B, does B inherit A's policy constraints? In every framework today, the answer is no. B operates under its own configuration, if it has one.
- - Approval escalation. If Agent C (three levels deep in a delegation chain) attempts to export customer data, can the system pause and route an approval request to a human? Frameworks offer optional human-in-the-loop as a pattern. None make it a first-class orchestration primitive with escalation logic.
- - Fleet audit trail. LangSmith traces LangGraph calls. CrewAI traces steps. But traces are observability, not governance. A Sondera AI analysis puts it directly: "A log is a passive record of what happened. A security control is an active, pre-execution enforcement of policies."
- - Budget enforcement across the fleet. If three agents run simultaneously and each spawns sub-agents, no framework enforces a total spend limit across the fleet. Each agent operates independently with no budget coordination.
Singapore's IMDA launched the world's first agentic AI governance framework in January 2026, explicitly requiring organizations to bound agent powers and define checkpoints requiring human approval. The regulatory expectation is clear. The framework support is not.
Framework vs control plane: different problems
This is not a criticism of agent frameworks. They solve a real problem well. The distinction is between coordination and governance.
| Capability | Frameworks | Control Plane |
|---|---|---|
| Agent coordination | Yes | Not its job |
| State management | Yes | Not its job |
| Pre-execution policy | No | Yes |
| Approval gates | Optional HITL | First-class |
| Immutable audit trail | Observability only | Yes |
| Fleet budget limits | No | Yes |
| Policy inheritance | No | Yes |
You use a framework to build the multi-agent system. You use a control plane to govern it. Production deployments need both.
The accountability chain problem
Here is the scenario that breaks every framework-only deployment.
Who approved Agent C's action? What policy governed it? Did Agent A intend for its "prepare a report" task to result in PII leaving the organization? In a framework-only deployment, nobody knows. The delegation happened. The action ran. There is no governance record of the chain.
With a control plane, every boundary in the chain gets a policy check. Agent A delegates to B: allowed (internal delegation). Agent B queries the database: allowed (read access). Agent C sends data externally: REQUIRE_APPROVAL. A human reviews the request, sees that customer emails would leave the org, and denies it. Audit trail records every decision in the chain.
What a multi-agent control plane looks like
A control plane for multi-agent systems provides four capabilities that frameworks do not:
Policy at every delegation boundary. When Agent A delegates to Agent B, the control plane evaluates the delegation against policy. When B calls a tool, the control plane evaluates the tool call. Every action by every agent passes through the same policy engine, regardless of where it sits in the chain.
Approval propagation. If a sub-agent three levels deep triggers a REQUIRE_APPROVAL decision, the approval request routes to the right human with full context: which agent, what action, what delegation path led here, what policy triggered the gate.
Fleet-wide limits. Total token spend, total API calls, total concurrent agents, all enforced across the entire fleet. Not per-agent limits that each agent manages independently, but fleet limits that the control plane enforces centrally.
Here is what delegation governance looks like as policy-as-code:
# safety.yaml - multi-agent delegation governance
version: v1
rules:
- id: allow-internal-delegation
match:
topics: ["job.*.delegate.internal"]
risk_tags: []
decision: allow
reason: "Internal agent delegation is safe"
- id: approve-data-access
match:
topics: ["job.*.read.customer-data", "job.*.read.pii"]
risk_tags: ["pii", "customer-data"]
decision: require_approval
reason: "Customer data access requires review"
- id: approve-external-action
match:
topics: ["job.*.send.*", "job.*.export.*", "job.*.publish.*"]
risk_tags: ["external"]
decision: require_approval
reason: "External actions from any agent need approval"
- id: deny-bulk-export
match:
topics: ["job.*.export.bulk", "job.*.download.all"]
risk_tags: ["bulk-data", "exfiltration-risk"]
decision: deny
reason: "Bulk data export blocked regardless of delegation path"Internal delegation passes through. Customer data access pauses for review. External actions require approval regardless of which agent in the chain initiates them. Bulk exports are blocked outright. These rules apply to every agent in the fleet, whether it was directly invoked or delegated to five levels deep.
The Kubernetes analogy
Kubernetes did not replace Docker. Docker built and ran containers. Kubernetes governed containers at fleet scale: scheduling, networking, secrets, resource limits, health checks, rolling updates. You still used Docker (or containerd) to run the workload. Kubernetes sat above it.
The same pattern applies to agents. LangGraph, CrewAI, and AutoGen are the container runtimes. They build and run agent workflows. A control plane sits above them, governing what agents can do: policy enforcement, approval gates, budget limits, audit trails. You still use the framework. You add the governance layer.
We explore this analogy in depth in our workflow orchestration post. The short version: the industry already solved this problem once. The solution was not a better container runtime. It was a control plane.
Getting started with multi-agent governance
1-3 agents: Per-agent governance is sufficient. Add policy evaluation and audit trails to each agent individually. This works when you can hold the full system in your head. Start with Cordum's quickstart to add governance to your first agent in five minutes.
3-10 agents: You need shared policy. Writing separate rules for each agent creates inconsistency. Centralize your policy-as-code and apply it across all agents. Add fleet-level budget limits.
10+ agents: You need a control plane now. Individual governance does not scale. Delegation chains cross team boundaries. Budget enforcement requires central coordination. Audit requirements demand organization-wide visibility. This is where Cordum sits: a source-available (BUSL-1.1) control plane that governs agent fleets with sub-5ms policy evaluation, structured approval workflows, and append-only audit trails.
Frequently asked questions
What is a multi-agent control plane?
A multi-agent control plane is a governance layer that sits above your agent framework and enforces policy on every action, regardless of which agent in a delegation chain initiates it. Where a framework (LangGraph, CrewAI, AutoGen) coordinates agents — message passing, state, task delegation — the control plane governs them: pre-execution policy evaluation, approval gates, fleet-wide budget limits, and an immutable audit trail. Production multi-agent systems need both.
Why isn't my agent framework enough for governance?
Frameworks solve coordination, not governance. They do not enforce policy inheritance across delegation (when Agent A delegates to B, B does not inherit A's constraints), do not make approval escalation a first-class primitive, and provide observability traces rather than active pre-execution enforcement. As one analysis puts it, a log is a passive record of what happened, while a security control is active, pre-execution enforcement of policy. The framework builds the system; the control plane decides whether a risky action is allowed to run.
What is the accountability chain problem in multi-agent systems?
It is the scenario where Agent A delegates to B, which delegates to C, and C takes a risky action — say, sending customer emails to an external API. In a framework-only deployment nobody can answer who approved it, what policy applied, or whether A's original task intended that outcome, because there is no governance record of the chain. A control plane checks policy at every delegation boundary and records each decision, so the export can be gated for human review before it happens.
How does policy inheritance work across delegation chains?
With a control plane, every action by every agent passes through the same policy engine regardless of depth in the chain. Internal delegation can pass through, customer-data access can pause for review, and external or bulk-export actions can require approval or be denied outright — and those rules apply whether an agent was invoked directly or delegated to five levels deep. The policy is centralized as policy-as-code rather than configured separately per agent.
When do I actually need a control plane vs per-agent governance?
Roughly by fleet size. With 1-3 agents, per-agent governance is sufficient — you can hold the whole system in your head. At 3-10 agents you need shared, centralized policy and fleet-level budget limits to avoid inconsistency. At 10+ agents a control plane becomes necessary: delegation chains cross team boundaries, budget enforcement requires central coordination, and audit needs organization-wide visibility that individual agent configs cannot provide.
How is this like Kubernetes for AI agents?
Kubernetes did not replace Docker; it governed containers at fleet scale (scheduling, networking, secrets, resource limits) while Docker still ran the workload. The same split applies to agents: LangGraph, CrewAI, and AutoGen are the runtimes that build and run agent workflows, and a control plane sits above them enforcing policy, approvals, budgets, and audit. You keep the framework and add the governance layer — the industry already solved this shape once.