CCAR-F Agentic Architecture and Orchestration Practice Question
An architect is designing a Claude agent that must coordinate a research subagent and a summarization subagent to produce a market brief. The research subagent gathers sources, and the summarization subagent condenses them. The architect wants to avoid the orchestrator losing track of which subagent produced which artifact across many turns. Which TWO architectural practices best support reliable artifact tracking and handoff? (Choose two.)
⚠ Common exam trap
The trap here is assuming the orchestrator can remember provenance from context alone, when durable attribution requires explicit identifiers and metadata rather than model recall.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Give each subagent a distinct tool name and require its results to be returned as tool_result blocks tied to a unique tool_use_id.
Reliable multi-subagent handoff depends on explicit, structured provenance rather than model inference. Unique tool names and tool_use_id linkage bind each result to its requesting subagent, while metadata embedded in artifacts keeps identity attached even after summarization or storage. Raising temperature, concatenating outputs, or trusting the system prompt to remember provenance all remove or weaken those structural guarantees, making misattribution more likely across many turns.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Concatenate all subagent outputs into a single summary string before appending them to the orchestrator's history.
Why it's wrong here
Merging outputs into one string destroys the boundaries between producers and makes it impossible to tell which subagent contributed which content. It also breaks the tool_use and tool_result pairing expected by the API if done incorrectly. This approach actively worsens attribution and undermines the handoff the architect wants to make reliable.
- ✗
Rely on the orchestrator's system prompt to remember which subagent produced each artifact without adding identifiers.
Why it's wrong here
The model has no persistent memory beyond the conversation contents; a system prompt cannot reliably track provenance across many turns and compactions. Without explicit identifiers, attribution depends on the model's inference and degrades as history grows. This is precisely the fragile design the architect is trying to avoid in a multi-subagent pipeline.
- ✓
Give each subagent a distinct tool name and require its results to be returned as tool_result blocks tied to a unique tool_use_id.
Why this is correct
Distinct tool names plus unique tool_use_id values create an explicit, machine-checkable link between each request and its result. The orchestrator can map every artifact to the subagent that produced it without relying on prose in the model's output. This directly prevents misattribution across many turns and keeps the conversation history auditable.
- ✗
Increase the orchestrator's temperature so it explores multiple attribution hypotheses before choosing one.
Why it's wrong here
Higher temperature increases variability in the orchestrator's output and makes attribution less deterministic, which is the opposite of what reliable tracking requires. Attribution should be enforced by structure, not by sampling. This change would likely introduce more misattributions and inconsistent handoffs across turns, harming the market brief's traceability.
- ✓
Embed the subagent identity inside each artifact as structured metadata fields alongside the content payload.
Why this is correct
Structured metadata such as a producer field and a timestamp travels with the artifact itself, so identity survives copying, summarization, and storage outside the conversation. Even if history is compacted, the artifact remains self-describing. This complements tool-level linkage and supports reliable handoff between research and summarization stages.
About these practice questions
Courseiva writes every CCAR-F question from scratch — 271 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Anthropic exam blueprint
This CCAR-F practice question is part of Courseiva's free Anthropic certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the CCAR-F exam.