Multi-agent work: when to split, and how to hand off
Adding agents does not make work faster by itself. Six principles from Anthropic, Cognition and recent research, and how endue organizes agents around them.
On this page
When one agent struggles with a job, the first idea is usually to add more agents. One to research, one to write, one to review. It sounds right. Read what the teams who have run these systems for a year actually report, though, and the conclusions are cautious.
This post collects six principles from what Anthropic, Cognition and LangChain have published, and from a study of how multi-agent systems fail. The second half shows how endue puts those principles into the product.
1. Start with one agent
In January, Anthropic wrote that multi-agent setups typically use 3 to 10 times more tokens than a single agent. It also described teams that spent months on elaborate multi-agent architectures, only to find that better prompting on one agent got the same results. The advice is short: start with the simplest approach that works, and add complexity only when the evidence asks for it.
The counterexample is real too. Anthropic’s Research feature uses a lead agent that plans and subagents that search in parallel. On an internal research evaluation it scored 90.2% higher than a single agent, while using about 15 times the tokens of a chat. Token usage alone explained 80% of the difference in quality. Much of the gain comes from being able to spend more compute in parallel, so the first question is whether the task is worth that spend.
2. There are three reasons to split
Anthropic lists three situations where several agents consistently beat one:
- Protecting context. One subtask produces a lot of material the next one does not need. A separate agent can dig through long search results or logs and pass back only what matters.
- Parallel work. The task divides into independent strands that can run at the same time. Broad research is the classic case.
- Specialization. The tools or instructions one part needs conflict with another’s. Put them all in one agent and its tool choices get muddy.
If a split does not serve one of these, the case for more agents is weak.
3. Read in parallel, write in one place
In Don’t Build Multi-Agents (June 2025), Cognition used a Flappy Bird example. Two subagents each built half of a clone. One produced a Super Mario-style background, the other a bird that looked and moved like nothing in Flappy Bird. Actions carry implicit decisions, and decisions made on different assumptions collide.
LangChain pointed out where Anthropic and Cognition actually agree: reading splits far more easily than writing. Anthropic’s research system reads with many agents, then has a single agent write the final report.
In April, Cognition updated its view. The setups that work in practice have several agents contributing intelligence while writes stay single-threaded. Its code reviewer, Devin Review, finds about two bugs per pull request, and roughly 58% of them are severe. Swarms of parallel writers still do not work well.
4. Hand off with a real brief
Anthropic found that short instructions like “research X” led subagents to duplicate work or wander. It started giving each subagent an objective, an output format, guidance on tools and sources, and clear task boundaries. Cognition goes further and recommends sharing the full trace of the work, not a few lines of summary.
A little more effort from the agent handing off saves a lot of guessing by the one receiving.
5. Choose a coordination pattern, and verify separately
In April, Anthropic described five coordination patterns:
| Pattern | Fits | Watch out for |
|---|---|---|
| Generator and verifier | Quality-critical output with explicit criteria | Without defined criteria the loop goes nowhere |
| Orchestrator and subagents | Work that breaks into bounded subtasks | The orchestrator becomes an information bottleneck |
| Agent teams | Independent, long-running parallel work | Findings are hard to share midway, completion is hard to detect |
| Message bus | Event-driven pipelines with a growing set of agents | Cascading events are hard to trace |
| Shared state | Agents building on each other’s discoveries | Without a stop condition it loops forever |
The recommended default is orchestrator and subagents. It covers the widest range of problems with the least coordination overhead; move to another pattern where you see it struggle.
Keep verification as its own role. In the MAST study, researchers at UC Berkeley analyzed 1,642 multi-agent traces. 44.2% of failures came from system design and specification, 32.3% from misalignment between agents, and 23.5% from verification. The most common failure modes were repeating steps, acting against one’s own reasoning, not noticing that the task was done, and pressing on instead of asking for clarification. Fixing role specifications alone raised the success rate by 9.4%, with the same model and the same prompt. Look at the structure before you change the model.
6. People need to see, stop and approve
Agents carry state across many turns, so small errors compound. Anthropic stresses that production systems need tracing and observability. You should be able to see what each agent is doing, stop it or change its direction, and step in before anything hard to undo.
How endue sets this up
endue turns these principles into product structure.
Each agent has its own identity. Name and @handle, system prompt and its revisions, default model, skill and connector bindings, and memory all belong to one agent. Bindings and memory are per agent too, so when you need specialization you make agents by role instead of packing every tool and instruction into one. You can also choose models by role: a fast, inexpensive model for research, the strongest one for the final draft.
A conversation is with one agent. Agents do not read each other’s conversations. To bring a second agent to the same problem, start a conversation with it, and put both conversations in the same project if they should share context. The project becomes the shared working record. Keeping contexts apart is the default.
Work that needs several agents happens in a space. Hand a task to a space and the agent on the conversation splits it into steps; the right teammate picks up each one. You can also tag a specific agent with @. Work moves through Received, In progress and Done, and finished results are kept as versions, so a new result never overwrites an earlier one. One agent divides the work and results accumulate as versions: the orchestrator pattern, with writing kept in one place.
Every agent’s work is on one screen. The activity board groups every conversation across every agent by state (Waiting, Active, Failed, Done). You can stop a run that is in progress and retry one that failed. To change direction mid-run, steer it with a new instruction.
When unsure, the agent asks. When it matters, it stops. An agent that cannot decide asks you, with choices or a free-text question, and waits for the answer. Actions that are hard to undo, like sending a message or deleting something, wait for your approval. That approval cannot be turned off per agent or per account, and in runs nobody is watching, those actions are refused instead of left waiting. These are product-level answers to two failure modes MAST found: moving on without asking, and finishing without checking.
Work arrives through several doors. Routines run on a schedule, channels such as Slack, Discord, KakaoTalk, NaverTalk and WhatsApp bring messages in, and the agent API lets your own systems call an agent.
Example: a team that researches, writes and reviews
Say you want a weekly market report.
- Give a research agent a web search skill and a fast model. Reading widely across sources is the part that splits well.
- Give a writing agent the strongest model, and make it the only agent that writes the report.
- Run a review agent on a different model from the writer, with criteria for checking sources and figures in its system prompt.
- Put all three in one space and hand it the task. Results stack up as versions, so a draft revised after review does not erase the one before it.
- When the report is ready to go out, a person checks it and hands the sending to an agent in a conversation, where the send waits for approval.
In short
- Try one agent first, and split when you have evidence.
- Split only to protect context, to parallelize, or to specialize.
- Read in parallel, write in one place.
- Hand off with an objective, a format, tools and boundaries.
- Keep verification separate, and define its criteria first.
- Make sure people can see, stop and approve.
Sources
- Anthropic, When to use multi-agent systems (and when not to) (January 2026)
- Anthropic, Multi-agent coordination patterns: Five approaches and when to use them (April 2026)
- Anthropic, How we built our multi-agent research system (June 2025)
- Cognition, Don’t Build Multi-Agents (June 2025) and Multi-Agents: What’s Actually Working (April 2026)
- LangChain, How and when to build multi-agent systems (June 2025)
- Cemri et al., Why Do Multi-Agent LLM Systems Fail? (NeurIPS 2025)
