DEV Community

Cover image for Multi-Agent Orchestration Solves Coordination. It Doesn't Solve Governance.
Waxell profile image Logan
Logan for Waxell

Posted on Edited on Originally published at waxell.ai

Multi-Agent Orchestration Solves Coordination. It Doesn't Solve Governance.

#ai #llm #agents #governance

You've set up your multi-agent orchestration stack. A planner agent breaks down tasks. A researcher agent retrieves context. An executor agent takes action. They hand off to each other cleanly. The demo works.

Multi-agent governance is the infrastructure layer that defines what agents in a coordinated system are allowed to do, enforces those rules across the delegation hierarchy in real time, and produces an auditable record of every action — including the handoff events where one agent passes work to another. It is distinct from multi-agent orchestration, which defines how agents coordinate; governance defines what they're permitted to do while coordinating. Most teams in 2026 have the first and are missing the second.

Then you ship to production and start asking different questions: What happens when the executor agent takes an action you didn't anticipate? Which agent is responsible when something goes wrong across a three-step handoff? How do you enforce a policy that applies to agents system-wide, not just to one of them? Who — or what — is watching the whole thing?

These aren't orchestration questions. They're governance questions. And your orchestration framework doesn't answer them.

Multi-agent orchestration is the set of patterns and frameworks — LangGraph, CrewAI, AutoGen, Magentic-One, and others — that define how agents divide work, pass state, and communicate. It solves coordination: who does what, in what order, with what inputs. Multi-agent governance is the separate layer that defines what agents are allowed to do, enforces those rules across the hierarchy in real time, and produces an auditable record of every decision. The two problems are related. They are not the same problem.

What Does Multi-Agent Orchestration Actually Give You?

Orchestration frameworks exist to solve a real problem: single agents don't scale well across complex tasks. A single LLM session handling research, planning, execution, and synthesis simultaneously runs into context limits, performance bottlenecks, and reliability issues. Specialized agents — each doing one thing well, coordinated by an orchestrator — are more maintainable and more capable.

The interest is real. Gartner reports a 1,445% surge in enterprise inquiries about multiagent systems from Q1 2024 to Q2 2025. Microsoft described the January 2026 VS Code 1.109 release as further evolving the editor "to make it the home for multi-agent development." The architectural pattern — break a complex task into specialized sub-agents, coordinate through a shared orchestration layer — is becoming standard practice for serious agent deployments.

What orchestration gives you: task decomposition, agent routing, state passing, tool assignment, and sequence logic. These are all coordination primitives. The orchestrator knows who should act. It doesn't know — and wasn't designed to determine — what those agents should be allowed to do.

That distinction has a measurable cost. In Towards a Science of Scaling Agent Systems (arXiv, December 2025; revised April 2026), Kim et al. ran 260 controlled configurations across six agentic benchmarks, five architectures (single-agent plus Independent, Centralized, Decentralized, and Hybrid multi-agent), and three LLM families, standardizing tools, prompts, and compute to isolate the effect of architecture alone. Performance relative to a single-agent baseline ranged from +80.8% on decomposable financial reasoning to −70.0% on sequential planning. The authors' finding most relevant here: architectures without centralized verification tend to propagate errors more than those with centralized coordination. More agents is not the variable that determines outcomes. Whether anything sits above them checking their work is.

A second study points the same direction from a different angle. Cemri et al. (arXiv:2503.13657, revised October 2025) assembled MAST-Data — 1,600+ annotated traces across 7 popular multi-agent frameworks — and derived a failure taxonomy of 14 distinct failure modes in 3 categories: system design issues, inter-agent misalignment, and task verification. One of those three categories — inter-agent misalignment — describes failures that occur between agents rather than within one, which is precisely the region an orchestration framework routes work through without inspecting. Orchestration frameworks define the pipeline topology. They are not the layer that catches what goes wrong as work crosses it — which is the case for putting a circuit breaker between agents →.

Why Does Governance Get Harder When You Add More Agents?

With a single agent, governance is localized. You define rules, enforce them in one place, monitor one execution stream. Complex, but bounded.

Add a second agent and something changes. Now you have a trust boundary between agents. When the planner agent passes a task to the executor agent, the executor doesn't know the context that led to that instruction. It knows it received an instruction. If the planner was manipulated — through a malicious prompt in retrieved content, an unexpected input, a subtle reasoning failure — the executor carries out the resulting action without any mechanism to catch it.

This is the governance plane problem in multi-agent systems: policies that should apply system-wide can't be enforced by individual agents, because individual agents don't have system-wide context. The orchestrator knows the workflow topology. The agents know their individual tasks. Nobody has the elevated view required to enforce rules across the hierarchy.

The security community has now named these as distinct risk classes. The OWASP GenAI Security Project's Top 10 for Agentic Applications, published December 9, 2025, lists ASI07 — Insecure Inter-Agent Communication ("spoofed inter-agent messages misdirected entire clusters") and ASI08 — Cascading Failures ("false signals cascaded through automated pipelines with escalating impact") as separate entries from the single-agent risks above them. Neither is a defect in any one agent. Both are properties of the space between agents.

Three specific things that break as agent count grows:

Policy fragmentation. If you want to enforce a rule — "never take an irreversible action without logging it," or "never access customer PII in this workflow" — where does that rule live? In each agent's system prompt? You now have N places where it can be inconsistently applied, drift over time, or simply fail when a model reasons around it. Policies need to live outside the agents, enforced at the infrastructure layer.

Trace ambiguity. When an action produces an unexpected outcome in a single-agent system, debugging is linear. In a multi-agent system, the action may be three handoffs removed from its origin. Most observability tools — LangSmith, Arize, Helicone — are excellent at showing you what happened within an agent's execution. They're not designed to surface why a governance rule wasn't applied at step 2 of a 4-step hierarchy. Governance telemetry is a different data product than observability telemetry — a separation we take apart in the agentic architecture governance plane.

Blast radius. In a single-agent system, a runaway loop, an unexpected tool call, or a cost spike is bad. In a multi-agent system, a poorly constrained sub-agent can trigger cascading actions across other agents before any human notices — and the gap between "the actions started" and "a human noticed" is where the damage accumulates.

That gap now has a public, primary-sourced measurement. On July 16, 2026, Hugging Face published a security incident disclosure stating that it had detected and responded to an intrusion into part of its production infrastructure that was, in the company's own words, "driven, end to end, by an autonomous AI agent system." Per that disclosure, a malicious dataset abused two code-execution paths in Hugging Face's dataset processing to run code on a processing worker; the actor then escalated to node-level access, harvested cloud and cluster credentials, and moved laterally into several internal clusters over a weekend. Hugging Face describes the campaign as run by "an autonomous agent framework … executing many thousands of individual actions across a swarm of short-lived sandboxes, with self-migrating command-and-control staged on public services." Its forensic reconstruction ran over an attacker action log of more than 17,000 recorded events. Hugging Face states it does not know which model powered the attacker's agents.

Read that as an operating benchmark rather than as a verdict on any vendor. Seventeen thousand actions is the volume a coordinated agent swarm can execute inside one weekend. Retrospective review — however good, and Hugging Face's own account credits AI-assisted anomaly detection with surfacing the compromise — is arithmetic performed after that volume already exists. That is the difference between the ungoverned and the governed case, stated concretely: in the ungoverned case, the number of actions taken before anyone intervenes is bounded only by how fast the agents can act. In the governed case, it is bounded by a policy that fires before each action, and by a kill path that reaches the whole session graph rather than just the orchestrator — a distinction explored in why stopping the orchestrator doesn't stop the swarm →.

Containment is where most organizations report they are weakest. Kiteworks — itself a vendor in the AI data-governance category — reports in its own Data Security and Compliance Risk: 2026 Forecast Report that 60% of organizations cannot terminate a misbehaving AI agent, and 63% cannot enforce purpose limitations on one. Treat those as vendor-published survey figures rather than independent measurement, but the direction is consistent with what the incident data shows: the agent registry — a system of record for what agents exist, what they're allowed to do, and what they're currently doing — is a control surface, not a reporting convenience. Without it, you don't have a clean way to pause, inspect, or constrain individual agents in a running system.

What Does Cross-Agent Governance Actually Look Like?

Cross-agent policy enforcement means having a governance layer that sits above the orchestration layer — not inside any individual agent, not in the orchestrator's routing logic, but as a separate plane that agent execution passes through.

In practice, this layer does a few things:

It holds the canonical policy definitions. Waxell's platform provides 50+ policy categories out of the box — rules about what agents can access, what actions require logging, what cost ceilings apply, what triggers a human-review escalation — and Waxell Runtime gates each step of the high-risk workflows you build on Waxell. Policies live in one place and apply uniformly to the agents in the system, regardless of what the orchestrator told them to do.

It enforces at execution time, not prompt time. A rule embedded in a system prompt can be reasoned around. A rule enforced at the infrastructure layer via Waxell's policy engine, before a tool call fires or an action executes, cannot. Pre-execution enforcement is the meaningful distinction. Applying a new policy to a running agent system requires no rebuilds.

It produces a unified audit trail. Not one trace per agent, but one coherent record of what the system as a whole did: which agent acted, in what sequence, under which policy, with what inputs and outputs. Waxell Observe auto-instruments 200+ Python libraries with two lines of code, capturing cross-hierarchy execution traces from the moment you initialize it. When something goes wrong, you want to be able to answer "what happened at each step and was it within bounds?" — not reconstruct that from five separate agent logs. Logs are not an audit trail. The deeper breakdown of what multi-agent coordination failures look like without a connected trace is covered in our governance blind spot post.

It governs the agents you didn't write. Increasingly the "multi-agent system" is not one team's LangGraph app — it's a mix of agents you built and third-party or vendor agents working alongside them. Waxell Connect is built for that case: shared workspaces, an inbox and delegation model, and a presence and skills roster, so handoffs between agents that don't share a codebase are still recorded and still governed. No SDK or code changes required on the third-party side.

It provides a kill surface. If an agent in your system is behaving outside expected parameters — running up cost, making unexpected tool calls, looping — you need a mechanism to pause or constrain that specific agent without taking down the whole workflow. The governance plane is that surface.

Where Do Observability Tools Stop and Governance Begin?

This is worth naming explicitly because the tools overlap visually but serve different purposes.

Observability tools tell you what happened. They capture traces, log tool calls, surface latency and token usage. They're retrospective by design: you run the agent, collect the telemetry, analyze afterward. This is valuable, especially for debugging.

Governance is prospective. It defines what's allowed before execution, enforces those rules as execution proceeds, and acts — automatically — when something approaches or crosses a boundary. It's not passive logging. It's active constraint.

Teams that treat their observability stack as governance coverage are, at best, catching violations after they've happened. For a single agent running infrequently, this might be acceptable. For a multi-agent system running at any meaningful scale, catching violations retrospectively means the blast radius has already expanded.

The governance plane for multi-agent systems is a separate architectural concern from the observability layer. In well-architected agentic systems, both exist — and they serve different purposes. You can read more about how these two layers differ at the architectural level in the Waxell glossary. Which layer a given policy belongs in also depends on the agent's role in the topology; coordinator, planner, and worker agents carry different failure modes, as covered in why role-blind policies fail →.

Regulatory context — and a date that changed. Under the EU AI Act (Regulation (EU) 2024/1689), Annex III covers AI systems used in high-impact areas including credit, employment, education, and law enforcement, with obligations that include human oversight and record-keeping across the system's operation. The compliance date for those obligations moved. Regulation (EU) 2026/1744 of the European Parliament and of the Council of 8 July 2026 — the Digital Omnibus on AI, published in the Official Journal on 24 July 2026 and now in force — sets the date of application of Chapter III, Sections 1, 2 and 3 to 2 December 2027 for AI systems classified as high-risk under Article 6(2) and Annex III, and to 2 August 2028 for Annex I embedded-product systems. The two tracks moved by different amounts from different starting points, which is worth getting right: Annex III high-risk obligations were originally due 2 August 2026, so they slipped sixteen months. Article 6(1) — the Annex I embedded-product route — was always on the longer runway, due 2 August 2027 under Article 113(c) of the original Regulation, so it slipped twelve. This is enacted law, not a political agreement pending adoption. For teams building multi-agent systems in these sectors, the legal date moved; the engineering requirement did not. The NIST AI Risk Management Framework (AI RMF 1.0) remains the working reference in the interim, and its Manage function assumes exactly the kind of connected, cross-agent execution record that per-agent observability logs don't produce.

Orchestration frameworks have done something genuinely useful: they've made multi-agent systems buildable. The patterns are maturing, the tooling is improving, the demos are compelling. The piece that's still missing for most teams is the governance layer that makes these systems safe to run at production scale — with policies that hold across the hierarchy, audit trails that span the full workflow, and a control surface that works when things go sideways.

The more agents you add, the more this gap matters.

Originally published on the Waxell blog.

How Waxell handles this: Waxell's policy engine holds 50+ policy categories in one place and applies them to agents across a multi-agent system — not inside individual agent prompts. Policies are evaluated before execution fires and require no rebuilds to update; Waxell Runtime applies that evaluation at each step of the high-risk workflows you build on Waxell. Waxell Observe instruments the hierarchy: the agent registry gives you a live system of record for what's running and what it's been delegated to do, while execution traces span agent hierarchies — parent-to-child delegation events are captured, context passed at each handoff is recorded, and the graph is queryable as a connected structure. Where the coordinating agents aren't all yours, Waxell Connect provides the shared workspace, delegation model and agent roster those handoffs run through. Start free with Waxell Observe and one governed MCP upstream →

FAQ

What is multi-agent orchestration?
Multi-agent orchestration is the set of patterns and frameworks used to coordinate multiple AI agents toward a shared goal. An orchestrator assigns tasks to specialized sub-agents, manages state passing between them, and sequences their actions. Common frameworks include LangGraph, CrewAI, AutoGen, and Magentic-One. Orchestration solves coordination — who does what and in what order — but does not address what agents are allowed to do or how policy is enforced across the system.

What's the difference between multi-agent orchestration and multi-agent governance?
Orchestration is about coordination: task routing, state sharing, agent sequencing. Governance is about control: defining what agents are permitted to do, enforcing those rules at the infrastructure layer, and producing an auditable record of every action. In a well-designed multi-agent system, both exist as separate layers. The orchestrator doesn't enforce policy; the governance plane does.

Why is governance harder in multi-agent systems than in single-agent systems?
Three reasons. First, policy fragmentation: rules embedded in individual agent prompts can't be uniformly enforced across a hierarchy of agents. Second, trace ambiguity: an unexpected action may be three handoffs removed from its origin, making root cause analysis difficult without cross-agent execution logs. Third, blast radius: a poorly constrained sub-agent can trigger cascading actions across other agents. Kim et al.'s December 2025 scaling study found that architectures without centralized verification tend to propagate errors more than those with centralized coordination — the structural argument for a layer above the agents.

What happens when one agent in a multi-agent system gets compromised?
This is the risk class OWASP catalogues as ASI08 — Cascading Failures: a false signal or bad output from one agent propagates through automated pipelines with escalating impact, alongside ASI07 — Insecure Inter-Agent Communication, where spoofed messages between agents misdirect a whole cluster. The mechanism is that a receiving agent has no independent way to verify what a sending agent produced; it treats the handoff as authoritative. Containing this requires verification at the handoff boundary and a kill path that reaches every agent in the session graph, not just the orchestrator that dispatched them.

Do observability tools like LangSmith or Arize cover multi-agent governance?
No — observability and governance serve different purposes. Observability tools capture what happened: traces, latency, token usage, tool calls. They're retrospective. Governance enforces what's allowed before and during execution. An observability stack without a governance layer means you catch policy violations after the fact. For multi-agent systems at scale, retrospective-only monitoring isn't sufficient — and it doesn't produce the connected, cross-agent execution record that EU AI Act Annex III record-keeping obligations assume.

What is a governance plane in the context of multi-agent systems?
A governance plane is the infrastructure layer that sits above the orchestration layer, holding policy definitions and enforcing them consistently across the agents in the system. Unlike per-agent governance embedded in system prompts, a governance plane applies rules at execution time — before actions fire — regardless of what any individual agent's instructions say. It also provides the unified audit trail and control surface needed to manage a multi-agent system safely in production.

How do you enforce policy across multiple agents without putting it in every agent's prompt?
By enforcing at the infrastructure layer, not the prompt layer. Policies defined in a governance plane are applied as execution passes through that layer — they don't rely on the agent choosing to comply. This means rules are consistently applied regardless of how an agent was instructed, what context it was given, or how it's reasoning at that moment. Pre-execution enforcement at the infrastructure layer is the meaningful mechanism; post-hoc review of agent outputs is not the same thing.

What does the EU AI Act require for multi-agent AI systems, and when?
Under the EU AI Act, AI systems used in high-risk application areas listed in Annex III — including credit scoring, employment decisions, law enforcement, and critical infrastructure — carry obligations including human oversight and record-keeping across the system's operation. The date those obligations apply changed: Regulation (EU) 2026/1744 of 8 July 2026 (the Digital Omnibus on AI), published in the Official Journal on 24 July 2026 and in force, moved the application of Chapter III Sections 1–3 to 2 December 2027 for Annex III high-risk systems and to 2 August 2028 for Annex I embedded-product systems. The starting points differed: Annex III was previously due 2 August 2026, while Annex I embedded-product systems were previously due 2 August 2027 under Article 113(c) of the original Regulation — a sixteen-month slip and a twelve-month slip respectively, not a single common deferral. For multi-agent systems, the practical implication is that the record must span the delegation hierarchy, not just individual agent sessions — and that the extra time is build time, not a reason to defer the build.

Sources

Top comments (1)

Some comments may only be visible to logged-in visitors. Sign in to view all comments.