multi-agent-patterns

Multi-Agent Architecture Patterns

Distribute work across multiple LM instances w/ isolated context windows. Sub-agents exist to isolate context, not to anthropomorphize roles.

When to Activate

• Single-agent context limits constrain task complexity
• Tasks decompose into parallel subtasks
• Different subtasks need different tools | system prompts
• Building multi-domain agent systems

Core Concepts

Three patterns: supervisor/orchestrator (centralized), peer-to-peer/swarm (flexible handoffs), hierarchical (layered abstraction). Key principle: context isolation — sub-agents partition context, not simulate org roles. Requires explicit coordination protocols & consensus mechanisms avoiding sycophancy.

Token Economics

Architecture	Token Multiplier	Use Case
Single agent	1x	Simple queries
Agent w/ tools	~4x	Tool-using tasks
Multi-agent	~15x	Complex research/coordination

BrowseComp: token usage explains 80% of performance variance. Model upgrades often outperform doubling token budgets — model selection & multi-agent architecture are complementary.

Parallelization

Tasks w/ independent subtasks: assign each to dedicated agent w/ fresh context. All work simultaneously -> total time approaches longest subtask, not sum of all.

Architectural Patterns

Pattern 1: Supervisor/Orchestrator

User Query -> Supervisor -> [Specialist, Specialist, Specialist] -> Aggregation -> Final Output

Use when: Clear decomposition, cross-domain coordination, human oversight needed Pros: Strict workflow control, easier human-in-the-loop Cons: Supervisor context bottleneck, cascade failures, "telephone game" problem

Telephone Game Fix: forward_message tool lets sub-agents pass responses directly to users:

def forward_message(message: str, to_user: bool = True):
    """Forward sub-agent response directly to user w/o supervisor synthesis."""
    if to_user:
        return {"type": "direct_response", "content": message}
    return {"type": "supervisor_input", "content": message}