Use multiple AI agents when a task can be divided into well-defined subtasks or roles, with parallel execution where the parts are independent, and when a well-built single agent or workflow has been measured and falls short. A multi-agent design adds coordination: something must split the work, give each part the right context, merge the results and check them. That costs tokens, time and engineering effort. Start from a single-agent baseline, set a budget for every run, and adopt multiple agents only where your own evidence shows they help.
A multi-agent system runs several model instances, each with its own instructions, context and tools, on parts of one task. Coordination can live in ordinary code, which splits the work and gathers the results, or in a lead agent that plans and delegates as it goes.
Anthropic has published a write-up of its multi-agent research system, a useful primary case study: a lead agent plans the research and delegates to subagents that search in parallel, and the article explains how the team evaluated the system. Treat it as an example of orchestration, delegation and evaluation working together, not as a forecast. Its measured results belong to that system and that kind of task, and should not be assumed to carry over to yours.
Anthropic's separate guide to building effective agents distinguishes parallelization, where independent work can be predefined, from orchestrator-workers, where a central model dynamically decides the subtasks and delegates them. Many problems that seem to need several autonomous agents can be solved with one of those simpler patterns.
Splitting work tends to help when a task has these properties:
- Breadth with independent parts. Comparing many suppliers, reviewing many contracts against the same checklist, or researching several sub-questions that do not depend on each other.
- More material than one context can hold well. Each worker reads its share and returns a summary, instead of one agent juggling everything.
- Different tools or permissions per part. Separate workers can use distinct, server-enforced credentials and tool permissions. Prompts or worker boundaries alone do not enforce access; filter shared context and results so a drafting worker does not receive unauthorized customer records.
- Time pressure. Independent parts run in parallel, so the whole task can finish sooner even if it costs more.
- Independent review. A separate checker with fresh context and its own criteria may catch missed errors. Its mistakes can still correlate with the author’s; agreement between agents is not verification against evidence.
It tends to hurt when every step depends on the previous one, as in a tightly argued document or a sequential calculation; when the parts must share a single, consistent state; or when the task is short enough that coordination overhead outweighs any gain.
Figure 1 — Define clear subtasks. Enforce access in the application.
Before designing anything with several agents, build the simplest version that could work: one agent, or a fixed workflow, with good instructions and the right tools. Measure it on a test set of permitted, minimized examples representative of real tasks, recording quality, cost per task and time to complete. Our guide to evaluating LLM applications covers how to build that set.
Then look at how the baseline fails. If failures come from breadth, overflowing context or the lack of an independent check, decomposition may help. If they come from missing knowledge, unclear instructions or a weak model, adding agents is unlikely to fix the issue without improving the knowledge, retrieval or other underlying cause. Anthropic's guide makes the same general point: start simple and add complexity only when it is needed, weighing the extra latency and cost.
Most of the effort in a multi-agent system goes into coordination, not into the individual agents. Decide:
- How work is split: by sub-question, by document or by source, so that parts neither overlap nor leave gaps.
- What each worker receives: a clear objective, boundaries, the output format and only the tools it needs.
- How results are merged: who resolves contradictions between workers, and how sources stay attached to claims.
- How failures are handled: what happens if a worker errors, times out or returns nothing useful.
- How runs are traced: record delegation and tool outcomes with trace identifiers so failures can be investigated. Minimize or redact sensitive payloads, restrict access and set retention periods rather than retaining every raw result.
Give each worker the narrowest permissions its part needs. Our blueprint for adding an LLM to a legacy application explains tool boundaries and the separation of read and write access in more detail.
Figure 2 — Design the coordination. Keep sources with results.
Multi-agent runs can grow in ways a single call cannot: more workers, more steps, more retries. Set explicit limits before production: the maximum number of workers, steps per worker, total tokens or spend per run, and wall-clock time. Define what happens when a limit is reached, for example returning a clearly marked partial result or stopping. Reserve a separate budget if a single-agent fallback is allowed; an exhausted run must not automatically trigger another unbounded run. Cancel or drain outstanding workers, and prevent retries or fallback from duplicating external actions with application-enforced idempotency and outcome reconciliation.
Track cost per accepted outcome rather than cost per call, and compare it with the baseline. A design that costs more per run can still be worthwhile if it produces accepted results the baseline could not; the same quality at lower latency may also be valuable. Judge quality, cost and latency together against agreed acceptance criteria. There is no general multiplier to plan with, so measure your own.
Evaluate the whole pipeline end to end on the same test set as the baseline, comparing quality, cost and time. Then check the coordination itself: did the workers cover every part of the task, did they duplicate each other, and did the merge step keep sources attached to claims? Keep people in the review loop for high-stakes outputs, and re-run the evaluation whenever you change the split, the prompts or the models.
If the evidence shows a clear gain on a task you care about, keep the design and its budget. If not, return to the simpler baseline; that decision is a success too. For deciding how much autonomy any agent should have in the first place, see our CTO playbook for AI agents.
These recommendations are TecnoStack's guidance, not Anthropic requirements. If you are considering a multi-agent design, our AI agents service can help you build the baseline, design the coordination and set the budgets.
- Anthropic. Multi-agent research system: a primary case study of a lead agent delegating to parallel subagents, and of how the system was evaluated.
- Anthropic. Building effective agents: distinguishes workflows from agents, describes patterns such as parallelization and orchestrator-workers, and recommends starting simple; its December 2024 examples are marked historical.
