CCA-F Study Day 3/20: Multi-Agent Orchestration Patterns

Domain 1: Agentic Architecture & Orchestration (~25-27% of exam)

Today's Focus

Today is the day you commit the five canonical multi-agent coordination patterns to memory. This is one of the highest-yield topics on the exam. The CCA-F tests whether you can select the right pattern for a given scenario — not just list them. Expect at least 3-4 questions that describe a system and ask which orchestration pattern applies. The exam also tests whether you understand why patterns fail when misapplied.

Anthropic published an official blog post on April 10, 2026 — "Multi-agent coordination patterns: Five approaches and when to use them" — which is the authoritative source for this material. Today's content aligns with that post.

Core Concepts

The Five Canonical Patterns

#	Pattern	Structure	Best For
1	Generator-Verifier	One produces → another validates → loop	Quality-critical output with explicit eval criteria
2	Orchestrator-Subagent (Hub-and-Spoke)	Coordinator delegates → specialists report back	Clear task decomposition with bounded subtasks
3	Agent Teams	Persistent workers claim from shared queue	Parallel, independent, long-running subtasks
4	Message Bus	Publish/subscribe event routing	Event-driven pipelines with growing agent ecosystem
5	Shared State	All agents read/write a persistent store	Collaborative work where agents build on each other's findings

Pattern 1: Generator-Verifier (Simplest, Most Deployed)

How it works: A generator produces output. A verifier evaluates it against explicit criteria. If rejected, feedback returns to the generator. The loop repeats until acceptance or max iterations.

Critical exam concept: The verifier MUST run in a separate session to avoid reasoning context bias. If the verifier shares the same conversation history as the generator, it has seen the generator's reasoning and will be biased toward accepting the output.

When to use: Code generation (write → test), fact-checking, compliance verification, rubric-based grading — any domain where an incorrect output costs more than an additional generation cycle.

Failure modes:

Verifier with no explicit criteria → rubber-stamps everything ("early victory problem")
Generator can't address verifier feedback → system oscillates without converging
Must include max iteration limit + fallback strategy (escalate to human, return best attempt with caveats)

Pattern 2: Orchestrator-Subagent (Hub-and-Spoke)

How it works: A central coordinator plans work, delegates bounded tasks to specialized subagents, and synthesizes results. Each subagent has its own context window and reports distilled findings back.

Claude Code uses this pattern directly — the main agent dispatches subagents in the background for codebase search and investigation while continuing primary work.

When to use: Tasks with clear decomposition and minimal interdependence between subtasks. Automated code review (security check + style check + test coverage → synthesized review).

Failure modes:

Information bottleneck: Cross-subagent discoveries must travel through the orchestrator. Details get lost or summarized away after multiple handoffs.
Sequential execution: Unless explicitly parallelized, subagents run one after another — incurring multi-agent token costs without speed benefit.

Pattern 3: Agent Teams

How it works: A coordinator spawns persistent worker agents. Workers claim tasks from a shared queue, work autonomously across multiple steps, and accumulate domain specialization over time. Workers stay alive (unlike subagents, which terminate after one bounded task).

Key distinction from Orchestrator-Subagent: Worker persistence. Subagents handle one task and terminate. Teammates stay alive across assignments, building context that improves performance.

When to use: Large-scale codebase migrations (each worker handles one service independently), batch processing with sustained multi-step work.

Failure modes:

Workers operating on shared resources → conflicting edits
Variable completion times → coordinator must handle partial completion
No inter-worker communication — findings can't flow between teammates

Pattern 4: Message Bus

How it works: Agents interact through publish/subscribe. A router delivers messages to subscribed agents. New agent types can join the ecosystem without rewiring existing connections.

When to use: Event-driven pipelines (security operations, alert processing) where workflow emerges from events rather than a predetermined sequence, and the agent ecosystem grows over time.

Failure modes:

Tracing/debugging is hard (cascade across 5+ agents)
Router misclassification → silent failure (handles nothing but never crashes)
Still has a central component (the router) as a single point of failure

Pattern 5: Shared State

How it works: No central coordinator. Agents read from and write to a shared persistent store (database, filesystem, document). Work starts when the store is seeded and ends at a termination condition.

When to use: Research synthesis where multiple agents explore different facets of a question and build on each other's findings in real time. Also: when eliminating single points of failure is a priority.

Failure modes:

Reactive loops: Agent A writes → Agent B responds → Agent A responds back → infinite cycle burning tokens without convergence
Duplicate work (two agents investigate the same lead)
Requires first-class termination conditions: time budget, convergence threshold ("no new findings for N cycles"), or a designated termination agent

Agent Teams vs. Subagents — The Table You Must Memorize

Feature	Subagents	Agent Teams
Context	Own window; results return to caller	Own window; fully independent
Communication	Report back to main agent only	Teammates can message each other
Coordination	Main agent manages all work	Shared task list with self-coordination
Best for	Focused tasks where only results matter	Complex work requiring collaboration
Token cost	Lower (summarized back)	Higher (each is full Claude instance)
Persistence	Terminates after one bounded task	Stays alive across assignments

Anti-Patterns & Exam Traps

Trap #1: Same-Session Self-Review

Wrong answer: "Use the same agent to generate code and then review it in the same conversation."

Why it's wrong: The verifier has seen the generator's reasoning in the conversation history. This creates reasoning context bias — the model is psychologically anchored to its own prior output and will be less likely to catch errors.

Correct: Separate sessions for generator and verifier. The verifier receives only the output artifact, not the generation reasoning.

Trap #2: Choosing Sophistication Over Fit

Wrong answer: "Implement a shared-state multi-agent system for a code review pipeline with known sequential steps."

Why it's wrong: Code review has a predictable workflow (receive PR → run checks → synthesize). Orchestrator-subagent handles this cleanly. Shared-state adds coordination complexity (duplicate work, reactive loops) without benefit.

Correct: Match pattern to structural requirements. Start with the simplest pattern that works.

Trap #3: Confusing Subagents with Agent Teams

Wrong answer: "Use subagents for a large codebase migration where each worker handles one service over multiple steps."

Why it's wrong: Subagents terminate after one bounded task. A multi-step migration requires persistent workers that accumulate context about their assigned service.

Correct: Agent Teams for sustained, multi-step work. Subagents for quick, one-shot subtasks.

Trap #4: Message Bus When You Need Shared Findings

Wrong answer: "Use a message bus for research synthesis where agents should build on each other's discoveries."

Why it's wrong: If agents are publishing events to share findings (not trigger actions), shared state is the better fit. The message bus still has a central router; shared state is fully decentralized.

Anthropic's Official Decision Framework

Memorize these decision questions:

How long do workers need context? Short → Orchestrator-Subagent. Long → Agent Teams.
How predictable is the workflow? Known sequence → Orchestrator-Subagent. Event-driven → Message Bus.
Do agents need each other's findings? No → Agent Teams. Yes → Shared State.
Events or accumulated knowledge? Events → Message Bus. Knowledge → Shared State.

Code Examples

Generator-Verifier Pattern (Separate Sessions)

import anthropic

client = anthropic.Anthropic()

def generator_verifier_loop(task: str, max_iterations: int = 3) -> str:
    """Generator-Verifier with separate sessions (no shared context)."""
    
    output = None
    
    for iteration in range(max_iterations):
        # GENERATOR SESSION — fresh conversation each time
        gen_messages = [{"role": "user", "content": task}]
        if output and feedback:
            gen_messages = [{"role": "user", "content": f"{task}\n\nPrevious attempt feedback: {feedback}\n\nRevise accordingly."}]
        
        gen_response = client.messages.create(
            model="claude-sonnet-4-20250514",
            max_tokens=2048,
            messages=gen_messages
        )
        output = gen_response.content[0].text
        
        # VERIFIER SESSION — sees ONLY the output, never the generator's reasoning
        ver_response = client.messages.create(
            model="claude-sonnet-4-20250514",
            max_tokens=1024,
            messages=[{
                "role": "user",
                "content": f"""Evaluate this output against the following criteria:
1. Factual accuracy
2. Completeness (all points addressed)
3. Code correctness (if applicable)

Output to evaluate:
{output}

Respond with JSON: {{"accepted": true/false, "feedback": "specific issues if rejected"}}"""
            }]
        )
        
        result = json.loads(ver_response.content[0].text)
        if result["accepted"]:
            return output
        feedback = result["feedback"]
    
    # Fallback: return best attempt with caveat
    return f"[MAX ITERATIONS REACHED] Best attempt:\n{output}"

Hub-and-Spoke (Orchestrator-Subagent)

import asyncio
from anthropic import Anthropic

client = Anthropic()

async def orchestrator_subagent(document: str) -> dict:
    """Orchestrator delegates to specialist subagents in parallel."""
    
    # Define specialist subagent tasks
    tasks = {
        "security_review": "Analyze this code for security vulnerabilities. Report findings as JSON.",
        "style_check": "Check this code against PEP 8 style guidelines. Report violations as JSON.",
        "test_coverage": "Identify untested code paths. Report as JSON with line numbers.",
    }
    
    # Fan out to subagents (each gets its own session/context)
    async def run_subagent(name: str, instruction: str) -> dict:
        response = client.messages.create(
            model="claude-sonnet-4-20250514",
            max_tokens=1024,
            messages=[{
                "role": "user",
                "content": f"{instruction}\n\nDocument:\n{document}"
            }]
        )
        return {"agent": name, "result": json.loads(response.content[0].text)}
    
    # Parallel execution
    results = await asyncio.gather(*[
        run_subagent(name, instruction) 
        for name, instruction in tasks.items()
    ])
    
    # Orchestrator synthesizes
    synthesis_response = client.messages.create(
        model="claude-sonnet-4-20250514",
        max_tokens=2048,
        messages=[{
            "role": "user",
            "content": f"Synthesize these code review findings into a unified report:\n{json.dumps(results, indent=2)}"
        }]
    )
    
    return {"individual_results": results, "synthesis": synthesis_response.content[0].text}

Pattern Selection Decision Tree

def select_pattern(requirements: dict) -> str:
    """Decision tree for multi-agent pattern selection."""
    
    if requirements.get("quality_critical") and requirements.get("explicit_eval_criteria"):
        return "generator-verifier"
    
    if requirements.get("clear_decomposition") and requirements.get("bounded_subtasks"):
        return "orchestrator-subagent"
    
    if requirements.get("parallel_long_running") and requirements.get("independent_workers"):
        return "agent-teams"
    
    if requirements.get("event_driven") and requirements.get("growing_ecosystem"):
        return "message-bus"
    
    if requirements.get("collaborative") and requirements.get("shared_discoveries"):
        return "shared-state"
    
    # Default recommendation from Anthropic
    return "orchestrator-subagent"  # Handles widest range with least overhead

Video to Watch

"Anthropic's Blueprint for Building Lean, Powerful AI Agents" — This video covers Anthropic's philosophy of simple, composable patterns over complex frameworks for agentic systems. Focus on the section discussing when a single agent suffices vs. when you need multi-agent orchestration, and how the patterns compose together.

Also highly relevant: "Claude Code Advanced Patterns: Subagents, MCP, and Scaling to Real Codebases" (Anthropic webinar, March 2026) — covers how Claude Code implements orchestrator-subagent in practice.

Reading

Primary (MUST READ): Multi-agent coordination patterns: Five approaches and when to use them — Anthropic's official blog post (April 10, 2026). This is the exam's source material for orchestration patterns.
Secondary: Building Effective Agents — The foundational post from December 2024 covering when to use single vs. multi-agent.
Bonus: How we built our multi-agent research system — Real production example of orchestrator-subagent at Anthropic (June 2025).

Hands-On Exercise (20 minutes)

Design a multi-agent document analysis system on paper (or in a text file):

The system receives a 50-page contract and must extract: key dates, financial terms, risk clauses, and compliance issues.
Draw the data flow diagram. Label each agent, its inputs, and its outputs.
Decide: Which pattern do you use? (Hint: is there quality-critical output? Clear decomposition? Shared findings?)
Add a verification step. Where does it go? Does the verifier need a separate session?
Add error handling: What happens if the "risk clause" agent finds nothing? Is that success or failure?

Expected answer: Orchestrator-Subagent (clear decomposition, bounded subtasks) with a Generator-Verifier layer on the extraction outputs. Each extraction subagent reports back to the coordinator. A separate verification pass (in its own session) validates extracted data against the source document.

Quick Quiz

Question 1: A team is building a system where Agent A generates code and Agent B reviews it. Both agents share the same conversation history. What is the primary risk?

A) Higher token costs due to duplicate context B) Reasoning context bias — the verifier is anchored to the generator's reasoning C) Rate limiting from too many API calls D) The verifier will always reject the generator's output

Question 2: A security operations center needs to process alerts from 8 different sources. New alert types are added quarterly. Investigation workflows vary based on alert classification. Which pattern fits best?

A) Generator-Verifier B) Orchestrator-Subagent C) Message Bus D) Shared State

Question 3: You're migrating 40 microservices from Flask to FastAPI. Each service has its own dependencies, tests, and deployment config. The migrations are independent — one service's migration doesn't affect another's. Each migration takes 15-30 minutes of multi-step work. Which pattern is best?

A) Orchestrator-Subagent — dispatch one subagent per service B) Agent Teams — persistent workers accumulate context per service C) Shared State — agents build on each other's migration findings D) Message Bus — publish migration events for workers to subscribe to

Answers

1: B — Reasoning context bias. The verifier has seen the generator's chain of thought and is psychologically anchored to accepting it. The fix is separate sessions.

2: C — Message Bus. Event-driven pipeline, growing ecosystem (new alert types quarterly), workflow emerges from events rather than predetermined sequence.

3: B — Agent Teams. Workers are persistent (multi-step, 15-30 min), independent (no interdependence), and benefit from accumulated context about their assigned service. Orchestrator-Subagent (A) would work for short one-shot tasks, but these migrations require sustained multi-step work.

Tomorrow's Preview

Day 4: Hooks System — You'll learn about programmatic interceptors that fire at agent lifecycle events, why they're the ONLY correct answer for deterministic enforcement (never prompts), and how to write hooks that block dangerous operations, audit activity, and track costs.