Multi-Agent AI: Every Handoff Is a Permission Decision

Multi-agent AI is one job split across several specialised AI agents that pass work, context and authority between each other under a coordination pattern. You get parallelism and specialisation. You pay in tokens, in latency, and in a much larger number of places where a permission decision has to be made.

Our position at LeapForce is that the second cost is the one teams keep underestimating. Almost every article on this topic treats a multi-agent system as an org chart problem: pick a planner, pick executors, pick an evaluator, draw the boxes. The failures we see reported in public are not box-shaped. They happen on the arrows. When a coordinator delegates to a sub-agent, the task travels. So, in most implementations, does the authority, silently, because the sub-agent reuses the caller's credential. The unit worth designing is the hand-off, not the agent.

Someone asked this precise question on Hacker News in June 2025, and the explainer literature on this topic still mostly steps around it. The commenter helsinki wrote: "Has anyone solved scoped permissions in multi-agent systems?" They laid out an ordinary four-step job: find a GitHub issue, fix and push it, update Jira, post to Slack. Then they asked the question that breaks it: with the same orchestrator available to 1,000 users at a company, how does the system obtain each individual user's GitHub, Jira and Slack permissions, hands-free, from one approval? That is not an exotic edge case. It is the shape of nearly every useful enterprise multi-agent system, and the answer is architectural.

The short answer: Build a multi-agent system when the job has genuinely parallel sub-tasks and enough value per run to absorb roughly an order of magnitude more token spend; govern it at the hand-off, because every arrow between two agents is a permission decision, a cost-attribution decision and an audit record all at once.

Last updated: July 30, 2026.

The governed unit in a multi-agent system is the edge between two agents, not the agent itself.

What multi-agent AI is, in one paragraph

Multi-agent AI is an architecture in which several agents driven by a large language model, each with its own instructions, tools and context, coordinate on one job. A typical run goes: intake of a goal, task decomposition into sub-tasks, delegation to specialists, parallel or sequential execution, synthesis of the partial results, and a validation pass before anything is finalised. The LangChain multi-agent docs frame the motivation in three words: context management, distributed development, parallelisation. Then they add a caveat most vendor explainers leave out: "not every complex task requires this approach", because one agent with the right tools and prompt often gets there too.

The word "agent" is doing a lot of work there, so it is worth pinning down. In this article an agent means a model given a goal, a set of tools it may call, and enough autonomy to decide the order of its own calls. Multi-agent systems are what you get when more than one of those exists in a single run and they are allowed to invoke or inform each other. That is the whole definition. Everything interesting is in how they are wired.

The wiring has a vocabulary worth fixing now. A coordinator (supervisor, planner, lead agent) decomposes and delegates. Specialists (workers, executors) do bounded work. An evaluator or checker validates output before it is released. A hand-off is the moment one agent passes control, state or both to another. Frameworks name these differently, and the naming matters far less than the fact that each hand-off is a real event that can be logged, priced and authorised, or not.

What multi-agent AI is not

It is not a swarm of independent minds. The agents in a production multi-agent system are, almost always, the same base model with different prompts, tools and context windows. Anthropic's engineering team described their production architecture as an orchestrator-worker pattern where "a lead agent coordinates the process while delegating to specialized subagents that operate in parallel," in How we built our multi-agent research system. That is division of labour, not a society.

It is not automatically better than one agent. The academic evidence is unkind here, and we cover it in the next section.

It is not the same as microservices, though the analogy is close enough to be dangerous. A microservice has a fixed contract; an agent has a goal and discretion, so two identical requests can produce different tool calls. Schema validation, retries and circuit breakers remain necessary and stop being sufficient, because the failure you are guarding against is a plausible wrong decision rather than a malformed payload.

It is not a security boundary. This is the one that costs money. Splitting a job across four agents does not, by itself, split the permissions across four agents. If the coordinator holds a token and passes it down, you have one privilege domain wearing four hats. The OWASP Gen AI Security Project's Top 10 for Agentic Applications, published 9 December 2025, lists Identity and Privilege Abuse at ASI03 and describes the pattern plainly: "leaked credentials let them operate far beyond their intended scope."

It is not a governance model. A governance model tells you who approved what, who is accountable, and what happens on dissent. A June 2026 gap analysis of the interoperability protocols found that none of them encode this. Kang and Diponegoro scored MCP, A2A, ACP, ANP and ERC-8004 against a six-dimension governance taxonomy: membership, deliberation, voting, dissent preservation, human escalation, and audit and replay. They found voting and dissent preservation "universally absent" across all five, with deliberation absent or at best partial. Their conclusion is the one we would endorse: agent-community governance is "a missing architectural layer", not a missing feature.

Does multi-agent AI actually work? The evidence points both ways

The honest answer in mid-2026 is that multi-agent AI produces large wins on a narrow class of tasks and reliably disappoints outside it, and the published evidence is genuinely contested rather than merely immature.

On the positive side, Anthropic reported that "a multi-agent system with Claude Opus 4 as the lead agent and Claude Sonnet 4 subagents outperformed single-agent Claude Opus 4 by 90.2%" on their internal research evaluation. That is a big number and it comes from a team running the architecture in production. It is also, importantly, an internal eval on open-ended research, which is close to the ideal case: many independent lines of enquiry, easy to fan out, easy to synthesise.

On the negative side sits the most systematic study of multi-agent failure to date. A UC Berkeley-led team built MAST, the first Multi-Agent System Failure Taxonomy, from 1,600-plus annotated execution traces across seven popular multi-agent frameworks. Their opening line is blunt: "Despite enthusiasm for Multi-Agent LLM Systems (MAS), their performance gains on popular benchmarks are often minimal." The taxonomy "identifies 14 unique modes, clustered into 3 categories": system design issues, inter-agent misalignment, and task verification. Inter-annotator agreement was kappa = 0.88.

Between those two poles sits an argument from a company that builds coding agents for a living. In Don't Build Multi-Agents (12 June 2025), Cognition's Walden Yan set out two principles: "Share context, and share full agent traces, not just individual messages," and "Actions carry implicit decisions, and conflicting decisions carry bad results." His diagnosis of why parallel sub-agents produce incoherent output is that "the decision-making ends up being too dispersed and context isn't able to be shared thoroughly enough between the agents."

Anthropic agrees about the boundary condition even while reporting the win. Domains where every agent needs the same context, or where dependencies between agents are dense, are described as "not a good fit for multi-agent systems today", with coding named as the example: fewer genuinely parallelisable sub-tasks than research has.

All four point at one boundary. Multi-agent collaboration pays off where sub-tasks are genuinely independent and each agent's context can stay narrow, and fails where sub-tasks share state, because keeping several agents consistent costs more than running them at once saves.

Here is the UC Berkeley authors presenting the MAST work and taking questions on it, which is the most detailed public discussion of the failure data we found:

Count the edges, not the agents

The number people quote when describing a multi-agent system is the number of agents. It is the wrong number. What determines both the coordination difficulty and the governance surface is the number of edges, the directed connections along which work, context or authority moves.

Do this arithmetic before you build. It takes ten minutes and it changes conversations.

Then add the edges nobody counts, which are usually the majority: every agent-to-tool call, every agent-to-datastore read, every agent-to-external-API write. A six-specialist coordinator system where each specialist touches two tools has 12 agent-to-agent edges and 12 tool edges, so 24 governed connections behind a diagram that showed seven boxes.

We call the exercise the Edge Census, and it has one rule: an edge exists if information or authority can cross it, whether or not your diagram drew it. Shared memory counts, including the classic blackboard pattern where agents read and write a common workspace instead of messaging each other. A scratchpad file both agents can write counts. A message bus counts.

Two things follow from the census. First, the mesh topology that sounds most flexible is the one that scales worst. At six agents it carries two and a half times the surface of a coordinator pattern, and every one of those edges is a place where a spoofed or malformed message can enter. OWASP ranks Insecure Inter-Agent Communication at ASI07, noting cases where "spoofed inter-agent messages misdirected entire clusters."

Second, the census tells you how much governance work you have actually signed up for, because each edge needs the same five answers. It is also the honest measure of scalability in a multi-agent design: a system scales when adding an agent adds a small, bounded number of edges, and it does not when the count grows quadratically.

The Handoff Contract: five fields for every edge

Here is the framework this article exists to give you, and it is the only piece of multi-agent AI design we would call non-negotiable. For every edge in your census, five fields must be filled in. We call the filled set a Handoff Contract. It is deliberately small enough to fit on one line of a spreadsheet, because a governance artefact nobody maintains is worse than none.

Three of those five deserve elaboration, because they are where the real design decisions live.

Acting as is the field people get wrong. There are three defensible answers and one indefensible one. The receiving agent can act under its own non-human identity (best for autonomous background work, because the audit trail names a thing that has an owner); it can act under a delegated, downscoped user identity (best when the action's legitimacy depends on who asked, as in the Hacker News scenario above); or it can act under a shared service account that is deliberately low-privilege (acceptable for read-only enrichment). The indefensible answer is that the receiving agent silently reuses the caller's full credential, which is what happens by default in most quick implementations. The identity model that makes the first option workable — owner, scope and expiry on every non-human actor — is the subject of our earlier analysis of non-human identity for AI agents.

The relevant standards have already reached this conclusion for tool calls. The Model Context Protocol authorization specification states that "MCP servers MUST validate that access tokens were issued specifically for them as the intended audience," and, on the delegation question directly: "The MCP server MUST NOT pass through the token it received from the MCP client." That is the same principle applied one layer down. Authority is re-issued at each boundary; it does not travel.

Re-check is where human oversight becomes real rather than aspirational. Most articles recommend "human-in-the-loop checkpoints" without saying which step. The useful rule is that the gate belongs immediately before the first irreversible external effect, not at the end of the run. A validation pass at the end tells you what already happened. A gate before the write is the only one that can stop it.

Charge is the field that turns a cost surprise into a line item. In a fan-out, one user request becomes a dozen billed model calls, and if they are all attributed to the orchestrator, nobody can tell you which specialist is expensive. Attribution is a design-time decision: the budget identifier has to be part of the hand-off payload, or it cannot be reconstructed afterwards.

Where does the contract physically live? Three places, and you want all three eventually. At design time it is a table in the pull request that adds the edge, which is enough to make the omissions visible during review. At run time it is policy in whatever component sits in the delegation path: the router, the gateway, or the runtime that issues the receiving agent's token. And after the fact it is a row in the audit log, because a control you cannot evidence is a control you cannot demonstrate. Teams that only do the first get a design document. Teams that only do the second cannot prove anything to an auditor.

A useful field test: pick any edge in a system you already run and try to fill in all five fields from your logs. Caller and Scope are usually recoverable. Acting as and Charge are the two we would expect to come back blank, because neither is something a framework fills in for you.

A worked example: the invoice-exception chain

Abstractions about edges are easy to nod along to, so here is one complete chain with the contracts filled in. The job: an accounts-payable exception queue where invoices that fail automatic matching are triaged, researched, and either corrected or escalated.

Four agents:

1. Coordinator — reads the exception, decides which specialists to call, synthesises the outcome.
2. Retriever — pulls the purchase order, the goods-receipt note and prior invoices from the document store.
3. Resolver — proposes and applies a correction: adjust a ledger entry, or draft a query email to the supplier.
4. Checker — validates the proposed correction against the approvals policy before anything is written.

The Edge Census gives six agent-to-agent edges (three down, three back) plus seven tool and data edges: document store read, ERP read, ledger write, email send, policy-rules read, audit-log write, and the notification channel. Thirteen governed connections behind a four-box diagram.

Now the contracts on the three most consequential edges.

Three design decisions are doing the work here, and none of them are about the model.

The Resolver is the only agent that can write, and its scope is narrower than the job. It cannot write any ledger entry; it can write the one attached to this exception. Every other agent is read-only. This is the single most consequential decision in a multi-agent design, and it is available regardless of which framework you use.

The Checker cannot be overruled by the agent it checks. In a naive implementation the Resolver receives the Checker's rejection as a message and gets to decide what to do about it, which is not a control. Making the rejection terminal at the orchestration layer converts an opinion into a gate.

The human gate sits before the write, not after the run. Above the threshold, the chain pauses. The reviewer sees the proposed diff, the retrieved evidence and the policy citation, and approves or rejects. Afterwards is too late; the money has moved.

The pattern this example follows is what the field calls planner-executor-evaluator, with the addition that the evaluator's verdict is enforced structurally. It maps cleanly onto the human oversight the EU AI Act requires of high-risk systems, which we return to below.

What multi-agent AI costs, in tokens and in dollars

Multi-agent architectures are expensive in a way that is easy to under-model, because the extra inference cost is not one big line item but many small ones. Anthropic gave the clearest public anchor we have found: "Agents typically use about 4x more tokens than chat interactions, and multi-agent systems use about 15x more tokens than chats."

That is a ratio, not a price. Here is the price, using Anthropic's published API rates as fetched on 30 July 2026, for the invoice-exception chain above. Treat this as a costing model with stated assumptions, not a measurement of a running system.

Assumptions: Coordinator on Claude Opus 5 ($5 per million input tokens, $25 per million output). Specialists on Claude Sonnet 5 ($2 in, $10 out under the introductory rate in effect through 31 August 2026). Single-agent baseline: one Sonnet 5 agent handling the whole exception with 25,000 input and 3,000 output tokens.

That is 9.1 times the single-agent cost for a four-agent chain with one retry, which sits below Anthropic's 15x figure precisely because the fan-out here is small and bounded. Scale it and the number stops being trivial:

Two things move this materially. Anthropic's published pricing notes that Sonnet 5's introductory rate of $2 and $10 per million tokens runs through 31 August 2026, after which it becomes $3 and $15 — which raises the multi-agent total in this model to $0.87 and the single-agent baseline to $0.12. And prompt caching changes the shape entirely: cache reads are billed at 0.1x the base input rate, and in a coordinator pattern the same system prompt and retrieved context are re-sent to several specialists, which is close to the ideal caching case.

The governance point is that none of this is visible unless the Charge field is populated at the edge. A $175,000 annual line item that appears as one undifferentiated API bill cannot be optimised, because you cannot see that the Coordinator's two Opus passes are 62% of the per-run cost. We have written separately on the mechanics of choosing cheaper models per task in our earlier analysis of how model routing cuts LLM costs.

Before anyone signs off on that, do the break-even in the other direction. The extra cost in this model is $0.65 per exception. An analyst on a fully loaded $40 per hour costs about $0.67 a minute, so the multi-agent version has to save more than roughly one minute of human handling per exception to pay for itself on labour alone. That is before you count accuracy, or the cost of the errors it prevents. That is a low bar for a genuinely hard exception and an impossible one for a routine match. Substitute your own token counts and your own loaded rate; the arithmetic is the point, not our numbers.

There is also a cost that does not appear on any bill. Each hand-off adds latency, and in a sequential chain the latencies compound. A four-step chain where each agent takes six seconds is a 24-second response before any tool call resolves. For a background queue that is fine. For anything a person is waiting on, it is the whole user experience.

Three coordination shapes and what each does to authority

Most explainers name three architectures, hierarchical, peer-to-peer and hybrid, then stop at how work flows. The more useful question is what each shape does to authority, because that is what determines your blast radius.

The same three agents, wired three ways: the control-flow difference is modest, the authority difference is not.

Hierarchical, or coordinator-led. One agent decomposes and delegates; specialists report back. CrewAI implements this as a hierarchical process where, per the CrewAI process documentation, "a manager language model (manager_llm) or a custom manager agent (manager_agent) must be specified" and "the manager allocates tasks to agents based on their capabilities, reviews outputs, and assesses task completion."

Authority effect: the coordinator becomes the single most privileged component in the system, because it must at minimum be able to invoke everything. That concentration is a feature for audit, since there is one place to log delegation decisions. It is also a liability for compromise. If the coordinator's goal can be hijacked, everything downstream inherits the hijacked intent. OWASP puts Agent Goal Hijack at ASI01 for exactly this reason.

Best for: jobs with a clear decomposition and specialists that do not need to talk to each other.

Peer-to-peer, or decentralised. Agents hand off directly to whichever peer is relevant. LangChain documents this as the Handoffs pattern, where "behavior changes dynamically based on state" and a tool call updates a state variable that triggers the routing change.

Authority effect: worst case. Every peer channel is an edge that must carry its own contract, and the permission set tends to converge on the union of all agents' permissions unless you actively prevent it. This is the topology where the n(n-1) arithmetic bites.

Best for: small numbers of agents with genuinely different competences and no shared write surface.

Hybrid, or routed. A routing step classifies the request and dispatches it to a sub-team, which may itself be hierarchical. LangChain's Router pattern has "a routing step" classify the input and direct it to one or more specialised agents, then synthesise the results. Microsoft's Agent Framework supplies the same capability as graph-based workflows with "type-safe routing, checkpointing, and human-in-the-loop support."

Authority effect: best, if you exploit it. A router is a natural policy enforcement point: it is the one component that sees every request before dispatch, so it is where scope narrowing, budget assignment and human-gate decisions can be applied once rather than n times.

Best for: most enterprise deployments, in our view, precisely because the routing layer gives you somewhere to put the controls.

Multi-agent AI frameworks: what they give you, what they leave to you

The most common mistake in framework write-ups is ranking orchestration libraries and managed platforms in one table. They answer different questions. A library answers "how do I express the graph?" A managed runtime answers "who runs it, and under what identity?" You need both answers, and choosing one does not choose the other.

Prices below were fetched on 30 July 2026 and change often. Verify before you budget.

Layer one: orchestration libraries

LangChain and LangGraph

• Best for: teams that want explicit control over the execution graph, including deterministic steps mixed with agentic ones.
• Key features: five documented multi-agent patterns: subagents, handoffs, skills, router and custom workflow. Hand-offs are expressed by returning a Command object that combines control flow with a state update, so routing and state are one operation.
• Limitations: large surface area, and documentation that moves fast enough that several URLs we had bookmarked from earlier in 2026 now 404.
• Pricing: the libraries are open source. LangSmith, the observability and deployment layer, is $0 per seat on Developer with up to 5,000 traces monthly, $39 per seat per month on Plus with up to 10,000 traces, then usage-based at $1.50 per LangChain Compute Unit and $1.00 per LangChain Storage Unit, per the LangSmith pricing page.
• What it leaves to you: per-agent identity, scope enforcement at the tool boundary, and spend attribution across a fan-out.

CrewAI

• Best for: role-first designs where the mental model is a team with job titles.
• Key features: sequential and hierarchical processes; a manager agent or manager LLM that allocates tasks, reviews outputs and assesses completion.
• Limitations: the manager's allocation is model-driven, which is flexible and also means delegation decisions are non-deterministic; treat them as decisions to be logged, not as configuration.
• Pricing: open-source framework.
• What it leaves to you: everything in the Acting as and Scope columns. The manager decides who does the work, not what they are allowed to touch.

OpenAI Agents SDK

• Best for: teams already on OpenAI models that want a small primitive set rather than a graph DSL.
• Key features: agents, handoffs ("a powerful mechanism for coordinating and delegating work across multiple agents"), guardrails that "run input validation and safety checks in parallel with agent execution, and fail fast when checks do not pass", sessions and built-in tracing, per the OpenAI Agents SDK documentation.
• Limitations: guardrails are input and output validation, which is a different control from authorisation. A guardrail can catch a bad payload; it does not decide whether this agent may write to that system.
• Pricing: open-source SDK; you pay model and tool usage.
• What it leaves to you: identity and budget. The tracing is genuinely useful and is the closest thing here to a native audit stream.

Microsoft Agent Framework

• Best for: .NET and Python shops in the Microsoft ecosystem, and anyone migrating off AutoGen or Semantic Kernel.
• Key features: Microsoft describes it as "the direct successor" to both, pairing AutoGen's single- and multi-agent abstractions with Semantic Kernel's session state, type safety, filters and telemetry. Graph-based workflows add checkpointing and human-in-the-loop support.
• Limitations: the Go implementation is in public preview at time of writing, with declarative agents, RAG, CodeAct and functional workflows not yet available.
• Pricing: open source; costs land on the model and hosting side.
• What it leaves to you: the same identity question, though the checkpointing and human-in-the-loop primitives make the Re-check field much easier to implement honestly.

Layer two: managed agent runtimes

Amazon Bedrock AgentCore

• Best for: teams that want per-agent identity and a tool gateway as managed infrastructure rather than as code they maintain.
• Key features: separate Runtime, Gateway, Memory, Identity and Observability components, so the authority concerns are addressable as services rather than as conventions.
• Limitations: it is AWS-shaped, and the metering has several dimensions, which makes cost modelling harder than a per-seat price.
• Pricing, per the AgentCore pricing page: Runtime at $0.0895 per vCPU-hour and $0.00945 per GB-hour; Gateway at $0.005 per 1,000 API invocations and $0.025 per 1,000 search invocations; Identity at $0.010 per 1,000 token or API-key requests, and at "no additional charge" when used through Runtime or Gateway; short-term memory at $0.25 per 1,000 new events. Observability bills through CloudWatch.
• What it leaves to you: policy. The runtime can give an agent its own identity; deciding what that identity may do on each edge is still your design.

The row that matters is the identity column. Four of the five are libraries that, by design, hold no opinion about who your agents are. That is the correct scope for a library, and it does mean the Acting as field is unowned unless something else owns it.

Security in multi-agent AI: what the protocols cannot express

Security in multi-agent AI is usually presented as three bullets: scope permissions, validate inter-agent messages, keep a human in the loop. All three are correct and none are operational as stated. Here is what the current standards actually require, and where they stop.

The tool boundary is well specified. MCP's authorization spec is prescriptive about the confused-deputy problem: servers "MUST only accept tokens specifically intended for themselves", clients "MUST implement Resource Indicators for OAuth 2.0 as defined in RFC 8707", and a server acting as a client to an upstream API "MUST NOT pass through the token it received from the MCP client." If you implement nothing else from this article, implement that, because it forecloses the most common privilege-escalation path in a tool-using chain. We have written on the wider connector picture in our earlier analysis of MCP server security.

The agent-to-agent boundary is less well specified. Google's Agent2Agent protocol moved to the Linux Foundation on 23 June 2025, with AWS, Cisco, Salesforce, SAP, Microsoft and ServiceNow among the companies quoted in the Linux Foundation announcement. Its central discovery artefact is the Agent Card, which the A2A specification defines as a JSON metadata document describing a server's "identity, capabilities, skills, service endpoint, and authentication requirements", with a section devoted to Agent Card signing. But declaring which authentication scheme you accept is not the same as making an authorisation decision, and the spec has the client obtain credentials out of band, which leaves the interesting part to implementers.

And the governance boundary is not specified at all. This is the finding worth carrying away. Two independent 2026 analyses reached compatible conclusions from different directions. The interoperability gap analysis cited earlier found voting, dissent preservation and deliberation absent across five protocols. Separately, a March 2026 study characterising the multi-agent threat landscape evaluated 16 AI security frameworks against 193 distinct threat items in nine risk categories, and reported that the OWASP Agentic Security Initiative achieved the highest coverage at 65.3%, while "no reviewed framework achieves majority coverage of any single category" (Nguyen, Ndebugre and Arremsetty). The least-covered categories were non-determinism and data leakage.

The practical reading of that is not "the standards are useless." It is that the standards cover the wire format and the token, and leave the policy to you, which is exactly where the Handoff Contract's Acting as, Scope and Re-check fields go.

OWASP's Top 10 for Agentic Applications gives the risk vocabulary an enterprise security team will recognise. Four of the ten are specifically multi-agent concerns:

Cascading failure is the one that scales with your edge count, and it has a structural containment rather than a detection one. If only one agent in a chain holds write scope, a bad state propagating through four reasoners still ends at a single narrow exit, and the checker's rejection at that exit is terminal. Detection tooling helps you find out afterwards. Write-scope minimisation is what decides how much there is to find out about.

Public sector bodies are moving on the same problem. The US NCCoE published a concept paper, Accelerating the Adoption of Software and AI Agent Identity and Authorization, which as of this writing shows status "reviewing comments". Its framing matches ours. Agents are described as systems that decide and act autonomously "with limited human supervision", and the scale of their actions "has the potential to increase exponentially." The proposal is to apply existing identity standards to them rather than invent new ones, which is the right instinct and also a quiet admission that most deployments have not done it.

Here is a conference talk that goes deeper on the authorisation model than we can here, from a security engineer working on exactly this problem:

Proving what happened when no single agent owns the decision

Distributed decisions create an accountability problem that tracing alone does not solve. A practitioner put it precisely on Hacker News in March 2026. Discussing the hardest failures to debug, chirdeeps wrote that the worst case is not a hallucination at all: one agent does its job correctly, hands slightly malformed state to the next, and that one confidently executes something destructive on the strength of it. Then the sentence that names the gap: "Tracing doesn't solve this because it just shows you the execution path."

That distinction is the whole audit design. A trace answers what ran. An audit record has to answer what was permitted, by whom, and on what basis. They are different records with different retention requirements and different readers.

Most treatments of multi-agent AI mention the explainability problem in a sentence and move on: once a decision is distributed across several reasoners, no single model's output explains it. That is true and it is also the wrong framing for an enterprise. You are rarely asked to explain the model's reasoning. You are asked who authorised the action, which is a question about records, and records are something you control.

Concretely, a multi-agent audit trail that survives a regulator or an incident review needs six things per hand-off:

The fourth row is the one most implementations miss. If your log records only what ran, you cannot demonstrate that anything was ever prevented, which is precisely what an auditor asks. This is a theme we have developed at more length in our earlier analysis of AI observability and audit trails.

The regulatory expectations point the same way. The EU AI Act's Article 12 requires that high-risk AI systems "technically allow for the automatic recording of events (logs) over the lifetime of the system." Article 14 requires that such systems "be designed and developed in such a way ... that they can be effectively overseen by natural persons during the period in which they are in use," with the human overseer able to "decide ... not to use the high-risk AI system or to otherwise disregard, override or reverse the output."

Read those two together in a multi-agent context and a design constraint falls out. The overseer must be able to override the output, which means the output has to reach a human before it becomes an effect, and the logs have to make the chain legible enough that overriding is an informed act rather than a coin flip. A 40-step trace across six agents is not legible. A per-edge record with five fields is. For the wider compliance timeline we maintain our earlier analysis of EU AI Act obligations for deployers.

When not to build a multi-agent system

Adoption data suggests most organisations are not close to needing this. McKinsey's State of AI survey, published 5 November 2025 and fielded from 1,993 respondents across 105 nations between 25 June and 29 July 2025, found that 23% of respondents report their organisations are scaling an agentic AI system somewhere in the enterprise, with a further 39% experimenting. But "in any given business function, no more than 10 percent of respondents say their organizations are scaling AI agents." Single agents are not a solved problem yet at most companies.

Gartner's June 2025 prediction that "over 40% of agentic AI projects will be canceled by the end of 2027, due to escalating costs, unclear business value or inadequate risk controls" names three causes, and multi-agent architectures make all three worse before they make anything better.

Use this as a decision rule. Do not build multi-agent when:

The sub-tasks share state. This is the Cognition argument and Anthropic's own caveat, and they agree. If agent two's correct behaviour depends on a decision agent one made implicitly, splitting them creates a synchronisation problem you will spend more effort solving than the original task took.

A function would do. Microsoft's own documentation says it flatly: "If you can write a function to handle the task, do that instead of using an AI agent." Extend that: if you can write a workflow with deterministic steps, write the workflow and put agents only in the steps that need judgement.

The job is latency-sensitive and sequential. Four agents in a chain is four round trips before the first useful output.

You cannot yet answer the Handoff Contract for a single edge. If you cannot say which identity the second agent acts under, you are not ready to add a third.

The value per run is low. Anthropic's framing is the right economic test: multi-agent systems "require tasks where the value of the task is high enough to pay for the increased performance." At 9x to 15x the token cost, a task worth cents does not qualify.

The alternative that usually wins is a single agent with better context engineering and a tighter tool set. It is less impressive on a slide and it fails in ways you can debug.

Where this analysis is uncertain

Several things in this article are weaker than the confident register of the genre would suggest, and it is worth being explicit about which.

We have not run a controlled multi-agent benchmark ourselves. Everything quantitative here is either cited to its source or is arithmetic over published prices, clearly labelled as a model. The invoice-exception costing is an illustration built from Anthropic's published rates and our stated token assumptions, not a measurement of a system in production. Treat the ratios as directionally useful and the absolute numbers as yours to re-derive with your own token counts.

The two headline studies measure different things. Anthropic's 90.2% is an internal evaluation on open-ended research, by the team that built the system, on the task type most favourable to fan-out. MAST's finding of minimal benchmark gains covers 1,600-plus traces across seven frameworks on public benchmarks. Neither is a controlled comparison of the same task under both architectures at enterprise scale, and we are not aware of one that is.

The security literature is young and moving. The multi-agent threat characterisation we cite is a March 2026 preprint; the interoperability gap analysis is from June 2026. Preprints are not peer-reviewed. We cite them because the systematic work in this area is currently happening in preprints, and we flag it so you can weight it accordingly.

The regulatory picture is unsettled for multi-agent specifically. The EU AI Act's obligations attach to systems and roles, not to hand-offs, and how a chain of agents is classified when several providers contribute components is not something we would state with confidence. NIST's control overlays for single-agent and multi-agent deployments were still in development at the time of writing.

Reddit was unreachable for this research. Its JSON endpoints returned 403 to our requests, so every practitioner voice quoted here comes from Hacker News, which skews toward engineers building agent infrastructure rather than the operations and compliance staff who inherit these systems. That is a real sampling bias and it probably makes the practitioner concerns in this article more technical than the average enterprise experience.

The Handoff Contract is a framework we are proposing, not a standard. It is not endorsed by OWASP, NIST or anyone else. Its value, if it has any, is that it is short enough to actually be filled in.

Where LeapForce fits

Everything above is architecture-neutral. If you take one thing from this article, take the Edge Census and the five fields; they work with LangGraph, with CrewAI, with a hand-rolled orchestrator, and with no framework at all.

The layer LeapForce builds is the one the frameworks deliberately leave empty: who these agents are, what they may touch, what they did, and what they cost. Three parts of our platform map directly onto the Handoff Contract. Access and Identity treats non-human identities as first class, so Acting as has an answer that is not "the caller's token". Every agent gets a named owner, a scope and an expiry. AI Coworkers follows a Build → Scope → Review → Share → Improve lifecycle in which the Scope stage is explicit: as our product page puts it, the coworker gets "its own non-human identity: a named owner, the minimum connector scopes it needs, a model policy, and a budget," and "can never quietly do more than it was given." And the AI Gateway is where the Charge and Re-check fields become enforceable at the request rather than in a wiki, with a rollout model we state as Observe first. Enforce second. Optimize third. — start in observe mode, turn on enforcement once you know the traffic, optimise cost last.

To be direct about the boundary: LeapForce does not sell an agent framework and will not write your orchestration graph. Choose LangGraph or CrewAI or whatever fits your team, and note that LeapForce is in active development, with per-capability build status disclosed honestly as live, in development or roadmap, so ask for the label rather than assuming a capability ships today.

Ready to Govern Your AI?

Talk to LeapForce — one controlled layer for every AI tool, connector, model, and agent.