CCA-F Study Day 29: Cross-Domain Scenario Practice

Multi-Agent Research System (Exam Scenario 3)

Review Day 9 of 10 | This scenario tests Domains 1, 2, and 5 simultaneously

Today's Focus

The Multi-Agent Research System is one of 6 exam scenarios (4 randomly selected per exam). It integrates concepts from Domain 1 (orchestration patterns, subagents, context isolation), Domain 2 (tool design, MCP, error handling), and Domain 5 (context management, error propagation, escalation). Today we synthesize these into production-ready architectural decisions under exam pressure.

This scenario presents a system where a coordinator agent delegates research tasks to specialist subagents that search, analyze, and synthesize information from multiple sources. Exam questions probe your ability to make correct trade-offs across domains simultaneously.

Core Concepts: The Architecture

1. Hub-and-Spoke Pattern (Domain 1)

The Multi-Agent Research System uses the Hub-and-Spoke (Coordinator-Subagent) pattern:

User Query → Coordinator Agent
                ├── Research Subagent A (Domain Expert)
                ├── Research Subagent B (Source Specialist)  
                └── Research Subagent C (Fact Checker)
             ← Synthesized Result

Critical architectural decisions the exam tests:

Each subagent has its own context window (isolated from siblings)
The coordinator controls what context flows TO each subagent (need-to-know basis)
Results flow BACK as structured artifacts, not raw conversation history
The coordinator synthesizes, not the subagents

2. Context Isolation (Domain 1 + Domain 5)

Why context isolation matters in research systems:

Prevents cross-contamination: Subagent A's findings should not bias Subagent B's search
Manages token costs: Each subagent receives only relevant context (lower token usage per call)
Enables parallel execution: Independent contexts = no shared-state conflicts
Preserves information provenance: You know which subagent produced which claim

3. Tool Distribution Across Subagents (Domain 2)

Each subagent gets 4-5 tools maximum. For a research system:

# Coordinator Agent tools:
tools = ["delegate_research", "synthesize_results", "request_clarification", "deliver_report"]

# Search Subagent tools:
tools = ["web_search", "academic_search", "retrieve_document", "extract_citations"]

# Analysis Subagent tools:
tools = ["compare_claims", "check_consistency", "score_relevance", "flag_contradiction"]

The exam tests whether you keep tool counts low per agent AND distribute them logically by responsibility.

4. Error Propagation (Domain 5)

When a subagent fails in a multi-agent research system:

class ResearchCoordinator:
    async def execute_research(self, query, subagents):
        results = {}
        errors = []
        
        for agent in subagents:
            try:
                result = await agent.research(query)
                if result.get("is_error"):
                    errors.append({
                        "agent": agent.name,
                        "errorCategory": result["errorCategory"],
                        "isRetryable": result["isRetryable"],
                        "context": result["context"]
                    })
                    if result["isRetryable"]:
                        result = await agent.research(query)  # One retry
                else:
                    results[agent.name] = result
            except TimeoutError:
                errors.append({
                    "agent": agent.name,
                    "errorCategory": "timeout",
                    "isRetryable": True
                })
        
        # Coordinator decides: partial results acceptable?
        if len(results) >= 2:  # Proceed with partial
            return self.synthesize(results, errors)
        else:  # Too many failures - escalate
            return {"escalate": True, "reason": "insufficient_sources", "errors": errors}

The exam tests: Do you propagate errors up with structured metadata? Do you handle partial failures gracefully? Do you distinguish retryable from permanent failures?

5. Progressive Summarization for Research (Domain 5)

Research systems accumulate context fast. The 5 risks from progressive summarization apply directly:

Information loss: A summarized source loses the specific quote needed later
Bias amplification: Summaries favor "interesting" findings over contradicting evidence
Error propagation: A misquoted stat in the summary persists through synthesis
Temporal confusion: "Recent study" in summary loses the specific date
Authority dilution: "Multiple sources confirm..." loses which specific sources

Correct approach: Pass structured artifacts (with source IDs, dates, confidence flags) between agents, not summarized prose.

Anti-Patterns & Exam Traps

❌ Wrong Answer (Exam Trap)	✅ Correct Approach	Why It's Wrong
Single agent with 15+ tools doing all research	Coordinator + specialist subagents with 4-5 tools each	Tool selection accuracy degrades beyond 5 tools per agent
Sharing full conversation history between subagents	Pass only the specific query and constraints each subagent needs	Context contamination biases independent research paths
Same-session fact-checking (agent reviews its own output)	Separate session for verification agent	Reasoning context bias: the model "remembers" its own logic and is less likely to challenge it
Using sentiment analysis to decide when to escalate	Escalate on: task complexity exceeding threshold, policy gaps, multi-system failure	Sentiment is unreliable for operational decisions; use programmatic structured criteria
Coordinator passes raw subagent outputs to user	Coordinator synthesizes, resolves contradictions, cites sources	The coordinator's job is synthesis and quality control, not passthrough
Retrying indefinitely on transient failures	Circuit breaker: 3 failures → open → stop attempting	Unbounded retries cascade into resource exhaustion and cost overruns
Model self-reports confidence score for escalation	Programmatic checks: source count threshold, contradiction detection, coverage gaps	Self-reported confidence is not calibrated; use verifiable criteria

Code Example: Full Research System Architecture

import asyncio
import json
from anthropic import Anthropic

client = Anthropic()

# Coordinator orchestrates the research workflow
async def research_coordinator(user_query: str):
    # Phase 1: Plan the research (what subagents to spawn, what each investigates)
    plan_response = client.messages.create(
        model="claude-sonnet-4-20250514",
        max_tokens=1024,
        system="You are a research coordinator. Decompose the query into 2-3 independent research angles.",
        messages=[{"role": "user", "content": user_query}],
        tools=[{
            "name": "create_research_plan",
            "description": "Create a structured research plan with independent angles to investigate.",
            "input_schema": {
                "type": "object",
                "properties": {
                    "angles": {
                        "type": "array",
                        "items": {
                            "type": "object",
                            "properties": {
                                "focus": {"type": "string"},
                                "sources_to_check": {"type": "array", "items": {"type": "string"}},
                                "key_questions": {"type": "array", "items": {"type": "string"}}
                            },
                            "required": ["focus", "sources_to_check", "key_questions"]
                        }
                    }
                },
                "required": ["angles"]
            }
        }],
        tool_choice={"type": "tool", "name": "create_research_plan"}
    )
    
    plan = json.loads(plan_response.content[0].input)  # Structured output via forced tool
    
    # Phase 2: Fan-out to subagents (parallel, isolated sessions)
    tasks = [
        research_subagent(angle, session_id=f"research-{i}")
        for i, angle in enumerate(plan["angles"])
    ]
    subagent_results = await asyncio.gather(*tasks, return_exceptions=True)
    
    # Phase 3: Handle errors, synthesize results
    valid_results = []
    errors = []
    for i, result in enumerate(subagent_results):
        if isinstance(result, Exception):
            errors.append({"agent_index": i, "error": str(result), "isRetryable": True})
        elif result.get("is_error"):
            errors.append(result)
        else:
            valid_results.append(result)
    
    # Phase 4: Synthesize in a SEPARATE session (no subagent reasoning context)
    synthesis = client.messages.create(
        model="claude-sonnet-4-20250514",
        max_tokens=2048,
        system="Synthesize research findings. Cite sources. Flag contradictions.",
        messages=[{"role": "user", "content": json.dumps({
            "original_query": user_query,
            "findings": valid_results,
            "errors": errors,
            "instruction": "Synthesize findings. Note any gaps from failed subagents."
        })}]
    )
    
    return synthesis.content[0].text

🎬 Video to Watch

Building Effective AI Agents (Anthropic Webinar)

This official Anthropic session covers single-agent and multi-agent orchestration patterns with real production examples from companies deploying at scale. Focus on the multi-agent orchestration section (second half), specifically the discussion of when to decompose into subagents vs. keeping a single agent with tools.

Also read: When to use multi-agent systems (and when not to) (published June 21, 2026). This Anthropic blog post identifies the 3 situations where multi-agent consistently outperforms single-agent: context pollution, parallel tasks, and specialization.

📖 Reading

How we built our multi-agent research system (Anthropic Engineering, June 2025) - The actual architecture behind Claude's Research feature. 90.2% improvement over single-agent on internal evals.
Harness design for long-running application development (Anthropic Engineering, March 2026) - Three-agent architecture (planner, generator, evaluator) for multi-hour autonomous sessions.

🛠️ Hands-On Exercise (25 minutes)

Design a Multi-Agent Research System on Paper

Scenario: You are building a competitive analysis agent that researches competitors for a product team.

Draw the architecture (5 min): Coordinator + subagents. Label each agent's responsibility and tools (max 5 each).
Define the context flow (5 min): What does the coordinator pass TO each subagent? What structured format do results come BACK in?
Design error handling (5 min): What happens when one source is unavailable? When two subagents return contradictory data? When all sources time out?
Add the verification layer (5 min): Where does the fact-checker sit? Why must it be a separate session?
Identify the anti-patterns (5 min): List 3 ways this could go wrong and the correct mitigation for each.

Quick Quiz

Q1: In a multi-agent research system, Subagent A finds that "Company X reported $5B revenue in 2025" and Subagent B finds "Company X reported $4.2B revenue in 2025." What should the coordinator do?

A) Average the two values and report $4.6B B) Use the value from whichever subagent has a self-reported higher confidence score C) Flag the contradiction in the final report with both sources cited, and optionally spawn a verification subagent to resolve it D) Discard both values since they conflict and report "revenue data unavailable"

Q2: A coordinator agent needs to verify that its research subagent produced accurate output. Which approach is architecturally correct?

A) Add a verification step at the end of the same subagent's session B) Create a new agent session with only the output and source documents (no reasoning history) C) Have the coordinator itself verify by re-reading the sources D) Use the model's self-reported confidence score to determine accuracy

Q3: Your multi-agent research system has 3 subagents. Subagent 1 returns results successfully. Subagent 2 returns an error with isRetryable: true. Subagent 3 times out. What is the correct coordinator behavior?

A) Wait indefinitely for all subagents to complete before synthesizing B) Retry Subagent 2 once, apply a circuit breaker to Subagent 3, synthesize from available results while noting gaps C) Discard all results and return a generic "research failed" message D) Retry both Subagents 2 and 3 indefinitely until they succeed

Answers

Q1: C - The coordinator's job is synthesis and quality control. Contradictions get flagged with citations (information provenance). Self-reported confidence (B) is an anti-pattern. Averaging (A) is fabrication. Discarding (D) loses valid data.

Q2: B - Separate sessions avoid reasoning context bias. The verifier sees only the output + sources, not the reasoning that produced the output. Same-session review (A) is a documented anti-pattern. The coordinator (C) doing verification couples responsibilities. Self-reported confidence (D) is always wrong.

Q3: B - Structured error handling: retry retryable errors (bounded), apply circuit breakers to timeouts, proceed with partial results while documenting gaps. Unbounded retries (A, D) are anti-patterns. Generic errors (C) violate structured error response principles.

Tomorrow's Preview

Day 30: Final Review - Full-length timed practice exam simulation covering all 5 domains. We'll work through 15 scenario-based questions under exam conditions (2 minutes per question) and review the decision frameworks for each domain.