When You Actually Need Multiple AI Agents (and When One Agent and a Loop Wins)

One agent in a loop, with tools, a written task list and a stopping rule, handles far more than most builders expect. The structure does the work that people assume needs extra agents. The pattern has five parts: - A plan on disk. The agent writes the task list to a file before it starts, then updates it as it goes. The file survives context loss. The conversation does not. - Tools instead of teammates. A search tool, a test runner and a database query are not agents. They are functions. Most of what people call a "research agent" is a search tool with a prompt around it. - A verification step inside the loop. After each unit of work, the agent runs something that can fail: a test, a type check, a schema validation, a second call that grades its own output against the requirement. - A retry budget. Three attempts at a failing step, then stop and write down why. Unbounded retries are how a cheap run turns into an expensive one. - An append-only log. Every action and result, timestamped. This is the thing you read in the morning. Anthropic's own engineering guidance for agents (December 2024) makes the same argument, advising builders to start with simple prompts and add multi-step agentic systems only when simpler approaches fall short, and to add complexity only when it demonstrably improves outcomes. Nothing on that list requires a framework. Most of it is a loop, a file and an if statement.

The strongest published criticism of multi-agent systems comes from engineers who build agents commercially, not from bystanders. That is worth sitting with before you pick a framework. Walden Yan of Cognition, the team behind Devin, published "Don't Build Multi-Agents" on 12 June 2025. Its two principles are blunt: share context, and share full agent traces rather than individual messages; and actions carry implicit decisions, so conflicting decisions carry bad results. The failure he describes is not a bug. Two subagents given the same brief make different reasonable assumptions, and the pieces do not fit when you join them. The academic picture agrees. "Why Do Multi-Agent LLM Systems Fail?" by Cemri and colleagues (arXiv, March 2025, revised October 2025) annotated more than 1,600 traces across seven multi-agent frameworks and produced a taxonomy of 14 failure modes in three categories: system design issues, agents working at cross purposes, and task verification. The paper opens by noting that performance gains on popular benchmarks are often minimal. There is a mechanical reason underneath. Chroma's "Context Rot" report (Hong, Troynikov and Huber, 14 July 2025) tested 18 models and found performance degrades as input length increases, in non-uniform ways, even on deliberately simple tasks. Passing context between agents means repeatedly rebuilding long inputs, and long inputs are where models get worse. More agents does not mean more intelligence. It usually means more surface area for the same model to contradict itself.

Multiple agents earn their cost when subtasks are truly independent, mostly read-only, and produce more material than one context window can hold. Research and search are the clearest examples. Anthropic's write-up of its multi-agent research system (13 June 2025) reported that a system using Claude Opus 4 as lead with Claude Sonnet 4 subagents outperformed single-agent Claude Opus 4 by 90.2% on their internal research evaluation. The same post reports the price: agents use around 4 times more tokens than chat, and multi-agent systems around 15 times more. Their stated conclusion is that the approach suits high-value tasks with heavy parallelisation, and suits coding poorly, because coding has fewer genuinely parallel subtasks and needs shared context. Cognition's follow-up, "Multi-Agents: What's Actually Working" (22 April 2026), lands in a similar place after ten months of building. Their finding is that multi-agent setups work best today when writes stay single-threaded and the extra agents contribute intelligence rather than edits, and that most working multi-agent setups are limited to read-only subagents such as web search and code search. So the test is not "is my problem complicated". Complicated problems are usually served better by one agent with better tools. The test is: - Can the subtasks run without knowing what the others decided? - Does each one return a summary rather than an edit? - Would doing them in sequence blow the context window or the clock? Three yeses and you have a case. Two and you have a loop.

If you do need orchestration, you are signing up for five engineering jobs that have nothing to do with prompting. Knowing them upfront is the difference between a system and a demo. Task decomposition. Something has to split the work, and that something is usually a model. Anthropic's post notes that minor changes to the lead agent can unpredictably change how subagents behave. Your splitter is now a component that needs its own tests. State. Agents run long and hold state across many tool calls. You need a store outside the conversation that records what is done, what is in flight and what failed, so a crash resumes rather than restarts. Error recovery. Decide per subtask whether failure means retry, skip, escalate to a stronger model or halt the whole run. Without that decision written down, one flaky tool call takes the batch with it. Cost control. At roughly 15 times chat token usage, a runaway loop is a real bill. Cap tokens per subtask, cap total run cost, and stop on the cap rather than warning about it. Observability. You cannot debug what you cannot replay. The OpenTelemetry project's GenAI semantic conventions now define spans for model calls, tool executions and agent invocations, and their guidance notes that telemetry doubles as the feedback loop for improving a non-deterministic system. Adopt a tracing standard early, because reconstructing a multi-agent failure from printed logs is miserable. Each one is real work. That is the actual price of the architecture.

Handing work off overnight is a reliability problem before it is an architecture problem. A second agent does not fix a first agent that cannot tell whether it succeeded. Work backwards from the morning. You want to wake up to three things: what got done, what failed and why, and a diff you can review in fifteen minutes. Every design decision follows from that. What actually gets you there: - Small units. Break the night into jobs that each take minutes, not one job that takes hours. A failed unit costs one unit. - A machine-checkable definition of done. Tests pass, the build succeeds, the row count matches. "Looks good" cannot run at 3am. - A queue, not a conversation. Jobs come from a list, results go back to the list. This is a cron job and a table before it is anything cleverer. - Nothing irreversible. Overnight runs write to branches, drafts and staging. Merges and sends wait for you. - Hard caps. Wall-clock limit, token limit, retry limit. The run stops itself. Do that and you have unattended work with one agent. If you later add a second, you are adding it to a system that already tells you the truth about what happened, which is the only condition under which the second one helps. This is the sequence we teach in buildAcademy: make one thing reliable, prove it, then decide whether the complexity buys you anything.

Is a multi-agent framework ever the right starting point? Rarely. Anthropic's agent guidance suggests starting with direct API calls, since many patterns take only a few lines of code. Frameworks help once you know which coordination pattern you need. Adopting one first means debugging someone else's abstraction before you understand your own problem. Are subagents in coding tools the same thing as multi-agent systems? Mostly no. The reliable ones are read-only helpers that search and report back while a single agent does the writing. Cognition's April 2026 post describes exactly this split. The risk appears when several agents edit the same codebase at once. How do I know my problem is genuinely parallel? Ask whether one subtask needs the output of another. If yes, it is a sequence, and a loop handles sequences perfectly well. Genuine parallelism means each branch could run on a different day, in any order, by a different model, without changing the final result. Does adding agents improve quality on hard reasoning tasks? Not reliably. The Berkeley-led failure analysis of multi-agent systems, published in March 2025, found gains on popular benchmarks are often minimal, and traced most failures to design issues such as poor task specification and weak verification rather than to the limits of model capability. What should I build first if I want agents working overnight? A single job that runs on a schedule, does one small unit of work, verifies itself, writes a log and stops. Get it running unattended for a week. Everything harder is built on that, and most people never need more.