Multi-agent topology is a cost model before it is an orchestration diagram

Multi-agent topology is a cost model before it is an orchestration diagram. A star, chain, tree, ring, or mesh does not merely describe who talks to whom. It determines how many times context is copied, how deep the sequential path becomes, where verification can sit, which node becomes a bottleneck, and how far one bad message can travel. The arrows are invoices and failure multipliers.

A supervisor-and-workers star buys auditability and low coordination overhead by concentrating routing and synthesis in one hub. Its depth is usually short, but every worker may receive a version of the same context and every result returns through the orchestrator. The hub becomes a token, latency, and availability bottleneck. This can still be the cheapest shape for decomposable, read-heavy work because the coordination contract is simple and the decision provenance is legible.

A chain prices work differently. Each stage sees a narrower local task, so context duplication can fall, but sequential latency accumulates and early errors contaminate every downstream stage. Its blast radius is the remaining pipeline. Chains suit ordered transformations where each output has a clear contract; they are expensive for exploratory work because one weak decomposition commits all later compute to the wrong path.

Trees add parallelism and context partitioning, then charge for aggregation and hierarchy depth. They work when tasks decompose recursively and supervisors can project only the state each specialist needs. If every level forwards full history, the tree is a context-duplication machine disguised as delegation. If summaries become too aggressive, it turns into a game of telephone. The economic lever is selective state projection, not the number of agents drawn in the box.

Meshes look resilient and flexible because peers can coordinate directly. They also create quadratic communication possibilities, duplicated beliefs, deadlock risk, and a much harder audit graph. Read-heavy collaboration can tolerate this; write-heavy work usually cannot. Concurrent agents updating shared state need versioned writes, reconciliation, or a canonical store, otherwise the apparent parallelism is purchased with conflict and repair. Multi-agent systems fail along their communication edges, and a mesh manufactures more edges than any other common shape.

The correct topology therefore follows workload economics: decomposability, read-versus-write intensity, verification dominance, latency budget, context size, and consequence of error. Causal credit assignment is easier in explicit chains and stars than in dense peer interaction. Negotiated backpressure is easier when ownership and queue boundaries are visible. Even the price of human review changes according to where the topology exposes a stable checkpoint.

There is one precise concession: for small experiments, drawing the simplest topology that makes the behavior understandable is often better than building an elaborate cost model from estimates. Early uncertainty can dominate measured differences. But the experiment should instrument context replication, model calls, sequential depth, queue delay, retries, and failed edges. Once the design carries production volume or consequential effects, “the framework made this pattern easy” is not a topology rationale.

I want every orchestration diagram annotated with expected calls, tokens copied, critical-path depth, state owners, verification gates, and retry fan-out. Cost is an architectural property; multi-agent topology is where that property becomes visible. Choose the graph by the bill and failure behavior it creates, not by how convincingly it resembles an organization chart.