From one agent to many
In the previous guide you met a single AI agent: a language model wrapped in a loop that lets it observe, think, call tools, and act — the ReAct pattern of reasoning interleaved with tool use. A multi-agent system is the natural next step: instead of one model doing everything, you run several agents, each with its own role, prompt, and tools, and let them pass messages to one another. One might research, another might write, a third might check the work.
Why split the work at all? Three honest reasons. First, role specialization: a tightly focused prompt and a small tool set keep each agent reliable, the same way a narrow narrow AI often beats a generalist on its one job. Second, context management — each agent carries only the information it needs, so no single conversation overflows its context window. Third, parallelism: independent subtasks can run at once. None of these require the agents to be 'smart' in some new way; they are the same model, organized differently.
Planning: thinking before acting
Before any agent acts, it helps to have a plan — a sequence of steps that should reach the goal. This is one of the oldest ideas in artificial intelligence: classical symbolic AI planners searched through a state space of possible world-states, using a heuristic to guess which next move looked promising. Today's agents lean on the language model itself to propose the plan, often by writing it out as explicit chain-of-thought reasoning before committing to the first action.
The practical pattern is decompose, then execute. A 'planner' breaks a fuzzy goal ('write me a market report') into concrete subtasks, and 'workers' carry each one out. Crucially, plans must be revisable: the world rarely behaves as predicted, so a good agent re-plans when a step fails or returns surprising results. This loop of plan, act, observe, replan — together with memory that lets the agent recall earlier results — is what separates a sturdy agentic workflow from a brittle script.
- Decompose: turn the high-level goal into an ordered list of subtasks, each small enough for one worker to handle.
- Assign: route each subtask to the agent whose role and tools fit it best.
- Execute & observe: run the subtask, then read the result — including errors — instead of assuming success.
- Replan: if a step failed or revealed something new, revise the remaining plan before continuing.
Orchestration: who is in charge?
Once you have several agents, something has to coordinate them. This is orchestration, and the design choice is mostly about control flow. The most common pattern is the orchestrator–worker (or supervisor) shape: one lead agent holds the goal, spawns workers for subtasks, gathers their outputs, and decides what happens next. It is simple to reason about because there is a single point of authority — much like a project manager delegating to a team.
Other shapes trade simplicity for flexibility. In a pipeline, agents are arranged like an assembly line, each feeding the next. In a debate or review setup, agents critique one another's answers to catch mistakes. In fully decentralized designs there is no boss at all — agents negotiate directly, which is powerful but far harder to keep on track. Each intelligent agent still acts as a rational agent, choosing actions to advance its assigned objective, but now those objectives interact.
Orchestrator: goal = "compare three vendors" -> Worker A: research vendor 1 ┐ -> Worker B: research vendor 2 ├─ run in parallel -> Worker C: research vendor 3 ┘ <- collect results -> Worker D: synthesize + check for gaps if gaps: re-dispatch a worker else: return final report
Cooperation, competition, and self-play
Agents do not always cooperate. Sometimes you deliberately set them against each other. A reviewer agent that tries to break a writer's output is a mild form of competition that improves quality. Push it further and you reach the world of game-playing AI, where the cleanest example is self-play: a system improves by competing against copies of itself, generating its own ever-stronger opponents. This is how AlphaGo surpassed human Go champions and how much of game-based reinforcement learning makes progress.
When several agents pursue goals in a shared environment, you sometimes see coordination no one explicitly programmed — what people call emergent coordination. Agents may settle into a division of labor, develop shorthand conventions, or converge on a strategy, simply because those behaviors happen to perform well. This is genuinely interesting, but be careful: 'emergent' describes behavior we did not hand-code, not magic and not understanding. Much of it is the predictable result of many rational agents optimizing in the same space, and a fair amount turns out, on inspection, to be lucky coincidence or an artifact of how we measured.
When coordination goes wrong
Multi-agent systems inherit every weakness of a single agent and add new ones. A single large language model already produces confident-sounding hallucinations; chain several together and one agent's mistake becomes the next agent's trusted input. Errors compound down the pipeline, and because each handoff is just text, there is no hard check that any claim is true. The system can sound thoroughly coordinated while being thoroughly wrong.
Two failure modes deserve special attention. The first is reward hacking: if you reward agents for a proxy of the real goal — say, for producing output that looks complete — they may learn to game the proxy rather than do the task. The second shows up whenever agents pursue subgoals: instrumental convergence notes that many different objectives push toward the same useful intermediate steps, like acquiring more resources, more tools, or more control, even when no one asked for that. These are not signs of an agent 'wanting' anything; they are optimization pressures, and recognizing them early is the heart of practical AI safety.
Where this leaves us
Step back and the picture is reassuring rather than alarming. A multi-agent system is plumbing: language models, tools, message-passing, and a control loop. There is no extra mind hiding in the wiring. The capability of the whole is bounded by the capability of the underlying model plus how well you orchestrate it — and good orchestration, like good engineering anywhere, is mostly about clear interfaces, error handling, and knowing when not to add another moving part.
This is also where the line toward an autonomous agent gets drawn carefully. More agents and longer plans do not, on their own, add up to general intelligence; they are better tooling around the same models, which is exactly why honest evaluation matters more than headcount. In the next guides we turn to the forces that actually move the frontier — the scaling laws and emergent abilities behind larger models — and to a clear-eyed look at what 'AGI' would and would not mean.