Choosing a Multi-Agent Topology Is Choosing How It Fails

Once a system holds more than one agent, the design question quietly shifts. It stops being about what any individual agent can do and becomes a question about the connective tissue between them: who hands work to whom, where authority sits, and what any single node can observe about the whole. Borrowed from distributed systems, the word for that arrangement is topology, and it is not a diagram you draw after the fact to document what you built. It is the decision that sets what the system is capable of. Give the same set of agents the same instructions and connect them two different ways, and you get two systems that succeed at different things and, more revealingly, break in different ways.

Almost every real arrangement reduces to one of three shapes, or to a deliberate splice of them. One puts a single agent in charge and runs all traffic through it. One strings the agents into a line, each consuming what the one before it produced. One dispenses with the central agent entirely and lets the participants speak to each other. What separates them is not complexity or sophistication. It is which handful of properties each shape is willing to guarantee, and which it quietly abandons in order to do so. Competence with topologies is not reciting the three. It is reading a task closely enough to know which guarantees it actually depends on, then picking the shape that supplies those and spends its weakness somewhere the task can absorb it.

Three guarantees that cannot all hold at once

Before the shapes, the constraint that governs them. A multi-agent system might want three things: a trustworthy account of everything it did, the ability to keep running when a part of it dies, and clean interchangeable stages you can build and test one at a time. Call them accountability, resilience, and modularity. Each is desirable on its own. The uncomfortable fact is that the structural move that secures any one of them actively erodes another.

A complete account of what happened requires a place that saw everything, which means funneling all activity through one node, which is precisely what caps throughput and creates a part whose death is fatal. Surviving the death of any part requires having no such indispensable node, which is precisely what leaves no one holding the full record. Cleanly separable, testable stages require pinning down a fixed order of operations, which is precisely what makes total time additive and lets an early failure starve everything after it. No arrangement maximizes all three at once, because the feature you install to obtain one is the feature that spends another. This is why topology is a decision rather than a preference. To choose a shape is to name the two properties you are unwilling to give up and the one you have decided you can live without. The three canonical shapes are simply the three ways to resolve that choice.

Centralizing control buys a record and concentrates the risk

The first shape elects a single agent and makes it responsible for the entire job. It takes in the objective, breaks it apart, parcels the pieces out to specialists, gathers what they return, and decides the next move. The specialists work in isolation from one another; none of them has a channel to a peer. Whatever passes between agents passes through the one in the middle. Because that agent witnesses the whole execution, properties that are usually expensive to obtain come nearly for free here. There is exactly one seat from which to apply a policy, one component that holds the true state of the work underway, and one ledger in which every decision is already written. Debugging starts from a known location, since nothing happened that the central agent did not mediate. Recovery has an owner rather than being a shared responsibility no one actually holds. When the job genuinely requires a defensible reconstruction of what the system did and why, this shape hands you that reconstruction as a byproduct of how it is built, not as instrumentation bolted on afterward.

The liabilities are the same fact read from the other side: the central agent is load-bearing for everything. Its failure is the system’s failure, because nothing else knows how to run the job alone. Its rate of work is the system’s rate of work, since every message waits its turn at the same desk, and adding specialists does nothing to lift that ceiling. Its working memory swells in proportion to how much is happening, because holding the live state of every delegated task is its job, and the amount in flight is exactly what spikes when the system is busiest. The trade is legibility purchased with fragility, and it is a good trade in the precise case where a clean account of events is worth more than uptime or speed.

A line is the easiest shape to reason about and the slowest to run

The second shape lays the agents out in a fixed order and lets work flow down the line. What the first produces is the whole of what the second receives; what the second produces is the whole of what the third receives; the pattern holds to the last position. No agent carries more than one responsibility, and no agent reaches past its immediate neighbor. The payoff is the payoff of any well-factored assembly line. A single position can be exercised on its own, because its entire agreement with the world is one input and one output. A position can be rebuilt or upgraded in place as long as its replacement honors that same agreement, and nothing on either side of it needs to know. When the final result is wrong, the fault is locatable: walk the line, inspect the artifact each position left behind, and the bad one announces itself. For work that really is a chain of transformations, where each step consumes a well-defined thing the previous step made, this shape yields a system you can take apart and understand one joint at a time.

The price is paid in time and in fragility, and both scale with the length of the line. Nothing overlaps, so the total duration is every position’s duration added together. A longer line is unconditionally slower than a shorter one, and each position you insert adds its full cost to the whole. Fragility compounds a second way. A position that fails does not fail alone. Everything after it is left with nothing to act on, so a single break at one joint silences every joint downstream of it, propagating not as a visible error but as absence. Guarding against this means building the failure handling into every joint rather than only at the mouth of the line, so a break is caught and named where it occurs instead of traveling onward as silence or as corrupt output. The longer the line, the more joints there are at which that discipline has to actually hold, and one lapse anywhere reopens the cascade.

Dropping the coordinator buys survival and forfeits the account

The third shape is the first one inverted. Nobody is in charge. The agents address each other directly, and no single participant governs the flow of work. Surrendering central control is the entire point, because it purchases two things the centralized shape structurally cannot offer. The first is speed: a message goes straight from the agent that has it to the agent that needs it, with no obligatory stop at an intermediary sitting on the path of every exchange. The second is survival: with no indispensable node, no single death ends the system, so one agent can fall and the rest carry on, and capacity rises as participants are added rather than being pinned to whatever one coordinator can handle. For loosely joined work where staying up and staying fast outrank keeping a tidy history, discarding the coordinator is a clean structural gain.

The charge for it falls on accountability. With no central memory and no central ledger, no participant knows what the system as a whole actually did. Answering why some outcome occurred means questioning every agent that took part and stitching the story back together from pieces, and some of the story may be gone for good, recorded nowhere. There is a subtler cost as well. When many agents interact directly and nothing supervises the aggregate, behavior can emerge at the level of the whole that none of the parts would predict, and that collective behavior is harder to anticipate, harder to reproduce under test, and harder to fence in than the individual agents suggest it should be. Speed and survival on one side, observability and control on the other.

Read the task’s structure, then let it name the shape

The dependable way to land on a shape is to characterize the task before entertaining any topology, and to let the characterization do the choosing, instead of arriving with a favorite and filing the task down until it fits. Three questions expose the structure fast enough to be worth asking every time.

Ask first whether the work has a genuine chain of command. Is there one participant whose actual role is to break the goal down and steer the others, or are they colleagues with no natural superior among them? Real hierarchy is the thing the centralized shape exists to serve, and its record and its single locus of authority repay their cost when the work is hierarchical by nature and its history has to survive scrutiny. Absent that hierarchy, installing a coordinator invents a bottleneck that returns nothing, because you are buying centralized control the task never had a use for.

Ask next whether the work is an ordered transformation whose every step is locked to the result of the step before it. If the second step is genuinely unable to begin until the first has produced its output, then the order is a fact about the data and a line matches it exactly. The question that keeps you honest is whether the order is imposed by the data or merely inherited from habit. Steps that could just as well run in any sequence, or all at once, turn a line into a tax: you accept additive time and cascade exposure to serialize something that was never sequential to begin with.

Ask finally whether the participants are loosely joined, sharing no state and owing each other no particular order of contact. If they are, and if either survival or speed is a headline requirement, the coordinator-free shape lets them cooperate with no routing overhead and no central part to lose. The constraint that overrides this runs the other way. If the work answers to compliance, to regulation, or to the practical need to debug it later, and any of those demands one continuous record of what was decided, the coordinator-free shape cannot produce that record, because its scattered state can never be reassembled into a whole after the fact.

A generate-and-judge loop is broken until it is told when to stop

One further pattern earns a name of its own, both because it keeps reappearing and because it carries a requirement the others do not. Two agents form a loop. One produces a candidate, a draft or a plan or an answer. The other measures that candidate against a stated standard and hands back specific, structured criticism. The first uses the criticism to produce a better candidate, the second measures again, and around it goes. It is how a system sharpens its own output through repeated critique instead of settling for a single attempt.

What sets this pattern apart is that, left alone, it never ends. The two agents will trade candidates and critiques indefinitely unless something outside the exchange calls a halt. So the loop is only sound if it is built with two exits from the start: a standard of quality that, once cleared, stops it, and a ceiling on the number of rounds that stops it regardless when the standard is never cleared. Both are load-bearing. The quality bar is what lets the loop converge, by defining what would count as done. The round ceiling is what guarantees the loop halts even when convergence never comes. A generate-and-judge loop lacking a firm stop is not merely inefficient, it is defective, because nothing at all bounds how long it can run. The convergence test and the iteration limit are not refinements to add once the thing works. They are the difference between a pattern and a runaway process.

The sharpest failures come from forcing a shape onto the wrong task

Everything so far concerns how a shape behaves when it is used well and pressed to its limit. There is a second and nastier class of failure, and it comes from mounting a shape on a task whose structure contradicts it. These deserve naming because they are frequent and because they wear the disguise of bad luck when they are really design errors present from the first sketch.

Route everything through a central agent for a task with no real chain of command, and you have built a bottleneck that adds delay and coordination overhead while contributing no control, because the participants could have reached each other directly and the agent enthroned in the middle is coordinating nothing that needed coordinating. Wire up a coordinator-free mesh for a task that owes someone a complete account of itself, and you have built a system that cannot satisfy its own requirement, because no quantity of retrofitted logging will rebuild one continuous decision record out of state that was distributed by design. Neither of these is a shape buckling under load. Each was the wrong shape from the opening line of the design, and the friction it generates surfaces at every level until someone changes the shape rather than tuning around it.

Splicing shapes is legitimate, and the joints are where the work goes

Few real systems hold a single shape from end to end, and combining them is a sound response rather than an admission of defeat. A central agent can delegate one slice of the job to an internal line when that slice is a strictly ordered transform. A position within a line can spread a subtask across a set of loosely joined peers when that subtask parallelizes without friction. When one complicated task contains parts with honestly different structures, fitting each part to the shape that suits it is the correct move.

What a hybrid costs, it costs at the joints. Every place two shapes meet is a place where control and data have to pass out of one structure and into another, and each of those crossings has to be engineered deliberately. What exactly is the artifact that crosses? How is a failure at the crossing noticed and handled, given that the two sides fail in different ways and expect different things of each other? How does state travel from a single owner into a spread of peers, or out of a line’s forward flow into a central agent’s tracked memory? The habit that keeps a hybrid from degrading into a knot is to settle which region of the task each shape serves before drawing anything, and then to treat every crossing between shapes as a real interface with a stated contract, not as an incidental handoff that happened to survive the first test run.

Wiring is the one decision you commit to early and rarely revisit

Of all the choices in a multi-agent design, the arrangement of the agents is among the earliest and among the least forgiving to change later, because reworking it means recutting the seams between components rather than editing a line of instruction. Centralized control is the correct shape when a defensible record and a single point of authority matter more than throughput or survival. A line is correct when the data itself dictates an order and cleanly separable, testable stages justify paying for time in series. A coordinator-free mesh is correct when survival and speed matter more than the ability to say afterward exactly what happened. A generate-and-judge loop is a legitimate fourth shape for as long as it carries the stop condition that keeps it from running without end. And a hybrid is legitimate the moment different regions of a task have different structures, provided the joints between shapes are engineered as carefully as the shapes themselves. None of these is a default you reach for by reflex. Each is the right answer to a task with a particular structure, and the only reliable way to find it is to read the structure of the task before committing to the structure of the system.