Multi-Agent Workflows: Coordination Cost and Control

Multi-agent systems can help when work can be divided into distinct tasks with useful parallelism or independent review. They can also add model calls, repeated context, orchestration complexity, and failure paths. There is no general result that a single agent or a multi-agent design is always better; compare them on the same task and quality criteria.

1. Communication structure

An all-to-all group chat has up to M(M-1) directed communication paths for M agents if every agent can send to every other agent. A hub-and-spoke workflow has a number of connections proportional to M. These are topology counts, not token-cost formulas. Actual model usage depends on which messages are sent, which agents are invoked, how much history each invocation receives, and whether context is pruned or cached.

Common designs include:

• Sequential workflow: each step receives a compact artifact from the previous step.
• Hub-and-spoke: a controller delegates bounded subtasks and collects results.
• Parallel specialists: independent agents work on separate inputs and a reducer combines their outputs.
• Group chat: participants share an evolving transcript; useful for some collaborative tasks but requires turn limits and termination criteria.

Use the least complex structure that meets the measured quality requirement. Parallelism can lower elapsed time while increasing total token use.

2. A simple history-growth model

Suppose a workflow makes N model calls. Each call includes a fixed prompt of P tokens, and the shared transcript grows by an average of L tokens after each call. If every call receives the full growing history, total input tokens are:

This model is quadratic in N because later calls repeat more history. It is a simplified example, not a universal complexity law for multi-agent systems. Real systems may summarize, truncate, share partial histories, use cached prefixes, or invoke agents a different number of times.

Hypothetical calculation

For N=20 calls, a 2,500-token fixed prompt per call, and 600 new transcript tokens after each call, the estimated input is:

This excludes output tokens, tool payloads, and any separate prompts or retries. It illustrates why repeated history should be measured and, where safe, summarized or replaced with structured state.

3. Failure modes to design for

• Non-termination: agents repeat critique or delegation without reaching an acceptance condition.
• Context divergence: workers act on different versions of state, files, or tool results.
• Duplicate work: multiple agents independently perform the same expensive analysis or action.
• Conflicting side effects: concurrent agents modify the same resource.
• Unbounded fan-out: a task spawns more workers than the value of parallel work justifies.
• Unsafe delegation: an agent receives tools or data it does not need.

These are engineering risks to test for, not claims that every framework exhibits them.

4. Practical controls

1. Set explicit limits for calls, worker count, wall-clock time, input/output tokens, and total spend.
2. Give workers narrow tasks, minimal necessary context, and scoped tools.
3. Pass structured outputs or artifacts rather than entire conversational histories when possible.
4. Version shared state and make side-effecting operations idempotent or serialized.
5. Define objective completion and escalation criteria before the workflow starts.
6. Record per-agent usage and evaluate success, quality, latency, and cost against a simpler baseline.

An evaluator-optimizer pattern is one option: generate a candidate, run deterministic checks, return concise failures, and stop after a bounded number of iterations. An LLM judge may help where deterministic checks are insufficient, but its judgments also need evaluation.

5. Evidence and further reading

Anthropic's Building Effective Agents discusses composable agent patterns and recommends choosing complexity according to the task. It is guidance, not a benchmark proving that multi-agent systems underperform in general.

• Wu et al., AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation.
• Microsoft AutoGen documentation.
• LangGraph documentation for graph-based stateful workflows.