Scope Note
This article is a design note, not a universal proof. The equations below are stylized approximations used for topology comparison in planning and internal simulation. Real throughput depends on task mix, queue discipline, escalation policy, reviewer latency, and how much work can be parallelized safely.
1. What topology actually changes
Team topology changes four things at once: how quickly work fans out, where review queues form, how conflicts are reconciled, and whether an operator can reconstruct a clean accountability path afterward. That combination matters more than raw agent count. Adding agents to a bad shape often raises contention faster than it raises useful output.
The useful question is therefore not How many agents do we have? but Where do coordination edges and review gates sit? A topology is good when it keeps local work local, pushes only disagreements upward, and preserves one understandable responsibility chain per decision.
2. A minimal planning model
For design work, it is enough to estimate effective_throughput as completed decisions divided by total cycle time, where cycle time is approximated as execution time plus coordination delay plus review delay plus escalation delay.
A simple coordinator stress metric is coordinator_utilization approx arrival_rate * review_time / review_capacity. Once this ratio approaches 1.0, flat teams degrade sharply because every extra agent sends more work into the same bottleneck.
A simple traceability constraint is that each completed decision must map to one primary path: executor -> reviewer -> owner. Supporting evidence can be many-to-one, but final responsibility routing should not be.
3. Comparing common team shapes
Flat pool
Flat pools are easy to bootstrap and work well for small teams or low-stakes tasks. They fail when one reviewer or coordinator becomes the universal merge point. The symptom is not just latency. It is also shallow review, because the same gate is forced to scan too many partially related cases.
Dense mesh
Dense meshes maximize local communication freedom, but they also multiply negotiation edges. They are useful for exploration and research swarms, not for governed production work where every disagreement eventually needs a single owning decision. In practice, meshes tend to hide responsibility rather than distribute it.
Review cells with escalation
The most reliable production pattern is a small cell of agents that can coordinate locally, plus an explicit escalation edge for disagreements or exceptions. This keeps most traffic inside the cell while preserving a bounded route for conflicts and cross-cell dependencies.
4. Why review cells usually win
Review cells work because they separate two traffic classes. Routine coordination stays inside a small group where context is shared. Only low-frequency, high-cost events move upward. That reduces queue depth at upper layers and gives operators cleaner audit trails.
The important design move is not creating many layers. It is ensuring that upward moves are exceptional rather than normal. If every task touches two or three higher layers, the hierarchy has simply become a slow mesh.
5. Choosing cell size
The previous version of this article presented a closed-form n* formula as if team size had a universal optimum. That was too strong. In practice, the right size is empirical and domain-specific.
A better heuristic is to grow a cell until one of three signals appears: median review latency starts rising faster than output, the lead reviewer spends more time merging than judging, or escalation rate rises because the cell contains too many loosely related specialties.
For medium-complexity decision work, a useful starting default is 6-10 agents per review cell. Above that range, operators should look for natural sub-problems that can be split into separate cells with a narrow escalation interface between them.
6. What to instrument before reorganizing
- Queue length at each review gate
- Median and p95 time from evidence-ready to approved
- Share of tasks resolved locally vs escalated
- Number of handoffs per completed decision
- Fraction of decisions with a complete executor-reviewer-owner path
If these metrics are missing, topology redesign becomes guesswork. Measure first, then split, merge, or rewire.
7. Internal simulation takeaways
Internal queueing simulations and replay traces consistently showed the same pattern: flat pools are competitive at very small scale, then collapse when reviewer load concentrates. Review-cell structures were materially better on coordination-heavy work, typically delivering about two to four times the completed decisions per review hour once the flat baseline became saturated.
Those figures should be read as planning signals rather than production guarantees. The robust lesson is structural: localize routine coordination, narrow the escalation surface, and preserve one auditable decision path.
Conclusion
Topology is a controllable operating parameter, not an organizational aesthetic. For governed multi-agent systems, the strongest default is a small review cell with explicit escalation, not a giant flat pool and not a free-form mesh. Operators should size cells from observed queueing and escalation data, then re-topologize when reviewer saturation or ambiguous ownership starts to dominate cycle time.