Agentic architectures: the four topologies and where they break

There's a strong pull toward elaborate multi-agent systems — a manager agent, a researcher, a critic, a writer, all chatting. They demo beautifully and fall over in production. The foundational agent post covers the loop, context, and tools; this one is about topology: how many agents, arranged how, and the failure mode each one buys you.

Topology 1 — the single agent

One model, one loop, a set of tools. It plans, acts, observes, repeats. This handles far more than people expect, and it should be your default — it's the cheapest to run, the easiest to debug (one transcript), and the one with no coordination overhead.

• Use it for: almost everything. Coding tasks, research, data work, support.
• Breaks when: the task genuinely needs parallelism, or the context for the whole job won't fit in one window without going stale.

Start with one agent. Make it good. Add a second only when a profiler — or a failure — proves one isn't enough. Most "we need multi-agent" instincts are "we need better tools and context" in disguise.

Topology 2 — orchestrator + workers (fan-out)

One coordinator decomposes a task and spawns workers for the independent parts, then combines the results. This is the first complication worth adding, because it buys something real: parallelism and context isolation.

• Use it for: fan-out work — search many files at once, evaluate several candidates, process a batch. Each worker gets a clean, scoped context; the orchestrator keeps a tidy summary instead of drowning in every worker's raw output. (This is exactly the subagent pattern Claude Code uses to keep its main thread clean.)
• Breaks when: the subtasks aren't actually independent — if workers need to coordinate mid-flight, you've picked the wrong shape.

Topology 3 — the evaluator loop (generate → critique → revise)

A worker produces, a separate evaluator scores against a rubric, the worker revises until it passes or a budget runs out. The key is that the evaluator runs in a fresh context — it judges the artifact, not the conversation that produced it, so it isn't anchored by the author's reasoning.

• Use it for: tasks with a checkable definition of done — "the tests pass," "the CSV has a numeric price column per row," "the rubric's twelve criteria are met." A fresh-eyes verifier reliably outperforms self-critique in the same context.
• Breaks when: "good" isn't gradeable. A vague rubric produces a noisy loop that burns tokens converging on nothing. No oracle, no evaluator.

Topology 4 — true multi-agent (peers that talk)

Multiple specialized agents, each with its own role, communicating. This is the architecture everyone wants and almost nobody needs. It's powerful for genuinely decomposable, role-specialized work — but every message between agents is a place context gets lost, costs multiply, and debugging becomes archaeology across N transcripts.

• Use it for: large, genuinely parallel efforts where roles are distinct and durable, and the coordination cost is worth it. Asynchronous peers (workers that keep running and report back) beat spawn-and-block.
• Breaks when: you reached for it first. The coordination tax is real and fixed; you pay it whether or not the task needed the power.

The escalation ladder

The whole post in one rule — stop at the first topology that holds:

1. Single agent           -> can one good loop do it? usually yes.
2. + Orchestrator/workers  -> only to parallelize independent subtasks.
3. + Evaluator loop        -> only when "done" is gradeable.
4. + Multi-agent peers     -> only for large, role-specialized, parallel work.

This is the ponytail ladder applied to architecture: every rung up adds capability and coordination cost, latency, and tokens. Climb only when the rung below provably can't hold the weight.

What actually decides success

Topology is the smallest lever. The things that determine whether any of these ship:

• Context discipline — narrow, relevant, cached. (The 99%-cost architecture is mostly this.)
• Tools with teeth — least-privilege, validated inputs, confirmed side effects.
• Evals — a golden set you run on every change, or you're flying blind.

Pick the simplest topology that fits, then spend your effort on those three. A great single agent beats a mediocre swarm every time.