Multi-Agent Coordination: Patterns and Pitfalls

Multi-agent systems promise to tackle complex tasks by dividing work among specialized agents. The reality: most teams encounter cascading failures, exponential cost growth, and debugging nightmares. Here's how to do it right.

When to Use Multiple Agents

Before reaching for multi-agent architecture, confirm you actually need it. Use multiple agents when:

• Parallelizable subtasks exist — Different agents can work simultaneously on independent pieces
• Specialization reduces errors — A dedicated code-review agent is more accurate than a generalist
• Context window constraints — The full problem exceeds what a single agent can hold in context
• Different models serve different needs — Use a cheap model for classification, an expensive one only for synthesis

Don't use multiple agents for complexity theater. A well-designed single agent with good tools usually outperforms a poorly-designed multi-agent system.

The Orchestrator-Worker Pattern

The most reliable multi-agent topology is the orchestrator-worker pattern:

The orchestrator decides which workers to invoke and in what order. Workers are stateless and specialized. The orchestrator holds state and makes coordination decisions.

Failure Isolation

Every worker must have explicit failure handling. Never let a single worker failure cascade to the entire pipeline:

• Timeout budgets — Each worker has a maximum execution time; the orchestrator handles timeouts gracefully
• Partial results — Design the system to produce useful output even if one worker fails
• Retry with backoff — Workers retry transient failures; orchestrator decides when to escalate
• Circuit breakers — Automatically disable a failing worker to prevent resource exhaustion

Shared State Management

Multi-agent systems need a shared state store that all agents can read from and write to atomically. We use LangGraph's state management for Python-based systems and a Redis + PostgreSQL combination for cross-language deployments. Key rules:

• State updates are atomic—no partial writes
• All state changes are logged to the audit trail
• Workers are read-heavy; only the orchestrator writes final state
• Use optimistic locking for concurrent worker updates

Cost Management

Multi-agent costs multiply. A workflow with 5 agents each costing $0.02 costs $0.10—10x a single-agent approach. Mitigation strategies:

• Use smaller models for worker agents; reserve frontier models for the synthesizer
• Cache worker outputs aggressively—workers often process the same documents multiple times
• Set hard cost caps per workflow; abort if total spend exceeds budget