Multi-Agent Coordination Patterns: When One Agent Isn't Enough

You've got a working Claude Code setup. Your CLAUDE.md points to a structured vault. Your axiom-principle-rule framework gives the agent your judgment, not just your knowledge. One agent handles your PO tasks well — story refinement, architecture review, stakeholder prep. Context engineering works for single-agent workflows.

Then Tuesday happens. Sprint planning starts in two hours. You need story analysis for six backlog items, architecture feedback on a tech debt proposal, and stakeholder talking points for a steering committee meeting. Same afternoon. You run the story analysis first. Twenty-five minutes. Then architecture feedback — but the agent starts referencing sprint planning language in its architecture assessment. By the time you get to stakeholder prep, the context is contaminated. Sprint velocity metrics bleed into executive talking points. Architecture constraints get applied to the wrong user stories.

You think: I'll just run multiple sessions. Three Claude Code instances, each pointed at the same CLAUDE.md, the same vault. Twenty minutes later, one agent recommends adding mobile support to the sprint. Another explicitly deprioritizes mobile. Same vault, same axioms — contradictory recommendations. You've discovered what every practitioner hits: the single-agent ceiling isn't about intelligence. It's about architecture. Or rather, the absence of one.

Why Multi-Agent Architecture Matters More Than Framework Choice

The single-agent ceiling has three failure modes, and recognizing which one you're hitting determines your fix.

Context overflow. Your single session accumulates instructions across tasks — story refinement criteria, architecture standards, stakeholder preferences — until the instructions compete. The agent tries to satisfy all constraints simultaneously. Sprint planning thoroughness conflicts with executive brevity. Architecture rigor conflicts with story simplicity. Not because the agent is confused — because conflicting instructions have equal weight in one context window.

Coherence degradation. Related to overflow but distinct. As a session runs longer, the agent's output drifts from the original intent. Your first story refinement is sharp. Your sixth is generic. Not because the agent forgot your standards — because earlier conversation turns push the original CLAUDE.md instructions further from the active context. The agent weighs recent conversation more heavily than system instructions. This is a known behavior, not a bug.

Sequential bottleneck. Some PO work is genuinely parallel — story analysis, architecture review, and stakeholder prep don't depend on each other. Running them sequentially in one session wastes time and introduces the contamination problem above. You're standing in line at a single register when three are open.

Here's the critical insight most practitioners miss: frameworks don't solve these problems. LangGraph chains agents together. CrewAI assigns roles. AutoGen enables free-form agent communication. But none of them tell you WHEN to split a single agent into multiple agents, or HOW to share context so the split doesn't create contradictions. Those are architecture decisions. As Anthropic's "Building Effective Agents" guide distinguishes: there are workflows (deterministic orchestration) and agents (autonomous tool use). Both need coordination patterns when you run multiple. The patterns are the architecture. The framework is the plumbing.

Microsoft's Agent Design Patterns guide catalogs enterprise-scale patterns — supervisor, group chat, orchestrator-worker, hierarchical. Valuable reference. But you don't need enterprise architecture diagrams for a solo PO coordinating three Claude Code sessions. You need practitioner patterns. The ones you discover when your multi-agent setup breaks on a Tuesday afternoon and you have to fix it before sprint planning starts.

One more constraint to name: cost. Each Claude Code session consumes tokens independently. Three parallel sessions use roughly three times the tokens of one sequential session. This isn't a reason to avoid multi-agent patterns — it's a reason to be deliberate about when you use them. The token cost is justified when the coordination produces better output than a single overloaded session. It's waste when you're splitting tasks that a single agent handles fine. The same context engineering discipline that taught you to fix context before rewriting prompts applies here: fix the architecture before adding agents.

Four AI Agent Orchestration Patterns for Practitioners

The patterns below aren't theoretical. They emerged from specific failures and the architecture that fixed each one. They're ordered by complexity — start at the top and move down only when pain forces you to.

Pattern 1: Single agent (default). Most tasks don't need multi-agent coordination. A well-configured Claude Code session with your CLAUDE.md and vault handles story refinement, research analysis, document drafting, and technical review. The pattern is: one session, one task type, close when done. The decision to stay here: if your output is coherent and you're not hitting context overflow, don't add complexity. Multi-agent coordination solves specific problems. Without those problems, it's over-engineering.

Pattern 2: Fan-out (parallel independent tasks). When you have multiple tasks with no dependencies between them, run them simultaneously. Story analysis + architecture review + stakeholder prep — each agent works independently, each with its own CLAUDE.md variant, results merged by you at the end. Boris Cherny, who built Claude Code, describes his own parallel session approach: multiple Claude Code instances working on different parts of a codebase simultaneously. If the creator uses fan-out for individual productivity, the pattern is validated at the practitioner level, not just enterprise scale.

The fan-out decision: are the subtasks independent? Would doing them sequentially produce the same result? If yes on both, fan-out. The risk: without shared context, agents may contradict each other. Fan-out works when the tasks don't share decision surfaces. When they do, you need Pattern 4.

Pattern 3: Pipeline (sequential dependent tasks). When one agent's output feeds the next agent's input. Research → analysis → recommendation. Each agent is a specialist — the research agent gathers data, the analysis agent evaluates it against your criteria, the recommendation agent synthesizes a stakeholder-ready output. Each stage's output is formatted for the next stage's input.

The pipeline decision: do the tasks have clear sequential dependencies? Does each stage require a different type of expertise or context? Pipelines shine when the stages are well-defined and the handoff format is explicit. They fail when the stages are fuzzy or the output format isn't structured enough for the next agent to consume reliably.

Pattern 4: Shared-context-hub (vault-coordinated specialists). This is the PO-specific pattern — and it's the one that solved the contradictory-recommendations problem from the opening. Multiple agents, each with a specialized role, but all reading the same vault. Same axioms, same principles, same decision framework. The structured vault you built in the Foundation track becomes the coordination mechanism. The axiom-principle-rule hierarchy becomes the shared decision brain.

The difference from fan-out: fan-out agents work independently and may contradict each other. Shared-context-hub agents share the same foundational context — your scope-intolerance axiom, your target-implementers principle, your acceptance-criteria rule. They can't contradict each other on judgment calls because they're reading the same judgment. They CAN differ on domain-specific analysis — the architecture agent sees different technical constraints than the story refinement agent — but the foundational decisions are consistent.

A note on Claude Code's built-in options: subagents run within a single session and report results back to the main agent — useful for focused subtasks like research or file analysis. Agent Teams (experimental) coordinate across separate sessions with direct inter-agent messaging. Both are implementations of these patterns. Subagents are a lightweight fan-out within one session. Agent Teams enable full shared-context-hub coordination. The patterns come first; the tooling implements them. Your Claude Code workflow started with single-agent proficiency — now you're extending it to multi-agent architecture.

The Vault as Shared Context for Agents

The shared-context-hub pattern works because of a specific design decision: agents share context through the vault, not through messages.

Most multi-agent tutorials describe agents "communicating" — passing messages, sharing results, updating shared state. That works for enterprise infrastructure where agents run as persistent services. For a PO running three Claude Code sessions, message-passing is impractical. Your agents don't run long enough to maintain a conversation with each other. They start, do their work, and produce output. The coordination has to be baked into the input, not negotiated during execution.

Here's what vault-coordinated context looks like. Each agent gets its own CLAUDE.md that shares three things:

# Shared across all agents (vault pointers)
vault_path: ~/vault
decision_framework: vault/axiom/, vault/principle/, vault/rule/
product_context: vault/product/current-sprint.md, vault/product/roadmap.md

And differs in one thing — the role-specific layer:

# Story refinement agent
role: sprint-story-analyst
focus: Analyze backlog items against acceptance criteria standards
output_format: structured story assessment with scope flags

# Architecture review agent
role: architecture-reviewer
focus: Evaluate technical proposals against architecture principles
output_format: architecture decision record with risk assessment

# Stakeholder prep agent
role: stakeholder-communicator
focus: Synthesize decisions into executive-appropriate summaries
output_format: talking points with decision rationale at leadership level

Three agents, three roles, one vault. The story refinement agent and the architecture review agent both read your scope-intolerance axiom. The story analyst applies it to sprint scope. The architecture reviewer applies it to technical scope. Different applications, same axiom. When you read both outputs, they're coherent — not because the agents coordinated with each other, but because they share the same decision foundation.

This is the practical answer to the counter-argument that "multi-agent fails because agents can't truly communicate." They can't, in the human sense. They don't need to. What they need is shared context — specifically, shared judgment context. Two agents reading the same vault with the same context engineering principles applied produce consistent output. Not identical output — they're analyzing different things. Consistent output — they're using the same criteria.

The "context fork" failure is the anti-pattern. Two agents diverge because one reads an outdated vault file while the other reads the current version. Or one agent gets a CLAUDE.md with a principle that the other agent doesn't see. The fix is atomic context: single source of truth for all agents. The vault IS the coordination protocol. If you update an axiom, every agent reads the updated axiom on their next invocation. No message-passing required. No synchronization protocol. Just files.

How do you know the coordination is working? Observability at the practitioner level is simple: compare outputs. After a fan-out session, read each agent's output side by side. Do the recommendations align on shared decision surfaces? After a shared-context-hub session, check that all agents applied the same axioms. If the story refinement agent and the architecture reviewer both flagged the same scope concern — your shared context is working. If they contradicted each other, trace which vault files each agent read. The failure is always in the input, not the intelligence.

Design Your Multi-Agent Workflow This Week

Can you describe your multi-agent system — what each agent does, how they coordinate, and why you chose that pattern over alternatives? If your agents produce coherent, non-contradictory output across parallel sessions — not because they talked to each other, but because they share the same decision brain — the architecture is working.

Here's this week's exercise:

1. Audit your single-agent pain. Run your normal PO workflow this week and note where one session breaks. Context overflow (instructions competing)? Coherence degradation (output quality drops across tasks)? Sequential bottleneck (parallel work done serially)? Contradictory output across sessions? Name the failure mode.

2. Match the failure to a pattern. No clear pain → stay single-agent (Pattern 1). Independent subtasks → fan-out (Pattern 2). Sequential dependencies → pipeline (Pattern 3). Contradictory output or shared decision surfaces → shared-context-hub (Pattern 4). Most POs land on fan-out or shared-context-hub.

3. Configure shared context. Create role-specific CLAUDE.md variants that share vault pointers but differ in task instructions. Test: give two agents the same judgment call (e.g., "Should we expand scope for this feature?"). If both agents apply your scope-intolerance axiom and reach consistent conclusions — the shared context is working.

4. Run a coordination test. Execute your PO workflow with the multi-agent pattern. Compare output coherence with the single-agent version. If the multi-agent output is faster AND more coherent — the architecture is paying off. If it's faster but contradictory — your shared context layer needs work. Go back to step 3.

5. Document what broke. The first coordination test always reveals something. A context fork. A handoff that doesn't format right. An axiom that two agents interpret differently. Document the failure. It's your first entry in a coordination pattern library that grows more valuable over time.

You know how to coordinate multiple agents. One agent uses your knowledge system well. Multiple agents share your decision framework and produce coherent output. But running three agents in parallel during sprint planning is a different cognitive mode than deep-focus refinement with one agent. How do you structure your time around these different agent configurations? Session types and flow-based batching match your cognitive mode to the right agent pattern — so you're not just coordinating agents, you're coordinating your own productivity around them.