Welcome to AIEdTalks’ Newsletter!
In today's edition:
Why splitting one working agent into five usually makes it worse
What actually changes when you add agents: memory becomes a network
A simple test for when to split, and when to stop
Seven multi-agent patterns you already know from backend systems
Let’s dive in.
Sponsored by
Cut Lead Review From Hours To Minutes
Sign up for a free trial of Attio, the agentic CRM.
Ask Attio to build a daily workflow that surfaces the deals that need your attention today, like anything with a stage change, a recent reply, or a new signal in the last 24 hours.
Review your pipeline in Claude, synced live from Attio via MCP.
That's it.
Today’s Edition
AI SYSTEMS
One Agent or Five? How to Decide.
Here's a design review you've probably sat in. A team has one AI agent that works. It answers refund and order questions, uses a dozen tools, and passes its evals. Then someone draws a better diagram: a planner, an order-lookup agent, a refunds agent, a policy checker, and a writer. Five specialists, each doing one job. It looks like microservices, and microservices are good, so they ship it. A week later, latency has tripled, the token bill is up roughly tenfold, and a customer gets a refund on a 41-day-old order even though the policy is 30 days. The refunds agent approved it. The policy agent knew about the 30-day rule, but it never saw the order.
That's not an AI problem. It's what happens when you take a monolith with shared memory and split it into services that talk over a lossy channel. Agents just make it easy to do by accident, because spinning up another agent is one line of code. This primer explains single-agent vs multi-agent design from zero: what changes when you split, how to decide, and how to design it if you do. It assumes you know microservices, message passing, and race conditions, and nothing about AI.
1. What an agent is, and what "multi-agent" means
An agent is an LLM running in a loop: think → act → observe. It decides which tool to call, reads the result, and repeats until the job is done. It's the same loop from our MCP and durable execution primers. Everything the agent knows during a run lives in its context window, the model's working memory. It's finite, and whatever isn't in it doesn't exist as far as the model is concerned.
A multi-agent system is several LLM instances, each with its own context window, coordinated by code. The most common shape has an orchestrator (a lead agent that breaks the task up and combines the results) and subagents (workers that each handle one piece). When one agent passes work to another, that's a handoff.
Fix one thing in your head early: more agents doesn't mean more intelligence. It means more context windows, and more boundaries between them.
2. What changes when you split
A single agent has one context window. Think of it as one process with shared memory. The order ID, the refund policy, the customer's history, and every decision made so far all sit in one place, so every new decision can see every fact.
Split it into five agents and each one gets its own window. Now the orchestrator has to decide what to send each subagent. That handoff is serialization: someone writes a summary, ships it, and the next agent works only from what arrived. Whatever the summary drops, the next agent never knew. In our refund story, the refunds agent got the order but not the policy. The policy agent got the policy but not the order. Both did their job correctly with the information they had.
Cognition, the team behind the Devin coding agent, wrote this down as two principles in June 2025: share full context and full traces, not just messages, and every action carries implicit decisions, and conflicting decisions produce bad results. Their example: ask two subagents to build pieces of a Flappy Bird clone, and one builds a Super Mario-style background while the other builds a bird that doesn't match. Neither was wrong. Neither could see what the other assumed.
Once you see it this way, the failure list writes itself: context lost at a handoff, two agents making conflicting decisions, two agents writing the same record, one agent's hallucination becoming another agent's input. A 2025 UC Berkeley study of 1,600+ multi-agent traces across seven frameworks sorted failures into 14 modes, and most of them are these. They're the distributed-systems bugs you already know, running on tokens.
3. What it costs
Splitting has a price, and you pay it on every run.
Tokens. Anthropic reports that agents use about 4x the tokens of a normal chat, and their multi-agent research system used about 15x. On equivalent tasks, their multi-agent setups used 3–10x the tokens of a single agent.
Latency. Running subagents in parallel buys thoroughness, not always speed. The total work goes up, and the run waits for the slowest branch.
Errors. A Google Research and MIT study found that when agents work independently, one bad output gets amplified 17.2x as it spreads. With a central orchestrator checking results, that dropped to 4.4x. The same study found that the right architecture for the task could improve results by up to 81%, and the wrong one could make them 70% worse.
So multi-agent systems can be much better, but only when the shape matches the problem.
4. When to split: the decision
The default is one agent. OpenAI, Anthropic, and Cognition all land in the same place. OpenAI's agent-building guide puts it plainly: maximize a single agent's capabilities first. In September 2026, Anthropic reported that in commerce, a single agent with well-organized skills beat both a one-giant-prompt design and a subagent design on quality, often at lower cost and latency.
Split only when a real constraint forces it:
The subtasks are truly independent and parallel. Researching five markets that share no context is the textbook case. Anthropic's multi-agent research system beat a single agent by 90.2% on their internal research evals.
The work overflows one context window. A subtask produces lots of output that the main task doesn't need. Isolate it and return a summary.
Too many tools. Past roughly 15–20 tools, or tools that overlap, the model starts picking the wrong one. Try tool search before splitting.
Different permissions. One part of the task should never touch payments. A subagent with restricted tools is a real security boundary.
Different model tiers. Cheap steps on a cheap model, hard steps on a strong one.
Separate owners behind a clean contract. Two teams, one well-defined interface.
And stop if any of these are true:
The work is tightly coupled. Most coding and step-by-step planning. If subagent B needs A's output, your "parallel" system is just a slow serial one.
You can't absorb the token multiplier.
Decisions must stay consistent with each other. Keep them in one context.
Rule of thumb: build the single-agent version first and measure it. You can't justify a split without a baseline to beat.
5. If you do split: the design rules
Pass full context, not summaries. The summary is where the refund bug came from.
Give every subagent a task contract: an objective, an output format, the tools it may use, and boundaries like "don't research X, that's another worker's job." Without this, Anthropic saw subagents duplicate each other's work.
One writer per resource. Parallelize reads. Keep writes single-threaded.
Put limits in code, not prompts. Cap agent count, depth, and tokens per run. A subagent that can spawn its own subagents can multiply your bill again.
The orchestrator owns the final decision.
Trace every agent separately: its own token cost, latency, and full history.
Here's the shape in a few lines:
MAX_WORKERS = 4 # enforced in code, not the prompt
MAX_DEPTH = 1 # workers can't spawn workers
def orchestrate(task, full_context):
pieces = lead_agent.split(task, full_context)[:MAX_WORKERS]
results = []
for piece in pieces:
contract = {"objective": piece.goal,
"output_format": piece.schema,
"boundaries": piece.exclusions, # what NOT to do
"context": full_context} # full context, not a summary
results.append(worker.run(contract, depth=1)) # own window, restricted tools
return lead_agent.combine(results) # one agent makes the final callNotice what does the heavy lifting: not the model, not the prompt. The caps, the contracts, and who is allowed to decide.
6. The patterns you already know
Every multi-agent pattern has a backend twin, and it fails the same way:
Single agent with skills — a monolith with plugins. The default. Fails when it has too many tools.
Pipeline — an ETL job. Fixed steps in order. Fails when a bad early stage poisons everything after it.
Orchestrator-workers — fan-out/fan-in. Fails when fan-out is unbounded and costs explode.
Router / handoff — an API gateway. Fails when it misroutes or drops context at the handoff.
Parallel — scatter-gather. Fails when branches can't reconcile, and the slowest one sets your latency.
Hierarchical — an org chart. Fails as every level adds latency and coordination.
Group chat / critic — code review or consensus. Fails with fake agreement, loops, or deadlock.
7. Common beginner mistakes
Splitting by job title. A planner, a coder, and a tester for one feature just play telephone. Split by context boundary instead.
Passing summaries between agents. Every summary is a lossy handoff.
Putting limits in the prompt. "Don't spawn more than three agents" is a suggestion. A cap in code is a limit.
Letting two agents write the same thing. That's a race condition with extra steps.
Assuming parallel means faster. More agents means more total work.
Never re-testing the single agent. Models improve. A split that was worth it last quarter may not be now. Re-run the single-agent baseline after every model upgrade.
Key terms
Agent — an LLM in a loop that picks its own tool calls until the job is done.
Workflow — LLM and tool calls in a fixed, code-defined order.
Context window — the model's finite working memory for a run.
Multi-agent system — several LLM instances with separate context windows, coordinated by code.
Orchestrator / subagent — the lead agent that splits and combines work / a worker that handles one piece.
Handoff — passing work, and some context, from one agent to another.
Task contract — the objective, output format, tools, and boundaries a subagent receives.
Fan-out / fan-in — sending pieces to workers in parallel, then combining the results.
One writer per resource — only one agent may change a given record, file, or state.
The one idea to remember
Adding an agent isn't adding a feature. It's adding a network boundary, with everything that comes with one. So build it like a distributed system: start with one agent, split only when a real constraint forces it, and when you do, pass full context, keep one writer per resource, and put the limits in code. Then five agents stop being five opinions and become one system.
Notes on the facts: the refund story is a composite scenario, not a named incident; every failure in it is documented in the sources cited here. The ~4x and ~15x token figures and the 90.2% research-eval result come from Anthropic's June 2025 post on its multi-agent research system; the 3–10x single-agent comparison is from Anthropic's January 2026 guidance; the commerce finding is from Anthropic's September 2, 2026 commerce-agents guide. These are vendor-reported numbers, not independent benchmarks. The 17.2x vs 4.4x error amplification and the +81% / −70% range are from Kim et al., "Towards a Science of Scaling Agent Systems" (Google Research and MIT, December 2025). The 14 failure modes are from the MAST taxonomy (Cemri et al., UC Berkeley, 2025). Cognition's principles are from "Don't Build Multi-Agents" (June 2025), and the single-agent-first guidance is from OpenAI's "A Practical Guide to Building Agents" (2025). The 15–20 tool threshold is a practitioner rule of thumb, not a hard limit.
👋 That’s All Folks!
Before you go, just a few public service announcements:
See you soon,
AIEdTalks’ Newsletter Team
