Multi-Agent Orchestration Needs a Control Plane

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.

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.

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.