Agent Architecture · 3 topologies, 3 predictable breaks

Every multi-agent system already has an org chart. You just didn't draw it.

Teams reach for "multi-agent" the way they reached for "microservices" a decade ago, without naming the shape they're actually building. Every shape already has a name. Every shape already has the specific way it snaps.

The agents aren't the risk. The wiring between them is.

Hub–Spoke: bottlenecks at the hub Mesh: errors cascade node to node Hierarchy: goal drifts by the leaves

Pattern 1 / 3

Hub–spoke: one agent runs the room

A supervisor agent receives the task, delegates pieces to specialist agents, and synthesizes what comes back. Each specialist gets a focused context window, a smaller tool set, and a system prompt written for exactly one job.

One agent holds the plan. Everyone else holds a piece of it.

Where it breaks

The hub becomes the bottleneck. Every decision, every point of latency, every dollar of cost routes through one context window. When the supervisor has a bad turn, the whole system has a bad turn, because nothing downstream can outvote it.

Use it when: the task decomposes cleanly into independent pieces that don't need to argue with each other. Research, draft, and review can run this way. Negotiating a shared decision cannot.

Pattern 2 / 3

Mesh: nobody's in charge, which is the point (until it isn't)

Agents talk directly to each other, negotiating a shared artifact, a contract, a plan, without a central router deciding who's right. Valuable when the decision genuinely needs more than one perspective: architecture debates, code review as generator plus critic, adversarial verification.

No agent is the bottleneck. Every agent is a possible source of the lie the others believe.

Where it breaks

Error cascade. One agent's mistake becomes the next agent's trusted input, and because nobody is the designated arbiter, nobody is positioned to catch it before it compounds. The telephone game, with each retelling delivered in a confident voice.

Use it when: agents genuinely need to negotiate, not just divide labor. If the work splits into independent pieces, you don't need mesh; you need hub-spoke and are paying mesh's coordination tax for nothing.

Pattern 3 / 3

Hierarchy: the org chart you actually meant to draw

Supervisors of supervisors. A top-level manager delegates to team leads, who delegate to individual workers, the way a "Platform Architect" might hand off to a Backend Lead and a Frontend Lead, each running their own specialists.

Every layer you add is a game of telephone with a budget attached.

Where it breaks

Goal drift down the chain. Each layer conditions on the layer above it, not on the original objective, so by the third hop the worker agent is optimizing its subtask beautifully while the thing the top of the chain actually wanted goes quietly unserved.

Use it when: the system is genuinely too large for one supervisor's context window to hold, and not one layer before that. Most hierarchies get built for a task that still fit in two levels.

The real decision isn't the topology. It's noticing when yours stopped fitting.

Systems don't usually fail because someone picked the wrong shape on day one. They fail because the shape was right for three agents and nobody revisited it at nine. Hub-spoke quietly turns into an overloaded hierarchy. A clean hierarchy grows a mesh of side-channels because two leads started talking directly to unblock each other.

Before you add a fourth agent, ask one thing: does this new piece of work exist because the task needs it, or because the topology needs feeding?

Questions worth answering directly

What are the main multi-agent architecture patterns?

Three: hub-spoke (one supervisor delegates and synthesizes), mesh (agents negotiate directly, no central router), and hierarchy (supervisors of supervisors, delegating down through layers).

What's the most common failure mode in multi-agent systems?

It depends on the shape. Hub-spoke bottlenecks at the supervisor. Mesh suffers error cascade between peers. Hierarchy suffers goal drift the further a worker sits from the original objective.

When should I use a hierarchical multi-agent system?

Only once the task genuinely outgrows one supervisor's context window. Most systems reach for hierarchy well before that point and pay its coordination cost for nothing.

Can multi-agent topologies be mixed?

Yes, and most production systems do: hub-spoke at the top, short hierarchy chains beneath it, and mesh reserved for the rare case that genuinely needs peer negotiation.

This page is one artifact of a larger practice.