S3 · Multi-Agent Research System

spans 60% of the blueprint D1 27% D2 18% D5 15% ~15 items per lab on the exam 20 items in the bank

Domains this lab exercises

Expected items apply the blueprint weight to a 60-item exam. Bank items are what exists for this lab today — a coverage figure, never a score.

Domain	Weight	Expected items	Statements	Bank items for this lab
D1 Agentic Architecture & Orchestration	27%	16.2	7	8
D2 Tool Design & MCP Integration	18%	10.8	5	6
D5 Context Management & Reliability	15%	9.0	6	6

Task statements in play 8 of 30

Each statement is a published objective; every practice item on this site cites one. Expand a row for the guide's key facts and, where the guide names them, the anti-patterns that supply that statement's distractors.

ID	Statement	Domain	Bank items
1.1	Design and implement agentic loops for autonomous task execution Keys The agentic loop lifecycle: sending requests to Claude, inspecting stop_reason ("tool_use" vs "end_turn"), executing requested tools, and returning results for the next iteration How tool results are appended to conversation history so the model can reason about the next action The distinction between model-driven decision-making (Claude reasons about which tool to call next based on context) and pre-configured decision trees or tool sequences Implementing agentic loop control flow that continues when stop_reason is "tool_use" and terminates when stop_reason is "end_turn" Adding tool results to conversation context between iterations so the model can incorporate new information into its reasoning Avoiding anti-patterns such as parsing natural language signals to determine loop termination, setting arbitrary iteration caps as the primary stopping mechanism, or checking for assistant text content as a completion indicator Anti-patterns parsing natural language signals to determine loop termination setting arbitrary iteration caps as the primary stopping mechanism checking for assistant text content as a completion indicator	D1	3
1.2	Orchestrate multi-agent systems with coordinator-subagent patterns Keys Hub-and-spoke architecture where a coordinator agent manages all inter-subagent communication, error handling, and information routing How subagents operate with isolated context—they do not inherit the coordinator's conversation history automatically The role of the coordinator in task decomposition, delegation, result aggregation, and deciding which subagents to invoke based on query complexity Risks of overly narrow task decomposition by the coordinator, leading to incomplete coverage of broad research topics Designing coordinator agents that analyze query requirements and dynamically select which subagents to invoke rather than always routing through the full pipeline Partitioning research scope across subagents to minimize duplication (e.g., assigning distinct subtopics or source types to each agent) Implementing iterative refinement loops where the coordinator evaluates synthesis output for gaps, re-delegates to search and analysis subagents with targeted queries, and re-invokes synthesis until coverage is sufficient Routing all subagent communication through the coordinator for observability, consistent error handling, and controlled information flow	D1	4
1.3	Configure subagent invocation, context passing, and spawning Keys The Task tool as the mechanism for spawning subagents, and the requirement that allowedTools must include "Task" for a coordinator to invoke subagents That subagent context must be explicitly provided in the prompt—subagents do not automatically inherit parent context or share memory between invocations The AgentDefinition configuration including descriptions, system prompts, and tool restrictions for each subagent type Fork-based session management for exploring divergent approaches from a shared analysis baseline Including complete findings from prior agents directly in the subagent's prompt (e.g., passing web search results and document analysis outputs to the synthesis subagent) Using structured data formats to separate content from metadata (source URLs, document names, page numbers) when passing context between agents to preserve attribution Spawning parallel subagents by emitting multiple Task tool calls in a single coordinator response rather than across separate turns Designing coordinator prompts that specify research goals and quality criteria rather than step-by-step procedural instructions, to enable subagent adaptability	D1	3
1.6	Design task decomposition strategies for complex workflows Keys When to use fixed sequential pipelines (prompt chaining) versus dynamic adaptive decomposition based on intermediate findings Prompt chaining patterns that break reviews into sequential steps (e.g., analyze each file individually, then run a cross-file integration pass) The value of adaptive investigation plans that generate subtasks based on what is discovered at each step Selecting task decomposition patterns appropriate to the workflow: prompt chaining for predictable multi-aspect reviews, dynamic decomposition for open-ended investigation tasks Splitting large code reviews into per-file local analysis passes plus a separate cross-file integration pass to avoid attention dilution Decomposing open-ended tasks (e.g., "add comprehensive tests to a legacy codebase") by first mapping structure, identifying high-impact areas, then creating a prioritized plan that adapts as dependencies are discovered	D1	5
2.1	Design effective tool interfaces with clear descriptions and boundaries Keys Tool descriptions as the primary mechanism LLMs use for tool selection; minimal descriptions lead to unreliable selection among similar tools The importance of including input formats, example queries, edge cases, and boundary explanations in tool descriptions How ambiguous or overlapping tool descriptions cause misrouting (e.g., analyze_content vs analyze_document with near-identical descriptions) The impact of system prompt wording on tool selection: keyword-sensitive instructions can create unintended tool associations Writing tool descriptions that clearly differentiate each tool's purpose, expected inputs, outputs, and when to use it versus similar alternatives Renaming tools and updating descriptions to eliminate functional overlap (e.g., renaming analyze_content to extract_web_results with a web-specific description) Splitting generic tools into purpose-specific tools with defined input/output contracts (e.g., splitting a generic analyze_document into extract_data_points, summarize_content, and verify_claim_against_source) Reviewing system prompts for keyword-sensitive instructions that might override well-written tool descriptions	D2	3
5.1	Manage conversation context to preserve critical information across long interactions Keys Progressive summarization risks: condensing numerical values, percentages, dates, and customer-stated expectations into vague summaries The "lost in the middle" effect: models reliably process information at the beginning and end of long inputs but may omit findings from middle sections How tool results accumulate in context and consume tokens disproportionately to their relevance (e.g., 40+ fields per order lookup when only 5 are relevant) The importance of passing complete conversation history in subsequent API requests to maintain conversational coherence Extracting transactional facts (amounts, dates, order numbers, statuses) into a persistent "case facts" block included in each prompt, outside summarized history Extracting and persisting structured issue data (order IDs, amounts, statuses) into a separate context layer for multi-issue sessions Trimming verbose tool outputs to only relevant fields before they accumulate in context (e.g., keeping only return-relevant fields from order lookups) Placing key findings summaries at the beginning of aggregated inputs and organizing detailed results with explicit section headers to mitigate position effects Requiring subagents to include metadata (dates, source locations, methodological context) in structured outputs to support accurate downstream synthesis Modifying upstream agents to return structured data (key facts, citations, relevance scores) instead of verbose content and reasoning chains when downstream agents have limited context budgets	D5	4
5.3	Implement error propagation strategies across multi-agent systems Keys Structured error context (failure type, attempted query, partial results, alternative approaches) as enabling intelligent coordinator recovery decisions The distinction between access failures (timeouts needing retry decisions) and valid empty results (successful queries with no matches) Why generic error statuses ("search unavailable") hide valuable context from the coordinator Why silently suppressing errors (returning empty results as success) or terminating entire workflows on single failures are both anti-patterns Returning structured error context including failure type, what was attempted, partial results, and potential alternatives to enable coordinator recovery Distinguishing access failures from valid empty results in error reporting so the coordinator can make appropriate decisions Having subagents implement local recovery for transient failures and only propagate errors they cannot resolve, including what was attempted and partial results Structuring synthesis output with coverage annotations indicating which findings are well-supported versus which topic areas have gaps due to unavailable sources Anti-patterns Why silently suppressing errors (returning empty results as success) or terminating entire workflows on single failures are both anti-patterns	D5	4
5.6	Preserve information provenance and handle uncertainty in multi-source synthesis Keys How source attribution is lost during summarization steps when findings are compressed without preserving claim-source mappings The importance of structured claim-source mappings that the synthesis agent must preserve and merge when combining findings How to handle conflicting statistics from credible sources: annotating conflicts with source attribution rather than arbitrarily selecting one value Temporal data: requiring publication/collection dates in structured outputs to prevent temporal differences from being misinterpreted as contradictions Requiring subagents to output structured claim-source mappings (source URLs, document names, relevant excerpts) that downstream agents preserve through synthesis Structuring reports with explicit sections distinguishing well-established findings from contested ones, preserving original source characterizations and methodological context Completing document analysis with conflicting values included and explicitly annotated, letting the coordinator decide how to reconcile before passing to synthesis Requiring subagents to include publication or data collection dates in structured outputs to enable correct temporal interpretation Rendering different content types appropriately in synthesis outputs—financial data as tables, news as prose, technical findings as structured lists—rather than converting everything to a uniform format	D5	6

The lab

Rendered from certs/ccar-f-architect-foundations/scenarios/s3.md — the lab document is the source, this page is a view of it.

Primary domains: D1 Agentic Architecture & Orchestration (27%) · D2 Tool Design & MCP Integration (18%) · D5 Context Management & Reliability (15%) — spans 60%

Identical domain profile to s1.md. This is the heart of the 27% domain that no CPN course teaches — if only one lab gets built properly, make it this one or S4.

Brief

A multi-agent research system on the Claude Agent SDK. A coordinator agent delegates to specialized subagents: one searches the web, one analyzes documents, one synthesizes findings, one generates reports. The system researches topics and produces comprehensive, cited reports.

Task statements in play

ID	Statement
1.1	Design and implement agentic loops for autonomous task execution
1.2	Orchestrate multi-agent systems with coordinator-subagent patterns
1.3	Configure subagent invocation, context passing, and spawning
1.6	Design task decomposition strategies for complex workflows
2.1	Design effective tool interfaces with clear descriptions and boundaries
5.1	Manage conversation context to preserve critical information across long interactions
5.3	Implement error propagation strategies across multi-agent systems
5.6	Preserve information provenance and handle uncertainty in multi-source synthesis

The decisions it tests

Subagents do not inherit context. The single most testable fact in this scenario: a subagent does not automatically receive the coordinator's conversation history or share memory between invocations. Context must be passed explicitly in the prompt — which means the synthesis subagent needs the complete findings from the search and analysis agents included in its prompt, not a reference to them.

Hub-and-spoke, deliberately. The coordinator manages all inter-subagent communication. Routing everything through it buys observability, consistent error handling, and controlled information flow. Subagents talking directly to each other loses all three.

allowedTools must include Task. A coordinator cannot spawn subagents at all unless the Task tool is permitted. Mechanical, and exactly the kind of thing an exam item hinges on.

Parallelism is one response, not several turns. Spawn parallel subagents by emitting multiple Task calls in a single coordinator response. Issuing them across separate turns serializes the work.

Partition scope to avoid duplicate work. Assign distinct subtopics or source types per subagent. The guide also names the opposite risk: decomposition so narrow that broad research topics end up incompletely covered.

Goals, not procedures. Coordinator prompts should specify research goals and quality criteria rather than step-by-step instructions, so subagents can adapt. Pair this with iterative refinement: the coordinator evaluates synthesis output for gaps, re-delegates targeted queries, and re-invokes synthesis until coverage is sufficient.

Provenance survives the handoff. Use structured data formats that keep content separate from metadata — source URLs, document names, page numbers — so citations remain attributable through synthesis. Losing attribution mid-pipeline is how a "cited report" stops being one.

Reference build

A coordinator with an AgentDefinition per role, each with its own system prompt and restricted tools
allowedTools including Task; two subagents spawned in a single response to show real parallelism
Explicit context passing: the synthesis prompt carries the full findings, structured so URLs and page numbers stay attached
Scope partitioned by subtopic, with a note on where narrow decomposition would lose coverage
A refinement loop: synthesis reports gaps → coordinator re-delegates → synthesis re-runs
fork_session used once to compare two synthesis strategies from a shared baseline

Traps

Assuming shared memory or inherited history between coordinator and subagents.
Subagent-to-subagent communication "for efficiency" — loses observability and error handling.
Parallel Task calls spread across turns.
Step-by-step coordinator prompts that prevent subagent adaptation.
Truncate over structure — summarizing findings down before synthesis and losing provenance, instead of passing structured content with metadata intact.