The multi-agent governance problem
Consider a deployment review workflow. An orchestrator agent receives a deploy request and delegates to a planner agent, which delegates to a reviewer agent, which delegates to a deployer agent. The deployer runs kubectl apply against production.
Three questions matter immediately: Who approved the final action? Which policy applied at each delegation step? If the deployer was denied, can the reviewer retry with a different agent that has broader permissions?
Single-agent governance answers these questions for one agent. Multi-agent system governance answers them across the entire delegation chain, for every agent involved, with a single correlated audit trail.
This is not a theoretical concern. Production multi-agent systems built with CrewAI, AutoGen, LangGraph, and custom orchestrators already run delegation chains three to five levels deep. Without fleet-level governance, each agent operates with its own local view of what is allowed. The result is policy gaps at delegation boundaries and untraceable side effects.
Why multi-agent governance differs from single-agent
Governing a single agent is relatively straightforward: define a policy, evaluate each action against it, log the decision. Multi-agent systems introduce three complications that single-agent governance does not address.
Delegation chains
When Agent A delegates to Agent B, which delegates to Agent C, the policy context must travel with the delegation. If Agent A has production write access but Agent C does not, the delegation should not implicitly grant Agent C broader permissions. Policy must be evaluated at each link in the chain, not just at the entry point.
Shared state and cross-agent side effects
Agents in a fleet often share state through databases, message queues, or shared memory. Agent B might modify a configuration file that Agent C reads two seconds later. If Agent B's write was governed but Agent C's read was not, the governance boundary has a gap. Side effects that span agents require governance that spans agents.
Attribution and accountability
When a multi-agent workflow produces an unintended outcome, you need to answer: which agent made the decision, which policy rule applied, and who in the delegation chain should have caught it? Without correlated audit trails, post-incident analysis becomes guesswork.
| Dimension | Single-agent | Multi-agent |
|---|---|---|
| Policy scope | One agent, one policy file. Rules apply to that agent only. | Fleet policy plus per-agent overrides. Inheritance and conflict resolution required. |
| Approval chains | Human approves the agent action directly. | Agent A requests approval, but the action was triggered by Agent B. Who should the approval route to? |
| Side effects | The agent caused the side effect. Attribution is clear. | Agent C writes to production. But Agent A delegated to B, which delegated to C. The side effect trace spans three agents. |
| Audit trail | Linear log of decisions for one agent. | Correlated log spanning multiple agents, requiring trace_id propagation and parent-child linking. |
| Failure blast radius | One agent fails, one workflow stops. | One agent fails mid-delegation, downstream agents may continue with stale or partial context. |
What top resources miss
| Source | Strong coverage | Missing piece |
|---|---|---|
| Singapore IMDA: Model AI Governance Framework for Agentic AI | Strong framing of multi-agent accountability dimensions: risk bounding, technical controls, operator responsibility. | High-level principles without implementation patterns for delegation chains, trace propagation, or per-agent policy design. |
| NIST AI 600-1: AI Risk Management Framework Profile | Useful risk taxonomy and governance functions (Govern, Map, Measure, Manage) applicable to agent fleets. | No distinction between single-agent and multi-agent governance. No patterns for cross-agent audit correlation. |
| Microsoft AutoGen: Multi-Agent Patterns | Practical team orchestration patterns with round-robin, selector, and swarm topologies. | Orchestration patterns without policy enforcement. No pre-dispatch governance layer for agent-to-agent delegation. |
Fleet governance model
A fleet governance model has three layers. The fleet policy sets boundaries that no agent can cross. Per-agent policies refine behavior within those boundaries. A shared audit trail correlates every decision across all agents.
Global rules enforced for all agents. Defines maximum delegation depth, blocked action types, mandatory approval thresholds, and environment restrictions. Fleet denials cannot be overridden by per-agent rules.
Agent-specific rules that inherit from the fleet policy. A researcher agent might be allowed to read external APIs. A deployer agent might require approval for any write. Per-agent rules add constraints or relax fleet-level require_approval decisions to allow, but never relax fleet denials.
Every policy decision from every agent flows into a single audit store, tagged with trace_id, workflow_id, and delegation chain metadata. Post-incident queries can reconstruct the full decision tree for any workflow.
This layered model means you can add a new agent to the fleet and it immediately inherits fleet-level protections. You only need to write per-agent rules for behavior specific to that agent's role.
Governing delegation chains
Delegation chains are the defining challenge of multi-agent governance. Every time one agent hands a task to another, three things must happen:
- - Trace propagation. The delegating agent passes its trace context (trace_id, workflow_id, delegation_chain) to the delegate. The delegate appends itself to the chain and increments the delegation depth.
- - Policy inheritance. The delegate evaluates its actions against both the fleet policy and its own per-agent policy. The delegating agent's permissions do not transfer. Each agent is evaluated on its own access.
- - Depth enforcement. The fleet policy defines a maximum delegation depth. When an agent at the limit tries to delegate further, the governance layer denies the delegation. This prevents unbounded chains where no human can reason about what happened.
Here is what trace context looks like as it flows through a delegation chain:
# Trace context passed through delegation chain
{
"trace_id": "tr_8f3a2b1c",
"workflow_id": "wf_deploy_review",
"parent_job_id": "job_orchestrator_001",
"current_job_id": "job_reviewer_003",
"delegation_depth": 2,
"delegation_chain": [
"orchestrator-agent",
"planner-agent",
"reviewer-agent"
],
"policy_snapshot": "ps_2026-04-09_v3",
"originating_user": "ops-team@company.com"
}The delegation_chain array is append-only. Each agent adds itself when it receives a delegated task. The governance layer reads delegation_depth to enforce fleet limits. If the deployer agent at depth 3 tries to delegate to a fifth agent and the fleet limit is 3, the action is denied before it executes.
Correlating audit trails across agents
In a single-agent system, the audit trail is a flat list of decisions. In a multi-agent system, the audit trail is a tree. The root is the originating request. Each branch is a delegation. Each leaf is a terminal action.
Three identifiers make correlation possible:
A unique identifier generated at the originating request. Every agent in the delegation chain carries this ID. Query by trace_id to see all decisions for one end-to-end workflow execution.
Identifies which agent delegated the current task. Enables tree reconstruction: given any leaf node, walk parent_job_id references up to the root to see the full delegation path.
Identifies the workflow definition. Multiple executions of the same workflow share a workflow_id. Query by workflow_id to compare governance decisions across runs of the same workflow.
Here is what a correlated audit query looks like:
# Query: show all decisions for workflow wf_deploy_review cordum audit query \ --workflow-id wf_deploy_review \ --format table # Output: # TRACE_ID JOB_ID AGENT ACTION DECISION RULE_ID # tr_8f3a2b1c job_orch_001 orchestrator plan_deploy allow fleet-allow-read # tr_8f3a2b1c job_plan_002 planner write_config approve fleet-require-approval # tr_8f3a2b1c job_review_003 reviewer read_diff allow researcher-allow-read # tr_8f3a2b1c job_review_003 reviewer post_comment approve fleet-require-approval # tr_8f3a2b1c job_deploy_004 deployer kubectl_apply deny fleet-deny-prod-deletes
The table shows five decisions across four agents, all linked by trace_id tr_8f3a2b1c. The deployer's kubectl_apply was denied by the fleet policy. An incident reviewer can see the full chain: who originated the request, which agents participated, what each one tried to do, and which policy rule governed each decision.
Three multi-agent governance patterns
How you structure agent communication affects how governance is enforced. Three patterns dominate production multi-agent systems, each with different governance tradeoffs.
A single orchestrator agent delegates to worker agents. The orchestrator holds the fleet policy and passes scoped sub-policies to each worker. All approvals route through the orchestrator before reaching a human.
Strengths: Clear chain of command. Simple audit trail. Easy to enforce delegation depth limits.
Tradeoffs: Single point of failure at the orchestrator. Bottleneck if many workers need concurrent approvals.
Agents communicate directly and delegate tasks laterally. Each agent carries its own policy plus a shared fleet policy. Conflict resolution follows a priority order: deny beats require_approval beats allow.
Strengths: No single bottleneck. Agents can coordinate without a central orchestrator.
Tradeoffs: Harder to trace delegation chains. Requires strict trace propagation discipline. Policy conflicts are more likely.
An orchestrator manages workflow state but does not hold policy. A separate governance layer evaluates every agent action independently. The orchestrator sequences tasks; the governance layer decides what is allowed.
Strengths: Clean separation of concerns. Governance is framework-agnostic. Works with CrewAI, AutoGen, LangGraph, or custom orchestration.
Tradeoffs: Additional infrastructure (the governance service). Latency on every decision point.
The orchestrator-mediated pattern is the most common in production because it decouples governance from orchestration. You can swap frameworks (move from CrewAI to AutoGen, or from LangGraph to a custom orchestrator) without changing your governance layer. Cordum operates in this position: it evaluates actions regardless of which agent or framework submitted them.
Start with 2 agents sharing one policy
You do not need to design a complete fleet governance architecture on day one. Start small:
- 1. Pick two agents that already interact (one delegates to the other).
- 2. Write a single fleet policy with three rules: deny destructive actions, require approval for external writes, limit delegation depth to 2.
- 3. Add trace_id propagation to the delegation handoff between the two agents.
- 4. Run the workflow 10 times and query the audit trail by trace_id. Verify you can reconstruct the full decision tree.
- 5. Add a per-agent policy for the downstream agent that refines its permissions.
- 6. Expand to additional agents one at a time. Each new agent inherits the fleet policy automatically.
The key insight: fleet policy gives you coverage from day one. Every agent that connects to the governance layer is immediately subject to fleet-level rules. You only write per-agent rules when an agent needs role-specific behavior.
Frequently asked questions
Multi-agent system governance is the practice of enforcing policies, approvals, and audit trails across multiple autonomous agents that interact with each other. It extends single-agent governance to handle delegation chains, shared state, cross-agent side effects, and correlated audit logs.
Single-agent governance evaluates one agent at one decision point. Multi-agent governance must handle delegation chains (Agent A delegates to B delegates to C), policy inheritance (fleet rules plus per-agent overrides), cross-agent side effects (one agent's action affects another's state), and correlated audit trails linking decisions across multiple agents to one originating request.
A fleet policy is a set of governance rules that apply to every agent in a multi-agent system, regardless of the agent's role or framework. Fleet policies define boundaries like maximum delegation depth, blocked action types, and mandatory approval requirements. Per-agent policies can refine behavior within fleet boundaries but cannot override fleet denials.
By propagating trace context through every delegation handoff. Each agent action carries a trace_id (links all decisions to one request), workflow_id (identifies the workflow), parent_job_id (identifies who delegated), and delegation_depth (tracks chain length). Query tools can reconstruct the full decision tree from these fields.
Delegation depth is the number of agent-to-agent handoffs in a task chain. If Agent A delegates to B, which delegates to C, the delegation depth is 2. Limiting depth prevents unbounded delegation chains where accountability becomes untraceable and policy evaluation cost grows linearly with chain length.
Yes. Fleet governance operates at the action level, not the framework level. An orchestrator built with LangGraph can delegate to a worker built with CrewAI, and both are governed by the same fleet policy evaluated by an external governance layer. The governance layer sees actions and metadata, not framework internals.
When an agent action triggers a require_approval decision, the governance layer blocks execution and routes the approval request to a human. The approval record includes the trace_id, the delegation chain, the policy rule that triggered it, and the action details. Approvals are bound to the specific action and policy snapshot at submission time.
Cordum evaluates every agent action against versioned policy rules before execution, regardless of which agent submitted it or which framework runs it. Fleet policies and per-agent policies are layered with explicit conflict resolution. Trace context propagation links all decisions in a delegation chain to a single audit trail queryable by workflow_id or trace_id.
Next step
Pick your most complex multi-agent workflow. Map the delegation chain on paper. Identify which agent has the highest-risk action. Add a fleet policy rule that governs that one action across all agents. Then expand.