Enterprise agentic AI, built to survive production.

Pattern7 min read

Multi-agent topologies: when a supervisor earns its latency

More agents is not more intelligence. Choose the smallest topology that keeps responsibilities legible.

By Naveen, Enterprise agentic AI architecture, aifanatic.pro

Multi-agent systems are easy to sketch and hard to operate. Each extra agent adds latency, cost, a new failure surface, and another prompt to keep in sync. Add one only when it buys something specific.

Four topologies, in order of preference

  1. Single agent with tools. One reasoning loop, many tools. Start here. It is the easiest to trace, test, and secure.
  2. Pipeline. Fixed stages, each an agent or a function: extract, validate, act. Use it when the order is known in advance.
  3. Supervisor and workers. A coordinator delegates sub-tasks to specialists. Use it when sub-tasks need different tools, models, or permissions.
  4. Graph or swarm. Agents hand off dynamically. Use it rarely, and only with strong tracing.

Reasons that justify splitting

Reasons that do *not* justify splitting: it matches the org chart, it looks impressive in a diagram, or the single prompt got long. A long prompt is a refactoring signal, not necessarily a topology signal.

The costs to price in

Every hop adds a model call. Every handoff loses information unless you pass a structured summary. Every agent boundary is a place where an error can be reinterpreted as fact by the next agent. Measure end-to-end latency and success rate for the single-agent baseline first; a topology change should beat it by a margin you can name.

Make handoffs contracts

Pass typed messages between agents: a task, its inputs, constraints, and a definition of done. Return typed results with a status field, not free text the next agent must interpret. This one habit prevents most multi-agent confusion.

Rule of thumb

If you cannot say in one sentence what each agent is *responsible for* and what it is *forbidden* to do, the boundaries are not ready.