An AI assistant can work with you from morning to afternoon and still forget by evening that you said, “Do not touch the official data.” The longer and more complicated the task, the more likely a single AI is to miss things. Multi-agent orchestration frameworks are designed for this situation.
What is a multi-agent orchestration framework (multi-agent harness)? A harness is the complete set of tools around a model: a loop that lets it act repeatedly, tools it can call, management of its context (everything the model can currently see), and guardrails. With this equipment, the model becomes an agent that can decide what to do next and use tools to complete the work. A multi-agent orchestration framework is the team version: one orchestrator splits a large job among several agents, each handling a small part in its own context and returning only a concise result. The orchestrator can be an AI or a piece of software.
This article explains in plain English the approaches that recur in official Anthropic, OpenAI, Google, and Microsoft documentation, along with a real-world account of Penchan’s AI team running the process once.
Why is one AI not enough?
Anthropic gave three names to problems a single agent can have on long tasks:
- Agentic laziness (declaring the job done halfway through): Anthropic’s example is a 50-item security check that processed only 35 items before declaring itself finished.
- Self-preferential bias (grading its own work): When asked to check its own output, it tends to favor itself.
- Goal drift (forgetting the original goal after a long conversation): As a conversation grows, older content is compressed into summaries. Each compression can lose details, so constraints such as “do not do X” can disappear this way.
There is also context contamination: information left by one subtask keeps interfering with the next. The solution is to split the work among several agents, each with a clean context and a single focus. If a checking agent receives only the result and the criteria, without seeing the doer’s reasoning, it is also less likely to make excuses for that work. This needs to be arranged deliberately.
Who holds the plan?
The Claude Code documentation distinguishes the approaches with one sentence: “The difference is who holds the plan.” The plan can stay with the directing AI, which decides the next step each round. This is flexible, but every result returns to its context, which becomes increasingly crowded over time. The plan can also be written as a program, with a script holding the steps and intermediate results while the directing AI needs to see only the final answer. The first is like a manager thinking while working; the second is like following a written process sheet. Either way, the point is to keep the orchestrator’s context clean.
Six common patterns
Anthropic has organized six patterns, which are often combined in practice:
- Classify-and-act: First identify the type of task, then send it to the appropriate agent. For example, route customer-service emails.
- Fan-out-and-synthesize: Split the work into small pieces and do them in parallel, then synthesize the results after everything is complete. For example, a multi-directional investigation.
- Adversarial verification: Assign another agent to look for problems using specific criteria. Use it for outputs where mistakes are costly.
- Generate-and-filter: Generate many ideas, filter them against criteria or real-world tests, remove duplicates, and keep only the best. For example, brainstorming headlines.
- Tournament: Have each agent produce a version, compare them two at a time, and select the best. Anthropic considers pairwise comparison more reliable than assigning absolute scores.
- Loop until done: Keep sending agents to look for issues until a stopping condition is met, such as no new errors appearing in the log.

Figure 1: Six patterns. Image source: Anthropic (claude.dev)
When agents read outside content such as web pages, email, or comments, there is another pattern called quarantine: the agent responsible for reading does not take high-privilege actions, and the agent that actually acts sees only the summaries they provide, not the original content. See AI agent security risks for this type of risk.

Figure 2: Agents reading outside content stay in quarantine; privileged agents see only the summaries. Image source: Anthropic (claude.dev)
In practice: one article, nine AIs
In September 2026, Penchan’s AI team used this approach to write an analysis of a new product. The division of labor was: one directing AI (making the plan, writing briefs, and deciding whether to accept or reject work, but not writing the article itself); six research agents (one question each, each returning an evidence file, with one dedicated to checking other people’s claims; at most three running at the same time, with the rest queued); one writing agent allowed to use only the evidence files; and one review agent from another model family. Several roles switched to backups along the way: one model’s research allowance ran out, so with Penchan’s approval, the remaining research was handed to agents from another model family; the review role also changed hands, as explained below. Penchan personally handled the article angle, cover, and pressing Publish.
It took about an hour and a half from “start” to receiving a draft the orchestrator had checked against the evidence; the final review took another hour or more, for the reason in the last row of the table below.
| What went wrong | Who caught it | What we learned |
|---|---|---|
| The brief had a wrong premise: it treated the product name as a model family, even though the same name also referred to an agent app for ordinary users | A research agent reported it, and the orchestrator personally checked primary sources | Verify the most important premise before sending out the brief |
| The orchestrator made a mistake: after reading the official page, it said, “There probably isn’t a waitlist” | A community research agent found user reports of seeing a waitlist screen in the app; Penchan had been right from the start | The official page not mentioning something does not mean it does not exist |
| The writing agent changed the media reports’ “humans placed calls” into “humans answered calls” | The orchestrator compared the draft line by line with the evidence files and sent back 12 issues in total | Check a draft against the original evidence |
| Errors remained after the orchestrator reviewed the draft: the FAQ and opening contradicted the corrected body, and a detail reported by only one outlet was written as if two outlets had reported it | A review agent from another model family read the evidence directly and found 8 issues that had to be fixed; the orchestrator also used video footage the reviewer had not seen to reject one of its points | Use a different model family for the final gate; check review comments against the evidence too |
| The review agent ran out of allowance, and its two replacements returned only progress messages with no conclusion | The orchestrator opened the outputs and checked them directly instead of looking only at “execution complete” | “It ran” does not mean “it was done” |
If the premise is wrong, an agent will diligently complete the work based on that wrong premise. Two of the five problems in the table involved the orchestrator itself. Each layer caught different errors; no single layer can be trusted on its own, including the orchestrator.
When should you not use it?
OpenAI, Microsoft, and Anthropic’s documentation all recommend getting a single agent working well first. If a simple approach can solve the problem, do not add more agents. Multi-agent systems suit broad, parallel, independent work, such as investigating from multiple directions or checking claims one by one; when several people need to edit the same file, or every step depends on the previous step, one agent is usually better.
A simple test is: can this work be split among several people who each investigate their own part without interfering with one another? If yes, a group of AIs may be worthwhile; if not, start by writing a good brief for one AI.
Costs also increase many times over: each agent consumes its own tokens (the unit used to process text and calculate model costs), and handoffs and coordination add another layer of cost. Research also suggests caution: a 2025 paper by Cemri et al. analyzed 7 open-source multi-agent systems and found failure rates between 41% and 86.7%.
Five design principles
- Split work along information boundaries. First decide which information needs to stay together, then divide the work. Anthropic ran an experiment in which agents divided by job title (planning, implementation, testing, and review) spent more tokens on coordination than on the work itself. Better divisions are independent research directions or separate checks that look only at results.
- Write a clear brief. A subagent cannot see what you discussed with the orchestrator. Write down the goal, output format, sources to use, and task boundaries; let the person doing the work decide how to get there. Anthropic also found that when planning includes overly detailed technical instructions that are wrong, the error propagates downstream.
- Separate doing from checking. Checking needs specific criteria and protection against the opposite problem: if you tell a review agent to find faults, it will usually find some even when the work is sound. Anthropic’s approach pairs one checker with each rule, then uses a “skeptic” agent to filter false positives.
- Use files for handoffs. Put the result in a file and return only a short reference to where it is, avoiding distortion through repeated retelling. Let only one agent edit a given thing at a time.
- Set stopping conditions and keep people at key gates. Put limits on retries and iterations, and decide in advance what happens when the limit is reached. Microsoft’s example is to hand the case to a person. Leave sensitive and irreversible actions for human approval.
Should the reviewer use a different model family?
Penchan’s team put a model from another model family in charge of the final gate. Research has found that when models score answers, they favor their own output; other research has found that stronger models make more similar mistakes, even when they come from different vendors. None of the official Anthropic, OpenAI, Google, or Microsoft documents we read requires using a different model family for review. Anthropic asks for a new model instance with a clean context. So Penchan treated a different model family as inexpensive insurance; the example it actually caught is in the fourth row of the table above. What supports quality is a reviewer with a clean context, direct access to the original evidence, and specific checking criteria.
Penchan’s takeaways
- Write a brief as if handing work to a new colleague. They have not heard any of your earlier conversation. Verify the most important premise yourself before sending it.
- Separate checking from doing. You do not need to code to apply this: open two conversations, one for writing and one that uses only the original material to check each point. Penchan’s team actually allowed the writer to use only evidence files and had a model from another model family review the final version.
- If one AI does the job well, do not call a group. Save multi-agent setups for work that is broad, parallel, and expensive to get wrong.
- Leave taste, authorization, and irreversible decisions to people. In Penchan’s team, Penchan still handled the article angle, cover, and pressing Publish.
Anthropic’s engineering team has written that every component in a harness contains an assumption about what the model cannot do by itself. Penchan’s team is still testing, one by one, which components can be removed as models get stronger.
For more foundational concepts, start with the AI Agent section; for how context works, see AI agent memory.
References
Cover image source: Anthropic (claude.dev)
Official documentation changes over time; this article reflects information retrieved on 2026-09-23.
- Anthropic (claude.dev): A harness for every task: dynamic workflows in Claude Code, https://claude.dev/blog/a-harness-for-every-task-dynamic-workflows-in-claude-code/
- Anthropic: Building multi-agent systems: when and how to use them, https://claude.com/blog/building-multi-agent-systems-when-and-how-to-use-them
- Anthropic: Harnessing Claude’s intelligence, https://claude.com/blog/harnessing-claudes-intelligence
- Claude Code documentation: Workflows, https://code.claude.com/docs/en/workflows
- Claude Code documentation: Glossary, https://code.claude.com/docs/en/glossary
- Claude Code documentation: Subagents, https://code.claude.com/docs/en/sub-agents
- Claude Code documentation: Agent teams, https://code.claude.com/docs/en/agent-teams
- Claude Code documentation: Best practices, https://code.claude.com/docs/en/best-practices
- Anthropic Engineering: Building effective agents, https://www.anthropic.com/engineering/building-effective-agents
- Anthropic Engineering: How we built our multi-agent research system, https://www.anthropic.com/engineering/multi-agent-research-system
- Anthropic Engineering: Harness design for long-running application development, https://www.anthropic.com/engineering/harness-design-long-running-apps
- OpenAI: A practical guide to building agents, https://cdn.openai.com/business-guides-and-resources/a-practical-guide-to-building-agents.pdf
- Google Agent Development Kit: Workflows, https://google.github.io/adk-docs/workflows/
- Microsoft Azure Architecture Center: AI agent orchestration patterns, https://learn.microsoft.com/en-us/azure/architecture/ai-ml/guide/ai-agent-design-patterns
- Microsoft Agent Framework: Overview, https://learn.microsoft.com/en-us/agent-framework/overview/
- Cognition: Multi-Agents: What’s Actually Working (2026), https://cognition.com/blog/multi-agents-working
- Cemri et al. (2025) Why Do Multi-Agent LLM Systems Fail?, https://arxiv.org/abs/2503.13657
- Kim et al. (2025) Towards a Science of Scaling Agent Systems, https://arxiv.org/abs/2512.08296
- Wang et al. (2024) Rethinking the Bounds of LLM Reasoning: Are Multi-Agent Discussions the Key?, https://arxiv.org/abs/2402.18272
- Panickssery et al. (2024) LLM Evaluators Recognize and Favor Their Own Generations, https://arxiv.org/abs/2404.13076
- Wataoka et al. (2024) Self-Preference Bias in LLM-as-a-Judge, https://arxiv.org/abs/2410.21819
- Verga et al. (2024) Replacing Judges with Juries, https://arxiv.org/abs/2404.18796
- Kim et al. (2025) Correlated Errors in Large Language Models, https://arxiv.org/abs/2506.07962