Multi-Agent Systems Mostly Fail on Unclear Specs, Not Weak Models
When teams first adopt multi-agent systems, their instinct is to wire a few Agents together and expect them to finish the job on their own. The usual result: they fight over the same task, simultaneously drop the part nobody owns, and produce outputs that do not line up. This is not anecdotal. The MAST study from UC Berkeley's Sky Computing Lab (Cemri et al., presented at NeurIPS 2025) analyzed 1,642 execution traces across 7 mainstream multi-agent frameworks and measured failure rates between 41% and 86.7%. It grouped the failures into three categories: about 44% stem from system design and specification (ambiguous roles, unclear task definitions), about 32% from coordination and handoffs between agents, and about 24% from missing verification. Together, that is almost entirely a matter of how work is split, how roles are divided, and how handoffs are connected, not of models being too dumb. Gartner likewise projects that over 40% of agentic AI projects will be cancelled by the end of 2027, driven by unclear value, runaway cost, and inadequate controls.
This article is about the methodology of workflow orchestration: when a goal arrives, how to split it into deliverable work units, how to assign each unit to a clearly defined role, and how to design the handoffs between roles. It does not touch which collaboration topology to use or how memory and context are shared, nor whether the investment is worth it. Get this layer of work and roles right, and the architecture and implementation that follow have something solid to stand on.
Task Decomposition: Slice the Goal Into Acceptance-Ready Work Units
Decomposition is not about chopping work into fragments; it is about slicing it into units that can each be delivered and verified independently. To judge whether a cut is right, check three things: does it have a single, clear output; can that output be checked for correctness; and are its dependencies on other units few enough. In its published engineering notes on its multi-agent research system, Anthropic stressed that if the lead Agent gives subtasks no clear objective, output format, or boundaries, the subagents will duplicate work or leave information gaps. The team even turned "how much to invest" into explicit rules: simple fact-finding uses 1 agent with 3-10 tool calls, direct comparisons use 2-4 agents at 10-15 calls each, and only complex research spins up more than 10. This discipline of "scaling effort to complexity" made the overall system outperform a single agent by 90.2%.
There are three common ways to cut, often mixed in practice:
- By process stage: collect, analyze, produce, review; slicing a goal along its natural steps, suited to work with a clear sequence.
- By domain: legal, finance, and technical each take a slice, suited to work that needs different expertise and can run in parallel.
- By type of responsibility: split "producing" from "gatekeeping" into different units so the doer and the checker are not the same, giving quality a second line of defense.
Aim for a middle granularity: cut too coarse and a single Agent carries too much at once, with unstable output that is hard to debug; cut too fine and coordination and handoff costs eat up the benefit. A practical rule: once a unit's output can be clearly described and independently verified, stop cutting deeper. In practice, run a coarse split first, see which unit keeps failing, then subdivide that one, rather than chasing a perfect decomposition diagram from the start.
Role Definition: One Agent Carries One Responsibility
Once the work units are cut, converge them into roles. A role is not "what this Agent can do" but "what result this Agent is accountable for." The most important principle is single responsibility: a role owns one kind of output. The more responsibilities pile on, the harder its behavior is to predict and its errors to locate. This is exactly the core design of MetaGPT (ICLR 2024): it encodes the standard operating procedures (SOPs) of a human software company into the process, dividing labor like an assembly line across five roles, product manager, architect, project manager, engineer, and QA engineer, with each role handing off a fixed-structure intermediate artifact (such as a PRD), which sharply reduces errors. CrewAI, in turn, defines each Agent with a "role, goal, backstory" triad, and officially recommends writing responsibility boundaries into the backstory and disabling self-delegation for lower-level executors to prevent roles from overstepping.
| Role | Output it owns | Boundary (what it does not do) |
|---|
| Planner | Break the goal into a task list and order | Does not execute, nor judge how good results are |
| Researcher | Gather and organize the needed facts and data | Makes no final decision, only supplies the basis |
| Executor | Complete the concrete output as assigned | Does not change task scope; scope issues go back to the Planner |
| Reviewer | Pass or reject against acceptance criteria | Does not edit directly, only gives a clear reason for rejection |
Writing boundaries clearly does its greatest good by eliminating gray zones, which is precisely the 44% specification-class failures that top the MAST statistics. When every role knows what it must hand off and what it must not touch, you avoid two roles fighting over the same task, or a piece of work going unowned because "someone else was assumed to handle it." Boundaries are not held together by tacit understanding; they must be written explicitly into the role definitions.
Handoff Design: You Pass a Delivery Contract, Not a Half-Finished Piece
Handoffs are where roles most easily break down, and about 32% of MAST failures land in this layer. A handoff failure is usually not that data failed to arrive, but that the receiver got something it cannot tell is finished and whose format does not match. A good handoff should be designed as a contract. Engineering practice already has established patterns for this: the Agents SDK that OpenAI open-sourced in 2025 implements a handoff as a tool call (transfer_to_X) and uses Guardrails to validate inputs and outputs at the handoff boundary, effectively forcing every handoff through a check. A clear handoff contract covers at least four things:
| Contract element | Question it answers |
|---|
| Input preconditions | What conditions must be in place before the receiver can start |
| Output format | What the deliverable looks like and how it is structured |
| Definition of done | What conditions count as "done" rather than merely "attempted" |
| Acceptance criteria | What standard the downstream uses to accept or reject |
Turn every handoff point into a gate with acceptance criteria, and the workflow stops carrying errors all the way downstream. Research shows that uncoordinated multi-agent systems can amplify errors by up to 17x, while an architecture with central verification gatekeeping holds it to about 4.4x. When an upstream output fails to meet the definition of done, reject it at the moment of handoff, rather than letting the downstream force a half-finished piece through, only to discover at the very end that the whole pipeline's result is unusable.
The Five Most Common Traps in Decomposition and Handoffs
- Cutting too fine: so many units that coordination cost overwhelms the benefit of dividing labor, with Agents spending most of their time waiting on and handing off to each other.
- Overlapping roles: two roles' responsibility descriptions intersect, so in practice they either fight over work or kick it to each other.
- Doing and reviewing not separated: letting the executor review its own output is no gatekeeping at all, leaving quality without a second line of defense.
- Handoffs without a definition of done: saying only "pass the result to the next one" without defining what counts as done, leaving the downstream to guess.
- Boundaries held by tacit understanding: responsibilities and handoffs are not written down, so a new task or context invites everyone to reinterpret and go their own way.
The shared fix for all five is to treat decomposition, roles, and handoffs as things to design and write down first, not to improvise after the Agents are wired up. Echoing the 24% of MAST failures caused by missing verification: workflow orchestration is fundamentally a design task. The clearer the design, the more predictable and maintainable the multi-agent system becomes, and the easier it is, when something breaks, to pinpoint which role failed to do what it should.
Nerdtechnic: Helping You Split and Connect Your AI Workflow Right
For a multi-agent system to produce reliably, the hard part is not wiring Agents together but splitting the work right and defining roles and handoffs clearly, which is precisely the trap most projects hit only after going live. Nerdtechnic's AI systems consulting service starts by mapping your actual process, then helps split the goal into acceptance-ready work units, define each role's responsibilities and boundaries, and design handoff contracts with acceptance criteria, so your AI workflow grows on a clear division of labor from the start, rather than discovering after launch that each role went its own way and the results do not line up.
References
Technical Sharing
