When one loop is enough - and when you need a team
The previous post ended with a loop: reason, act, observe, repeat. That loop, running inside a single agent, can handle a surprising range of tasks. But spend enough time building agents and you'll hit a wall. The task is too long for one context window. Two subtasks need to run at the same time. One part of the problem requires a specialist that would be noise everywhere else. When you hit that wall, you have a choice: push harder on the single agent or split the work across multiple agents. Knowing which to reach for - and why - is what this post is about.
What a single agent actually is
Before comparing, it's worth being precise. A single agent is one model, one context window, and one tool set, running one loop. Everything it has learned about the task lives in that growing history of thoughts, actions, and observations. Its memory is its context.
That constraint is the source of both its simplicity and its limits.
Where a single agent excels:
- Tasks that fit comfortably in one context window
- Linear workflows where each step depends on the last
- Problems where keeping a shared mental model matters more than speed
- Prototyping - one loop is trivial to trace and debug.
Where it breaks down:
- Long tasks that exceed the context limit midrun
- Tasks with independent subtasks that could be parallelised
- Workflows that need different capabilities in different phases
- Any situation where one agent failing silently kills the whole job
What a multi-agent system adds
A multi-agent system is two or more agents coordinating to complete a task. Coordination can mean many things - one agent spawning others, agents running in parallel and reporting back, and a pipeline where each agent's output is the next agent's input. The common thread is that no single agent owns the whole task.
This unlocks three things:
Parallelism. If you need to research five companies simultaneously, a single agent does them sequentially. A multi-agent system spawns five subagents and gets all five results at once. For I/O-bound tasks - anything involving search, API calls, or file reads - this is the primary win.
Specialisation. A coding agent prompted and tooled for writing Python is better at writing Python than a generalist agent. A multi-agent system lets you route subtasks to agents built for them - a planner, a researcher, a coder, a critic — each with the right system prompt and the right tools.
Context management. Each subagent gets a fresh, focused context. Instead of one agent accumulating 50,000 tokens of noise from early steps, a subagent receives only what it needs to do its job. The orchestrator summarises and routes; the workers stay sharp.
The orchestrator–worker pattern
The most common multi-agent architecture is a two-level hierarchy: one orchestrator and one or more workers.
The orchestrator receives the goal, makes a plan, and delegates subtasks. It does not do the work itself - it decides what the work is and who does it. Workers receive a scoped task, run their own loop, and return a result. They don't know about each other or the overall goal.
def orchestrator(goal, worker_agents):
plan = llm(f"Break this goal into subtasks: {goal}")
# plan = [{"task": "...", "agent": "researcher"}, ...]
results = {}
for step in plan:
worker = worker_agents[step["agent"]]
results[step["task"]] = worker.run(step["task"])
final_answer = llm(f"Synthesise these results: {results}")
return final_answer
Each worker.run() is the same agent loop from the previous post - reason, act, observe, repeat - but scoped to a single subtask. The orchestrator never picks up a tool itself; it reads a plan and routes. The workers never see the big picture; they just solve their piece.
This separation matters. It keeps orchestrator context lean (plans and results, not tool noise) and keeps worker context focused (one task, right tools, nothing else).
Parallelising with subagents
When subtasks are independent, run workers concurrently. In Python, asyncio or ThreadPoolExecutor are the usual choices:
from concurrent.futures import ThreadPoolExecutor
def run_parallel(tasks, worker):
with ThreadPoolExecutor(max_workers=len(tasks)) as pool:
futures = {pool.submit(worker.run, task): task for task in tasks}
return {task: f.result() for f, task in
[(v, k) for k, v in futures.items()]}
Two things to watch. First, rate limits: five agents hitting the same API simultaneously will hit quotas faster than one agent doing it sequentially. Build in back-off logic at the worker level, not just the orchestrator level. Second, result merging: parallel results arrive out of order and may conflict. The orchestrator's synthesis step needs to handle gaps and contradictions, not assume clean, uniform output.
When multi-agent is the wrong answer
Multi-agent systems have real costs, and reaching for them too early is one of the most common mistakes in agent engineering.
Complexity compounds. A single agent failing is easy to diagnose - you read the trace. Multiple agents failing is a distributed systems problem. Which agent failed? Did the orchestrator misparse the result? Did the worker receive a bad task? Every hop is a new failure surface.
Latency can get worse, not better. Parallelism helps I/O-bound tasks. For CPU-bound or model-call-bound work, the overhead of spawning agents, merging results, and making extra orchestration calls can exceed what a single focused agent would have taken.
Context hand-offs lose information. When the orchestrator summarises a worker's result to pass to the next, it makes decisions about what to keep. Those decisions are lossy. A single agent that ran the whole task never had to summarise itself.
The honest default: start with a single agent. Add a second agent when you have a concrete bottleneck - context overflow, a parallelism win you can measure, or a capability mismatch you cannot solve with a better prompt and better tools.
A practical decision framework
| Situation | Reach for |
|---|---|
| Task fits in context, linear flow | Single agent |
| Task exceeds context mid-run | Orchestrator + summarising subagents |
| Independent subtasks, I/O-bound | Parallel workers |
| Phases need different tool sets | Specialist workers per phase |
| Need a second opinion on outputs | Critic agent in the loop |
| Prototyping or debugging | Single agent - always start here |
A single agent is not a stepping stone to multi-agent. It is the right architecture for a large class of tasks and the one you should default to until you have a specific reason to split work. Multi-agent systems earn their complexity when tasks genuinely exceed what one context window can hold, when parallelism produces a real speed win, or when specialist agents meaningfully outperform a generalist on a defined subtask.
The loop does not change. What changes are, who owns which part of it, and how do the pieces report back?
Top comments (0)