Claude Certified Associate - Foundations
Call Kai
Learn
Practice Test
Spaced Repetition
Match
Flashcards
Knowt Play1/21
Earn XP
Description and Tags
examtopics
Name | Mastery | Learn | Test | Matching | Spaced | Call with Kai | Chat |
|---|
No analytics yet
Send a link to your students to track their progress
22 Terms
The synthesis agent receives summarized findings from the web search and document analysis agents, then passes a consolidated summary to the report generator. During testing, you discover the generated reports make factual claims without proper citations – the report generator cannot attribute statements to their original sources because that metadata was lost during the summarization steps. What’s the most effective approach to ensure proper source attribution in the final reports?
A. Have the report generator query the web search agent to re-locate sources for claims in the final report.
B. Have each agent output structured data separating content summaries from source metadata (URLs, document names, page numbers).
C. Skip summarization and pass full raw outputs from web search and document analysis directly to the report generator.
D. Instruct the synthesis agent to embed source references inline within its summary text using a consistent citation format.
Correct Answer: B
Have each agent output structured data separating content summaries from source metadata.
Why B is Correct
The root cause of the problem is that source metadata is being lost during the summarization steps. The fix is to preserve that metadata structurally from the very beginning of the pipeline, so it travels alongside the content through every agent handoff.
By having each agent output a structured format — for example, a JSON object with separate fields for summary and sources — the metadata never gets entangled with the content text and therefore can never be accidentally dropped. The synthesis agent can then pass both the consolidated summary and the merged source list forward, and the report generator has everything it needs to cite properly.
This is the most robust and scalable solution because it fixes the problem at the architectural level rather than patching it downstream.
Why the Other Answers Are Wrong
Option | Why It's Wrong |
|---|---|
A | Querying the web search agent after the fact to re-locate sources is unreliable — search results change over time, and there's no guarantee the same sources will be found again. It also creates unnecessary extra steps and latency. |
C | Passing full raw outputs bypasses the purpose of having a multi-agent pipeline. It bloats the context window, wastes tokens, potentially exceeds context limits, and undermines the efficiency the summarization agents were designed to provide. |
D | Embedding citations inline in the summary text is fragile — it relies on consistent formatting that can break or be misinterpreted in later steps. Structured data (Option B) is far more reliable than trying to parse citations out of free-form prose. |
The key exam principle here: in multi-agent pipelines, metadata (like source attribution) should be treated as a first-class citizen in the data structures passed between agents — not an afterthought embedded in text.
After the web search agent finds 25 sources (120K tokens of raw content), the document analysis agent extracts key insights (15K tokens), and the synthesis agent produces a coherent narrative draft (3K tokens), the coordinator must pass context to the report generation agent for the final output with proper source citations. What context-passing strategy provides the best balance of completeness and efficiency?
A. Pass the full accumulated context from all prior agents.
B. Pass the synthesis draft along with a structured source index that maps key claims to their source URLs and relevant excerpts.
C. Pass only the synthesis draft and have a separate post-processing pipeline match claims to sources and insert citations after the report is generated.
D. Pass a condensed summary of all prior stages that preserves the main findings and attributes them to sources by name only.
Correct Answer: B
Pass the synthesis draft along with a structured source index that maps key claims to their source URLs and relevant excerpts.
Why B is Correct
This question is fundamentally about context window efficiency vs. completeness — a core tension in multi-agent design.
Option B threads the needle perfectly:
The synthesis draft (3K tokens) carries the coherent narrative the report generator needs to write from
The structured source index preserves the critical metadata (URLs, excerpts) needed for citations without re-including all the raw content
Together, this is a fraction of the 120K+ tokens of accumulated context, yet contains everything the report generator actually needs to do its job
It directly solves the citation problem (learned from Q1) by keeping source metadata structured and attached to specific claims
This is the architectural best practice: pass forward what the next agent needs, not everything that came before.
Why the Other Answers Are Wrong
Option | Why It's Wrong |
|---|---|
A | Passing all 120K+ tokens of accumulated context is massively inefficient, likely exceeds context limits, and buries the report generator in noise it doesn't need. Earlier agents already did the distillation work — don't undo it. |
C | Post-processing citation matching is unreliable. Matching claims to sources after the report is generated risks misattribution, missed citations, and adds a fragile extra pipeline stage. Citations should be grounded during generation, not appended afterward. |
D | Source names without URLs or excerpts are insufficient for proper citation. A report that cites "a BBC article" without a link or quote isn't properly attributed. This approach loses too much metadata to be useful. |
The key exam principle here: each agent handoff should pass a purposefully curated payload — the distilled output of prior work plus the specific metadata the next agent needs — rather than the full accumulated history or a stripped-down version that loses critical information.
Your multi-agent research pipeline crashed after processing12 of 28 documents. The web search agent had identified relevant sources, the document analyzer had partially completed extraction, and the synthesizer had begun pattern identification. You need to resume processing without repeating work or losing fidelity of prior findings. What state management approach best balances information fidelity with context efficiency when restoring agent state?
A. Have each agent persist a structured export to a known location. On resume, the coordinator loads the manifest and injects relevant state into agent prompts.
B. Index all agent outputs in a shared vector store. When resuming, each agent queries the store using semantic search to retrieve relevant prior findings.
C. Have each agent maintain its own persistent state file and reload it independently at the start of each session.
D. Persist the coordinator’s conversation log containing all task delegations and responses, providing this to agents when resuming.
Correct Answer: A
Have each agent persist a structured export to a known location. On resume, the coordinator loads the manifest and injects relevant state into agent prompts.
Why A is Correct
This approach gets the architecture right on every dimension:
Structured exports preserve information with full fidelity — progress, findings, and metadata are stored explicitly, not inferred
A known location with a manifest gives the coordinator a single source of truth — it knows exactly what was completed, what was partial, and what hasn't started
Coordinator-managed injection means agents receive precisely the context they need for their specific resumption point — no more, no less
It cleanly separates storage (what was done) from orchestration (what to do next), which is the correct responsibility split in a coordinator-agent architecture
This is the pattern that mirrors real-world fault-tolerant pipeline design: checkpoint, manifest, resume.
Why the Other Answers Are Wrong
Option | Why It's Wrong |
|---|---|
B | Semantic search is probabilistic — an agent querying a vector store might miss its own prior findings if the query isn't framed correctly. Critical state restoration cannot rely on fuzzy retrieval; you need deterministic access to known checkpoints. |
C | Agents reloading their own state independently removes the coordinator from the loop entirely. The coordinator loses visibility into what's been completed, making it impossible to orchestrate the resume correctly or avoid duplicating work across agents. |
D | The conversation log is a record of delegations and instructions, not a structured representation of findings. It conflates orchestration history with agent output, is verbose, and doesn't give agents clean access to the specific prior findings they need. |
The key exam principle here: in fault-tolerant multi-agent systems, the coordinator owns the recovery logic. Agents should checkpoint their work in structured, deterministic formats, and the coordinator should control what state gets injected where on resume — not leave agents to figure it out themselves.
You’ve configured the system so that all four subagents have access to the complete set of 18 tools. During testing, agents frequently call tools outside their specialization – the synthesis agent attempts web searches, and the report generator tries to analyze documents. What is the primary cause of this poor tool selection behavior?
A. Choosing from 18 tools instead of 4-5 relevant ones increases decision complexity beyond reliable selection thresholds.
B. The tool definitions consume too much context window space, leaving insufficient room for task content.
C. The agents’ role descriptions in their system prompts conflict with having access to tools outside that role.
D. The coordinator cannot track which capabilities each subagent has, leading to misrouted tasks.
Correct Answer: A
Choosing from 18 tools instead of 4-5 relevant ones increases decision complexity beyond reliable selection thresholds.
Why A is Correct
This is a cognitive load / decision quality problem. When an agent is presented with 18 tools, the model must evaluate every option against the current task — and with a large, undifferentiated toolset, the signal separating "right tool" from "wrong tool" gets weaker.
LLMs make better decisions with fewer, clearly relevant choices
When all 18 tools are available, there's no structural guardrail preventing the synthesis agent from "reasoning its way" into using a web search tool — even if its system prompt says it shouldn't
The fix is scoping tool access per agent: give each agent only the 4-5 tools appropriate for its role, making wrong-tool selection nearly impossible rather than merely discouraged
The problem isn't that agents are ignoring instructions — it's that the architecture is asking them to self-police against a full toolset when they should never have seen those tools in the first place.
Why the Other Answers Are Wrong
Option | Why It's Wrong |
|---|---|
B | Context window consumption from tool definitions is a real concern at scale, but it's a secondary consequence, not the primary cause of incorrect tool selection behavior. Agents could have 18 tools with short descriptions and still misbehave. |
C | Role descriptions conflicting with tool access is backwards — the system prompt does define the role correctly, but access to out-of-scope tools creates the temptation. The conflict is architectural, not a prompt-writing failure. |
D | The coordinator misrouting tasks is a separate failure mode from agents themselves choosing wrong tools mid-task. The question describes agents actively reaching for tools outside their specialization, which is a tool-selection problem, not a task-routing problem. |
The key exam principle here: the most robust agent systems use least-privilege tool access — each agent receives only the tools it legitimately needs. Relying on instructions alone to prevent misuse of a broad toolset is fragile; the better fix is architectural scoping that makes the wrong choice unavailable.
The coordinator provides detailed step-by-step instructions to the web search subagent, specifying exact search queries, source priorities, and date filters. Production monitoring reveals three issues: (1) the subagent reports “insufficient results” rather than trying alternative approaches when pre-specified searches fail, (2) research quality drops for emerging topics that don’t match expected patterns, and (3) the subagent rarely surfaces valuable tangential sources. What’s the most effective way to improve subagent adaptability?
A. Implement a topic classification step where the coordinator categorizes requests as “well-defined” or “exploratory” and uses different instruction styles for each category.
B. Add explicit fallback directives to the detailed instructions: “If specified searches yield fewer than N results, attempt alternative query formulations before reporting failure.”
C. Remove procedural details entirely, delegating with simple goals like “research X thoroughly” and relying on the subagent’s general capabilities.
D. Specify research goals and quality criteria (coverage breadth, source diversity, recency) rather than procedural steps, letting the subagent determine its search strategy.
Correct Answer: D
Specify research goals and quality criteria rather than procedural steps, letting the subagent determine its search strategy.
Why D is Correct
All three symptoms in the question share a single root cause: the coordinator is over-specifying procedure instead of outcome. When you hand an agent a rigid script, you get rigid behavior.
D fixes this at the architectural level:
By specifying what good looks like (coverage breadth, source diversity, recency) rather than how to achieve it, the subagent retains the autonomy to adapt its approach when initial searches fail
The subagent can try alternative queries, broaden or narrow scope, and follow unexpected leads — because it was never constrained to a fixed sequence
This directly addresses all three issues: it can pivot when searches fail (1), adapt to emerging topics without predefined patterns (2), and naturally surface tangential sources while pursuing breadth (3)
This is the principle of goal delegation over procedure delegation — a coordinator's job is to define success, not script execution.
Why the Other Answers Are Wrong
Option | Why It's Wrong |
|---|---|
A | Adding a classification step is engineering around the symptom rather than fixing the cause. It adds coordinator complexity and still leaves the subagent procedurally constrained for "well-defined" queries — which is where most of the failures occur. |
B | Adding fallback rules is a patch, not a fix. It addresses failure (1) partially, but does nothing for issues (2) and (3). You'd need to anticipate every edge case with explicit rules — an unscalable approach that keeps the subagent brittle. |
C | Going to the opposite extreme — "research X thoroughly" with no guidance — removes quality criteria entirely. The subagent has no way to know what "thorough" means for this use case, leading to inconsistent results. Goals without criteria isn't delegation; it's abdication. |
The key exam principle here: effective coordinator-to-subagent delegation specifies outcomes and quality criteria, not procedures. The subagent's value is its ability to reason and adapt — over-specifying steps destroys that value, while under-specifying criteria removes accountability. D finds the right balance.
The synthesis agent completes its initial pass but flags that three key research questions remain unanswered because the web search and document analysis agents didn’t find relevant information on those specific subtopics. The coordinator currently proceeds directly to report generation, producing reports with incomplete coverage. What change would most effectively improve research completeness?
A. Have the report generation agent note which research questions couldn’t be answered, so users understand the limitations of the final output.
B. Increase the initial breadth of queries sent to web search and document analysis to reduce the probability of missing relevant information.
C. Have the coordinator evaluate synthesis output for gaps, then re-delegate to web search and document analysis with targeted queries before invoking synthesis again.
D. Give the synthesis agent direct access to web search tools so it can autonomously fill knowledge gaps without returning control to the coordinator.
Correct Answer: C
Have the coordinator evaluate synthesis output for gaps, then re-delegate to web search and document analysis with targeted queries before invoking synthesis again.
Why C is Correct
This answer implements a proper iterative feedback loop — one of the most important patterns in robust multi-agent systems.
The synthesis agent has already done the hard work of identifying the gaps — the coordinator just needs to act on that signal rather than ignore it
Re-delegating with targeted queries is far more efficient than a broad initial sweep, because now the system knows exactly what's missing
Returning through synthesis again ensures the new findings are properly integrated into a coherent whole, not just appended
This keeps the coordinator in its correct role: evaluating agent outputs and deciding what happens next — rather than blindly advancing the pipeline
This is the difference between a linear pipeline and an intelligent orchestration loop.
Why the Other Answers Are Wrong
Option | Why It's Wrong |
|---|---|
A | Documenting gaps in the final report is a transparency measure, not a completeness measure. It tells the user what's missing but makes no attempt to fix it. This accepts failure rather than addressing it. |
B | Broadening initial queries is a blunt instrument — it increases token consumption, processing time, and noise across every run, even when gaps don't occur. It also doesn't guarantee the specific missing subtopics will be found. Targeted re-querying (C) is strictly more efficient. |
D | Giving the synthesis agent direct web search access violates the single responsibility principle and undermines the coordinator's role. Agents acquiring tools outside their specialization creates unpredictable behavior — this is exactly the anti-pattern identified in Q4. |
The key exam principle here: multi-agent pipelines should implement evaluate → identify gaps → targeted re-delegation → re-integrate loops rather than linear pass-through sequences. The coordinator's value is precisely this ability to recognize incomplete output and orchestrate corrective action before proceeding.
The web search agent has gathered several relevant sources for a research topic. The document analysis agent now needs to examine these sources. How does information typically flow between these two specialized subagents?
A. The agents communicate through an event-driven message queue, with the document analysis agent subscribing to web search completion events.
B. The web search agent directly invokes the document analysis agent, passing the discovered sources as parameters.
C. The coordinator agent receives the web search agent’s output and includes relevant findings in the prompt when invoking the document analysis agent.
D. Both agents access a shared memory store where the web search agent writes findings and the document analysis agent reads them.
Correct Answer: C
The coordinator agent receives the web search agent's output and includes relevant findings in the prompt when invoking the document analysis agent.
Why C is Correct
This reflects the standard orchestration pattern in multi-agent systems built on LLMs:
Subagents don't talk to each other directly — they report back to the coordinator, which acts as the central hub of information flow
The coordinator receives the web search output, decides what's relevant, and injects that context into the next agent's prompt when invoking it
This keeps the coordinator in control of the pipeline, maintains clear visibility into what each agent knows, and allows the coordinator to filter, prioritize, or augment information between steps
It's also the most natural pattern given how LLM-based agents work: they receive a prompt, produce an output, and return — they don't maintain open connections to other agents
This is the hub-and-spoke model of multi-agent coordination, and it's the dominant pattern in LLM orchestration frameworks.
Why the Other Answers Are Wrong
Option | Why It's Wrong |
|---|---|
A | Event-driven message queues are a legitimate pattern in traditional distributed systems, but they're not how LLM-based multi-agent pipelines typically operate. This describes infrastructure-level messaging that adds complexity without matching how prompt-based agents naturally function. |
B | Agents directly invoking each other bypasses the coordinator entirely, removing its ability to oversee, filter, or redirect information flow. This creates tightly coupled agents and is the opposite of the recommended architecture. |
D | Shared memory stores can play a supporting role in agent systems (as seen in Q3), but as the primary communication mechanism between agents they remove the coordinator from the information flow and reintroduce the coordination visibility problem from Q4. |
The key exam principle here: in LLM-based multi-agent systems, the coordinator is the communication backbone. Subagents are stateless workers that receive prompts and return outputs — information flows through the coordinator, not directly between agents.
Production reviews reveal inconsistent handling of uncertainty in final reports. Sometimes conflicting subagent findings are synthesized into a single confident statement (losing nuance), while other times reports over-hedge with excessive qualifications (becoming unhelpful). When the web search agent returns “industry analysts estimate $50B market size (methodology varies)” and the document analysis agent returns “peer-reviewed study estimates $35B (±$7B, 95% CI),” the coordinator either picks one arbitrarily or produces vague statements like “the market may be $35B-$50B depending on factors.” What systematic approach best addresses this?
A. Configure subagents to only report findings meeting a high-confidence threshold, filtering uncertain information before it reaches the coordinator.
B. Add a verification subagent that cross-references findings across sources, only passing claims to synthesis that are corroborated by at least two independent sources.
C. Instruct the synthesis agent to structure reports with explicit sections distinguishing well-established findings from contested ones, preserving original source characterizations and methodological context.
D. Implement a confidence calibration layer that normalizes subagent uncertainty expressions to standardized probability scores (0.0-1.0), then weight-average findings by their calibrated confidence.
Correct Answer: C
Instruct the synthesis agent to structure reports with explicit sections distinguishing well-established findings from contested ones, preserving original source characterizations and methodological context.
Why C is Correct
The core problem isn't that uncertainty exists — it's that the system doesn't know what to do with uncertainty when it encounters it. C solves this by giving the synthesis agent a clear, systematic framework:
Preserving original source characterizations means the distinction between "analysts estimate" (methodology varies) and "peer-reviewed study, ±$7B, 95% CI" is never flattened into a single confident claim or a vague hedge
Explicit sections for well-established vs. contested findings gives the report a structure that naturally accommodates disagreement without either suppressing nuance or over-qualifying everything
This is calibrated communication: readers get the $35B figure with its statistical rigor and the $50B figure with its methodological caveat — and they can judge accordingly
It scales gracefully to any type of disagreement, not just this specific market size example
The fix is structural and instructional — teaching the synthesis agent how to handle uncertainty, not trying to eliminate it upstream or reduce it to a number.
Why the Other Answers Are Wrong
Option | Why It's Wrong |
|---|---|
A | Filtering out uncertain findings before they reach the coordinator destroys valuable information. The $50B analyst estimate and the $35B peer-reviewed figure are both meaningful — a report that only includes one because the other didn't meet an arbitrary confidence threshold is less accurate, not more. |
B | Requiring corroboration across two sources before passing findings to synthesis would discard the very disagreement the coordinator needs to handle. It also conflates "corroborated" with "correct" — two sources can agree and both be wrong, or two methodologically different sources can legitimately produce different valid estimates. |
D | Normalizing qualitative uncertainty expressions ("methodology varies") to numeric probability scores (0.0–1.0) is a false precision problem. You can't reliably map "analysts estimate" to a calibrated probability, and weight-averaging $35B and $50B into a single number ($42.5B?) loses exactly the methodological context that makes each figure meaningful. |
The key exam principle here: uncertainty in research findings should be preserved and structured, not eliminated or artificially resolved. The synthesis agent's job isn't to pick a winner or hedge everything equally — it's to represent the information landscape accurately, including where sources disagree and why.
In production, final reports frequently contain claims without proper source attribution. Investigation shows that while the web search and document analysis agents correctly attach citations to their outputs, the synthesis agent loses track of which sources support which conclusions when combining findings. What’s the most effective architectural change?
A. Require all subagents to output structured claim-source mappings that the synthesis agent must preserve and merge when combining findings from multiple sources.
B. Maintain complete transcripts of all subagent interactions and add a citation-resolution agent to analyze logs and determine attributions before report generation.
C. Add a verification step where the report generator uses semantic similarity matching against original sources to reconstruct which claims came from which documents.
D. Have the coordinator inject source identifier prefixes into text before each handoff, then parse these prefixes at report generation to reconstruct citations.
Correct Answer: A
Require all subagents to output structured claim-source mappings that the synthesis agent must preserve and merge when combining findings from multiple sources.
Why A is Correct
This should feel familiar — it's the same architectural principle from Q1 and Q2, now applied to a specific failure point (the synthesis agent):
The problem is that citations are being carried as unstructured text that gets lost during synthesis. The fix is to make source attribution structurally impossible to lose
By requiring every agent to output explicit claim-source mappings (e.g.
{"claim": "...", "sources": ["url1", "doc2, p.4"]}), citations become data fields that must be actively preserved or merged — not prose that can be accidentally summarized awayThe synthesis agent's job becomes well-defined: combine claims and carry forward their associated source lists
This fixes the problem at the point where it occurs (synthesis) rather than trying to reconstruct lost information downstream
This is the clean architectural fix: structured data contracts between agents that treat citations as first-class fields.
Why the Other Answers Are Wrong
Option | Why It's Wrong |
|---|---|
B | Adding a citation-resolution agent to analyze complete transcripts is expensive, complex, and unreliable. Reconstructing which claim came from which source by reading logs is an inference problem — you're trying to recover information that should never have been lost in the first place. |
C | Semantic similarity matching to reconstruct citations after the fact is probabilistic and error-prone. A synthesized conclusion may not closely match any single source sentence, especially when it combines findings from multiple sources. This is another downstream patch for an upstream structural problem. |
D | Injecting text prefixes into prose and parsing them later is fragile — prefixes can be dropped, reformatted, or lost during summarization just like inline citations in Q1. Structured data fields are far more robust than conventions embedded in free text. |
The key exam principle here: this question reinforces the lesson from Q1 and Q2 — metadata must be carried as structured data, not embedded in text. When the same problem recurs at a different pipeline stage, the solution is the same: enforce structured contracts that make metadata loss architecturally difficult, not just instructionally discouraged.
After the web search agent and document analysis agent complete their tasks, the coordinator invokes the synthesis agent. However, the synthesis agent responds that it cannot complete the task because no research findings were provided. What is the most likely cause of this issue?
A. The subagents need to share a single API connection to enable automatic context sharing between invocations.
B. The synthesis agent needs tools that can fetch results directly from the other agents’ conversation histories.
C. The coordinator did not include the outputs from the previous agents in the synthesis agent’s prompt.
D. The synthesis agent’s context window is not large enough to hold the combined outputs from both previous agents.
Correct Answer: C
The coordinator did not include the outputs from the previous agents in the synthesis agent's prompt.
Why C is Correct
This is a direct application of the core principle established in Q7: LLM-based agents are stateless. They know only what is in their current prompt — nothing more.
When the coordinator invokes the synthesis agent, it must explicitly include the web search and document analysis outputs in that prompt
If it doesn't, the synthesis agent starts with a blank slate and has no findings to work with — exactly the reported symptom
This is the most common and straightforward failure mode in multi-agent orchestration: the coordinator advances the pipeline but forgets to pass the prior context forward
The fix is simple: the coordinator must package the relevant prior outputs and inject them into the synthesis agent's invocation prompt
No exotic infrastructure explanation is needed — this is a basic prompt construction error.
Why the Other Answers Are Wrong
Option | Why It's Wrong |
|---|---|
A | There is no such thing as "automatic context sharing" via a shared API connection between LLM agents. Each invocation is independent. This describes a capability that doesn't exist in standard LLM-based multi-agent architectures. |
B | Agents don't have persistent conversation histories that other agents can query. Each agent invocation is stateless — there's no history store for the synthesis agent to fetch from, and adding such tools would be an unnecessarily complex fix for what is simply a missing prompt inclusion. |
D | A context window size limitation is a plausible secondary concern in some scenarios, but it would produce a different error (truncation or a token limit error) — not a message saying "no research findings were provided." The symptom points clearly to missing input, not insufficient capacity. |
The key exam principle here: LLM agents have no shared memory and no automatic awareness of other agents' outputs. The coordinator is solely responsible for ensuring each agent receives the context it needs, explicitly, in its prompt. If an agent says it has nothing to work with — the coordinator forgot to give it something.
Users report that final reports sometimes lack depth on specific subtopics. Investigation shows that the document analysis agent frequently identifies gaps – for instance, noting “the retrieved sources discuss API authentication but lack details on token refresh patterns” – but under the current strict pipeline, this insight isn’t actionable since search has already completed. What’s the most effective architectural change?
A. Add a research planning agent before the search phase that decomposes topics into specific sub-questions.
B. Have the analysis agent report specific gaps to the coordinator, which triggers targeted searches and re-invokes analysis until sufficient.
C. Have the coordinator review analysis output for gap indicators and re-invoke search with gap-informed queries when gaps are detected.
D. Have the synthesis agent attach confidence scores to each section and flag areas with insufficient coverage for manual review.
Correct Answer: B (with a nod to C)
Have the analysis agent report specific gaps to the coordinator, which triggers targeted searches and re-invokes analysis until sufficient.
Why B is Correct
This question rewards understanding of who should detect gaps and who should act on them — and the answer is that both responsibilities should be clearly owned:
The document analysis agent is best positioned to identify gaps because it's the one doing the deep reading — it knows what's missing in the sources it just analyzed (e.g. "token refresh patterns not covered")
That gap signal should be explicitly reported in structured output to the coordinator, not buried in prose
The coordinator then acts on that signal: re-querying search with targeted queries, feeding new sources back to analysis, and iterating until the gap is resolved
This creates a proper detect → report → re-delegate → re-analyze feedback loop, with each agent doing what it's best suited for
This is the iterative orchestration pattern from Q6, now applied to a gap identified mid-pipeline rather than at synthesis.
Why C Is Close But B Is Better
C is architecturally reasonable — the coordinator reviewing output for gap indicators is valid. But it makes the coordinator responsible for detecting gaps by parsing analysis output, which is less reliable than having the analysis agent explicitly flag them in structured form. B is cleaner because the agent that knows about the gap reports it directly.
Why the Other Answers Are Wrong
Option | Why It's Wrong |
|---|---|
A | Upfront research planning helps with known unknowns but can't anticipate gaps that only emerge during analysis. It addresses a different problem — initial scope definition — not mid-pipeline gap detection. |
D | Confidence scores and flagging for manual review are transparency measures, not completeness measures — the same failure mode as Q6's Option A. It tells users something is missing without attempting to fix it. |
The key exam principle here: agents should explicitly surface actionable signals (like gaps) in their structured output, and coordinators should be designed to act on those signals iteratively rather than treating each pipeline stage as a one-shot pass. A strict linear pipeline is fragile; feedback loops make systems resilient.
After the web search and document analysis subagents complete their tasks, the coordinator needs to spawn the synthesis subagent to synthesize the findings. What is the correct approach for providing the synthesis subagent with the information it needs?
A. Spawn the subagent with only a brief task description, relying on automatic context inheritance from the coordinator
B. Provide the subagent with tool definitions that allow it to request outputs from other subagents via callbacks
C. Pass reference identifiers and configure the subagent with read access to a shared memory store where other subagents deposited their results
D. Include the complete findings from both subagents directly in the synthesis subagent’s prompt
Correct Answer: D
Include the complete findings from both subagents directly in the synthesis subagent's prompt.
Why D is Correct
This is the fundamental principle of LLM-based agent architecture, tested again from a slightly different angle:
LLM agents are stateless — each invocation starts fresh with only what's in its prompt
There is no "automatic context inheritance," no persistent memory, no shared awareness between agents
The coordinator's core responsibility is to explicitly package and inject all necessary prior outputs into the next agent's prompt at invocation time
If the synthesis agent needs the web search findings and document analysis findings to do its job, they must be literally present in its prompt
This has been the correct answer pattern throughout this exam set (Q7, Q10) — and it's being tested again because it's the single most important architectural principle to internalize.
Why the Other Answers Are Wrong
Option | Why It's Wrong |
|---|---|
A | "Automatic context inheritance" does not exist in LLM-based multi-agent systems. Each agent invocation is independent. Relying on it produces exactly the failure mode described in Q10 — the agent reports it has nothing to work with. |
B | Giving the synthesis agent callback tools to pull outputs from other agents adds unnecessary complexity and coupling. It also inverts the correct responsibility: the coordinator should push context forward, not make the synthesis agent responsible for fetching it. |
C | Shared memory stores can play a supporting role in persistence and fault recovery (as in Q3), but as the primary mechanism for passing findings between agents they add infrastructure complexity and indirection where a direct prompt inclusion is simpler and more reliable. |
The key exam principle here: when in doubt about how agents share information in LLM-based systems, the answer is almost always explicit prompt inclusion by the coordinator. There is no magic — only what's in the prompt.
When the agent calls lookup_order and receives order details showing the item was purchased 45 days ago, how does the agentic loop determine whether to call process_refund or escalate_to_human next?
A. The orchestration layer automatically routes to the next tool based on the order’s status field.
B. The order details are added to the conversation and the model reasons about which action to take.
C. The agent executes the remaining steps in a tool sequence planned at the start of the request.
D. The agent follows a pre-configured decision tree mapping order attributes to specific tool calls.
Correct Answer: B
The order details are added to the conversation and the model reasons about which action to take.
Why B is Correct
This describes how the agentic loop actually works in LLM-based systems:
When
lookup_orderreturns results, those results are added to the conversation as a tool result messageThe model then reads the full conversation context — the original request, the tool call, and the returned data — and reasons about what to do next
In this case, it sees "45 days ago" and reasons against whatever policy context it has (e.g. "refunds allowed within 30 days") to decide between
process_refundorescalate_to_humanThis is dynamic, context-sensitive decision making — not rule lookup, not pre-planned sequencing, not automatic routing
The agentic loop is essentially: act → observe result → reason → act again, repeated until the task is complete. The model's reasoning at each step is what drives the next action.
Why the Other Answers Are Wrong
Option | Why It's Wrong |
|---|---|
A | Automatic routing based on a status field describes a traditional rule-based workflow engine, not an LLM agentic loop. The orchestration layer doesn't make tool selection decisions — the model does. |
C | LLM agents don't rigidly execute a pre-planned tool sequence. Plans can be formed, but the agent adapts based on what each tool actually returns. A fixed sequence can't handle the variability of real-world tool outputs. |
D | Pre-configured decision trees are again a traditional software pattern, not how LLM agents operate. Hardcoding "if age > 30 days → escalate" as a decision tree defeats the purpose of using an LLM agent, which can reason about nuance, exceptions, and context. |
The key exam principle here: the power of LLM-based agentic loops is in-context reasoning at each step. Tool results flow back into the conversation, and the model reasons over the full context to decide what comes next — making it far more flexible than any pre-specified routing logic or decision tree.
After investigating a billing dispute over 25+ turns, you’ve identified that duplicate charges occurred due to a payment gateway timeout triggering retry logic. The required refund ($847) exceeds your $500 authorization limit You need to call escalate_to_human, and the human agent won’t have access to your conversation transcript. What context should you pass to enable effective resolution?
A. A structured summary: customer ID, root cause, refund amount, and recommended action.
B. Your diagnosis and the refund amount only.
C. The customer’s original complaint verbatim plus the tool result excerpts showing duplicate transactions.
D. The complete conversation transcript with all tool results.
Correct Answer: A
A structured summary: customer ID, root cause, refund amount, and recommended action.
Why A is Correct
This question is really about effective handoff communication — what does a human agent actually need to resolve this efficiently?
The AI agent has done 25+ turns of investigative work; the human shouldn't have to re-do that work
A structured summary distills the essential facts: who (customer ID), why (payment gateway timeout → retry → duplicate charge), how much ($847), and what to do (approve refund above $500 limit)
This is immediately actionable — the human can verify and execute without re-investigating
It respects the human's time and cognitive load by presenting conclusions, not raw data
This mirrors the same principle seen throughout this exam set: pass forward what the next agent (or human) needs, curated and structured — not everything that was accumulated, not so little that they're left guessing.
Why the Other Answers Are Wrong
Option | Why It's Wrong |
|---|---|
B | Diagnosis and refund amount alone are insufficient — the human needs the customer ID to actually locate the account and act, and a recommended action to know what's being requested of them. This is too sparse to be actionable. |
C | Verbatim complaint text and raw tool result excerpts are unprocessed inputs, not conclusions. The human would have to do the same investigative reasoning the AI already completed — defeating the purpose of the escalation handoff entirely. |
D | The complete 25+ turn transcript with all tool results is information overload. The human agent doesn't need to read the full investigation — they need the outcome. This is the same anti-pattern as passing all 120K tokens in Q2. |
The key exam principle here: when handing off to a human (or another agent), synthesize don't dump. The value the AI agent created over 25 turns is the conclusion it reached — a structured, actionable summary — not the raw transcript of how it got there. Effective escalation respects the recipient's time and gets them to resolution faster.
Your agent is handling a billing dispute. After calling get_customer and lookup_order, it identifies that the dispute involves a promotional pricing error requiring manager approval – beyond the agent’s authorization level. How should the workflow handle this mid-process escalation?
A. Compile a structured handoff with customer details, order info, and the identified issue before calling escalate_to_human.
B. Persist the complete conversation and tool response history to a database, then call escalate_to_human with a reference ID.
C. Call escalate_to_human passing only the customer’s original message.
D. Attempt the refund with process_refund anyway, escalating only if the system rejects the transaction.
Correct Answer: A
Compile a structured handoff with customer details, order info, and the identified issue before calling escalate_to_human.
Why A is Correct
This is Q14's principle applied to a mid-process scenario — and the answer is the same because the underlying need is identical:
The agent has already done the investigative work (called
get_customerandlookup_order, identified the root cause)Before escalating, it should package that work into a structured handoff: who the customer is, what order is involved, and what the specific issue is (promotional pricing error requiring manager approval)
The human manager receives everything they need to act immediately — no re-investigation required
Escalating mid-process with good context is strictly better than escalating with none
The key nuance here vs. Q14: this is an authorization escalation (the agent can't act), not just a complexity escalation. But the handoff principle is identical.
Why the Other Answers Are Wrong
Option | Why It's Wrong |
|---|---|
B | Persisting the full conversation to a database and passing a reference ID makes the human manager go retrieve and read through raw logs — adding friction and re-investigation burden. A structured summary passed directly is simpler and more effective. It also echoes the "don't dump the transcript" lesson from Q14. |
C | Passing only the customer's original message discards everything the agent learned from |
D | Attempting an unauthorized action and hoping the system rejects it is never the right approach. The agent already knows it lacks authorization — proceeding anyway risks unintended side effects, audit failures, or system errors. Escalate proactively, not reactively. |
The key exam principle here: when escalation is necessary — whether due to authorization limits or complexity — do the handoff work first. Compile what you know into a structured, actionable summary before calling escalate_to_human. The human's job is to approve and execute, not to re-investigate what the agent already figured out.
You’re implementing the escalation logic for when the agent should call escalate_to_human. Your team proposes four different approaches for triggering escalation. Which approach will most reliably identify cases that genuinely require human intervention?
A. Implement sentiment analysis that monitors for frustration indicators (negative language, repeated questions, exclamation marks) and trigger escalation when the frustration score exceeds a configured threshold.
B. Configure the agent to escalate after three consecutive tool calls that fail to resolve the customer’s stated issue, ensuring a reasonable attempt before involving a human.
C. Instruct the agent to escalate when the customer requests a human, when the issue requires policy exceptions, or when the agent cannot make meaningful progress.
D. Build a rules engine that maps specific issue types, customer segments, and product categories to escalation decisions, removing the need for model judgment calls.
Correct Answer: C
Instruct the agent to escalate when the customer requests a human, when the issue requires policy exceptions, or when the agent cannot make meaningful progress.
Why C is Correct
This approach correctly identifies the three genuine triggers for human escalation and lets the model reason about whether they apply:
Customer requests a human — non-negotiable; customer autonomy must always be respected
Policy exceptions required — the agent lacks authorization to act (as in Q15); a human with appropriate authority is needed
Cannot make meaningful progress — the agent recognizes it's stuck, looping, or lacks the capability to resolve the issue
Crucially, these are semantic, context-sensitive conditions that require reasoning to evaluate — exactly what LLM agents are good at. The instructions give the model clear escalation criteria without reducing the decision to a brittle rule or a proxy metric.
Why the Other Answers Are Wrong
Option | Why It's Wrong |
|---|---|
A | Sentiment analysis is a proxy metric, not a direct measure of whether human intervention is needed. A customer can be frustrated and still have an issue the agent can resolve; conversely, a calm customer may have a complex authorization issue requiring escalation. Frustration score is an unreliable trigger. |
B | Three consecutive failed tool calls is an arbitrary mechanical threshold. Some issues genuinely need more attempts; others need escalation immediately regardless of tool call count. This rule will both over-escalate (giving up too soon on solvable issues) and under-escalate (waiting through failures when escalation was always needed). |
D | A rules engine mapping issue types and customer segments to escalation decisions removes model judgment entirely — which is precisely what you need for edge cases, novel situations, and nuanced context. Hard-coded rules can't anticipate every scenario and will fail on anything not explicitly mapped. |
The key exam principle here: escalation logic should be built around meaningful semantic conditions (authorization, customer preference, genuine inability to progress) evaluated through model reasoning — not proxy metrics, mechanical counters, or rigid rule tables. The model's judgment is an asset; good escalation instructions direct that judgment rather than replace it.
Your order management system requires tools for three distinct operations: issuing refunds (requires amount and reason), canceling orders (requires reason), and requesting reshipments (requires shipping address). Each operation shares an order_id parameter but has different additional requirements. You notice during testing that with your current unified tool design, the agent frequently omits required parameters or includes irrelevant ones. What design change will most effectively improve parameter accuracy?
A. Keep one unified tool with a nested operation_details object parameter whose internal structure varies by operation type, documented in the tool description.
B. Keep one unified tool but add JSON Schema if-then-else conditionals to enforce that parameters like amount are required only when the operation type is “refund”.
C. Split into three separate tools (issue_refund, cancel_order, request_reshipment), each defining only the parameters required for that specific operation.
D. Keep one unified tool with all parameters marked optional, but add detailed few-shot examples in the system prompt showing correct parameter combinations for each operation type.
Correct Answer: C
Split into three separate tools, each defining only the parameters required for that specific operation.
Why C is Correct
The root cause of the problem is clear: the agent is confused about which parameters apply to which operation because they're all bundled together. The fix is to eliminate that ambiguity structurally:
Each tool has an unambiguous, minimal parameter set —
issue_refundrequiresorder_id,amount, andreason; nothing else is present to accidentally include or omitThe model doesn't need to reason about conditional parameter requirements — the tool schema itself enforces the correct structure
Tool selection becomes the decision point, and LLMs are much better at choosing the right tool from a clear set than correctly populating a complex conditional parameter structure
This follows the single responsibility principle: one tool, one operation, one clear contract
This is the tool design equivalent of the least-privilege principle from Q4 — give the agent exactly what it needs for each task, nothing more.
Why the Other Answers Are Wrong
Option | Why It's Wrong |
|---|---|
A | A nested |
B | JSON Schema |
D | Marking all parameters optional and relying on few-shot examples in the system prompt is the most fragile approach. It provides no structural enforcement — the schema still allows any combination, and the agent can still omit required fields or include irrelevant ones despite the examples. |
The key exam principle here: tool design should make correct usage easy and incorrect usage hard. When different operations have different parameter requirements, separate tools with minimal, explicit schemas will always outperform a unified tool with complex conditional logic — because the structure itself guides the model rather than relying on it to navigate ambiguity.
Your post_content tool requires user confirmation before publishing. The current workflow displays “Ready to post to social media. Confirm?” and analytics show users approve 98% of requests within 2 seconds. Post-mortems reveal incidents where posts went to wrong accounts, were scheduled for wrong times, or contained errors – all confirmed by users without catching the mistakes. How should you redesign the confirmation workflow?
A. Auto-approve routine posts and only require explicit confirmation for unusual patterns like posting to new accounts or large audiences
B. Require users to type a confirmation phrase instead of clicking a button
C. Add a mandatory waiting period before the confirm option becomes available
D. Include the complete post text, target account, scheduled time, and platform in the confirmation request
Correct Answer: D
Include the complete post text, target account, scheduled time, and platform in the confirmation request.
Why D is Correct
The 98% approval rate in 2 seconds isn't a sign the workflow is working — it's a sign users are rubber-stamping confirmations because the prompt gives them nothing meaningful to verify. The incidents (wrong account, wrong time, content errors) all share the same root cause: the confirmation request didn't show the information needed to catch those mistakes.
The fix is to make the confirmation display everything consequential:
The full post text (so content errors are visible)
The target account (so wrong-account errors are catchable)
The scheduled time (so wrong-time errors are catchable)
The platform (so cross-platform mistakes are visible)
A confirmation is only meaningful if the user has enough information to actually confirm or reject. Without it, you have the illusion of human oversight without the substance.
Why the Other Answers Are Wrong
Option | Why It's Wrong |
|---|---|
A | Auto-approving "routine" posts removes human oversight precisely for the cases most likely to contain unnoticed errors — routine posts are exactly what users were rubber-stamping. Reducing confirmation requirements makes the problem worse, not better. |
B | Typing a confirmation phrase adds friction but doesn't add information. A user can type "CONFIRM" just as mindlessly as clicking a button if they still can't see what they're confirming. Friction ≠ meaningful verification. |
C | A mandatory waiting period similarly adds friction without adding information. Waiting 10 seconds before approving a confirmation that still says "Ready to post?" doesn't help users catch wrong accounts or scheduled times. |
The key exam principle here: human-in-the-loop confirmation is only valuable when users have sufficient information to exercise genuine judgment. A confirmation dialog that omits the details needed to catch errors provides false assurance — the appearance of oversight without the reality. Effective confirmation workflows surface exactly the information that could reveal a mistake.
Your agent uses three tools: get_property_details(property_id) returns data including street address, get_price_history(property_id) returns historical pricing, and get_neighborhood_info(address) returns area statistics. You observe that get_neighborhood_info always requires get_property_details first just to extract the address, even when users specify the property by ID. This creates unnecessary latency and failure coupling – if the first call fails, the neighborhood request also fails. What tool design change best addresses this?
A. Create a lookup_address(property_id) helper tool for retrieving addresses.
B. Add retry logic and timeout handling to get_property_details.
C. Change get_neighborhood_info to accept property_id, resolving the address internally.
D. Consolidate into a single get_property_with_neighborhood(property_id) tool returning both datasets.
Correct Answer: C
Change get_neighborhood_info to accept property_id, resolving the address internally.
Why C is Correct
The problem is a forced dependency chain: the agent must call get_property_details just to extract an address, then pass that address to get_neighborhood_info — even when it already has the property_id. This creates latency and failure coupling unnecessarily.
The fix is elegant: let get_neighborhood_info accept property_id directly and resolve the address internally, behind the scenes:
The agent can now call
get_neighborhood_info(property_id)directly, skipping the intermediate step entirelyThe address lookup becomes an implementation detail of the tool, not a burden on the agent
Latency drops and the failure coupling is eliminated — a single tool call now does what two previously required
The tool's interface matches how agents actually use it: they have a
property_id, they want neighborhood info
This is good API design: tools should accept the identifiers callers naturally have, not require them to pre-fetch intermediate values.
Why the Other Answers Are Wrong
Option | Why It's Wrong |
|---|---|
A | A |
B | Retry logic and timeout handling address resilience, not the architectural dependency problem. The agent still has to make two calls; they just fail more gracefully. This is a patch on a structural issue. |
D | Consolidating into a single |
The key exam principle here: tool interfaces should match the natural inputs callers have, not force them to acquire intermediate values first. When a dependency chain exists only because of an impedance mismatch between tool input and caller context, the right fix is to update the tool's interface — not add helper tools or patch the failure modes of the existing chain.
Your update_user_profile tool accepts a user_id (required) and an optional fields_to_update object. In testing, Claude frequently omits user_id or passes incorrectly structured data. What is most critical for helping Claude understand what parameter values to provide?
A. Strict JSON Schema type constraints marking user_id as required and defining fields_to_update as an object type
B. Verbose parameter names encoding format hints, such as user_id_string_uuid_format
C. Detailed error responses explaining why invalid parameter values were rejected
D. Clear parameter descriptions explaining expected format, such as “user_id: UUID of the user to update (required)”
Correct Answer: D
Clear parameter descriptions explaining expected format, such as "user_id: UUID of the user to update (required)"
Why D is Correct
The testing failures reveal a comprehension problem: Claude doesn't have enough context about what values to provide. The most direct fix is clear, human-readable descriptions that explain:
What the parameter is (the UUID of the user to update)
What format it expects (UUID)
Whether it's required (explicitly stated)
LLMs populate tool parameters primarily by reasoning from descriptions — a well-written description is the single highest-leverage improvement for parameter accuracy. It's the equivalent of good documentation: it tells the model exactly what to pass and why.
Why the Other Answers Are Wrong
Option | Why It's Wrong |
|---|---|
A | JSON Schema constraints ( |
B | Encoding format hints in parameter names ( |
C | Error responses after invalid calls help with iterative correction, but they're reactive — the model already made the wrong call. Good descriptions prevent the error in the first place. Relying on error feedback as the primary teaching mechanism adds unnecessary round-trips and latency. |
The key exam principle here: tool parameter descriptions are the primary communication channel between tool designers and the model. Clear, explicit descriptions of what each parameter means, what format it expects, and whether it's required will outperform structural constraints, naming conventions, or error-based feedback as a first line of defense against parameter errors.
Your control_device tool manages smart home devices through external APIs. When a device doesn’t respond within the timeout period, the tool returns an error. Production logs show that the agent simply tells users “the device is not responding” without offering helpful next steps. Which error response structure would best enable the agent to provide useful follow-up?
A. Set is_error: true with a structured technical error containing the device ID, timeout duration, and raw API response code for debugging purposes.
B. Set is_error: true with a brief “Device offline” message and provide a separate tool the agent can call to retrieve context-specific troubleshooting suggestions.
C. Set is_error: false with an optimistic message indicating the command was dispatched successfully but device acknowledgment is still pending.
D. Set is_error: true with a message explaining the likely cause and suggesting troubleshooting steps the agent can offer the user.
Correct Answer: D
Set is_error: true with a message explaining the likely cause and suggesting troubleshooting steps the agent can offer the user.
Why D is Correct
The agent's current failure ("the device is not responding") is a direct consequence of the error response giving it nothing actionable to work with. The fix is to make the error response itself informative and actionable:
is_error: truecorrectly signals that something went wrong — the agent shouldn't treat this as a successThe message explains the likely cause (timeout = device probably offline or unreachable) so the agent understands the situation
Suggested troubleshooting steps give the agent concrete things to relay to the user: check if the device is powered on, check network connectivity, try again in a few moments, etc.
The agent can only be as helpful as the information it receives. A rich, context-aware error message transforms the agent's response from a dead end into a productive next step.
Why the Other Answers Are Wrong
Option | Why It's Wrong |
|---|---|
A | Raw technical details (device ID, timeout duration, API response code) are useful for developers debugging logs — not for an agent trying to help a user. The agent can't translate |
B | Requiring a separate tool call to retrieve troubleshooting suggestions adds an unnecessary round-trip. The error response already has the context needed to provide relevant suggestions inline — splitting this into two steps adds latency and complexity for no benefit. |
C | Returning |
The key exam principle here: error responses should be as informative as success responses. When a tool fails, the error message is the agent's only source of context about what went wrong and what to do next. Errors that explain likely causes and suggest remediation steps transform agent failures into helpful interactions — errors that return only technical codes or terse messages leave the agent with nothing useful to offer.
After 30+ turns, your conversational assistant shows noticeably slower responses and occasionally produces less coherent outputs. Investigation reveals: (1) average conversations reach 50,000 tokens by turn 35, (2) production logs show 94% of user messages only reference the previous 3-5 exchanges, (3) the 6% of queries referencing earlier context typically ask about information the user could easily re-state. Your goal is to improve response speed and quality while maintaining good user experience. What’s the most effective approach?
A. Enable prompt caching and continue sending the complete conversation history, using cached prefixes to reduce per-request costs while preserving all context.
B. Build a retrieval system that stores all conversation turns and uses semantic search to pull in relevant historical context only when the current query appears to reference past information.
C. Implement a summarization layer that progressively compresses older conversation turns into a running summary while keeping the most recent 5-6 turns verbatim, maintaining full historical context in condensed form.
D. Implement a sliding window keeping only the system prompt and last 8-10 turns. When users reference earlier context, acknowledge the limitation and ask them to re-state the relevant information.
Correct Answer: C
Implement a summarization layer that progressively compresses older conversation turns into a running summary while keeping the most recent 5-6 turns verbatim.
Why C is Correct
The data in the question points directly to this solution:
94% of queries only need the last 3-5 exchanges → keep recent turns verbatim
6% of queries reference earlier context → a running summary preserves that information in condensed form rather than discarding it
The root cause of slower responses and degraded quality is context window bloat → progressive compression directly addresses this
C is the only option that simultaneously solves the performance problem and preserves historical context with no information loss — just compression. The model gets a compact summary of everything that happened before, plus full fidelity on recent turns where it matters most.
Why the Other Answers Are Wrong
Option | Why It's Wrong |
|---|---|
A | Prompt caching reduces cost but not context length. The 50,000-token context is still processed in full each turn — response latency and coherence degradation from long contexts are not addressed. This solves the wrong problem. |
B | Semantic retrieval is a valid pattern for some use cases, but it adds latency on every turn (retrieval step), risks missing relevant context if queries don't semantically match earlier turns, and is significantly more infrastructure complexity than needed given the data shows 94% of queries only need recent turns. |
D | A sliding window is simple but permanently discards older context. The question explicitly notes 6% of queries reference earlier information — acknowledging the limitation and asking users to re-state information degrades user experience unnecessarily when summarization can preserve that context cheaply. |
The key exam principle here: context management should be data-driven. The usage data here (94% recent, 6% historical) directly prescribes the solution: prioritize recent turns with full fidelity, compress older turns rather than discard them. Match your context strategy to your actual usage patterns.