Anthropic CCAR-F Claude Certified Architect – Foundations Exam Practice Test

Option B follows the Claude Agent SDK’s subagent context model. A normal subagent begins with a fresh context window and does not inherit the parent agent’s conversation history or prior tool results. Anthropic’s Subagents in the SDK documentation states that the information passed from parent to subagent is the spawning tool’s prompt string; required file paths, decisions, errors, or findings must therefore be included in that prompt. In this scenario, the coordinator should supply both agents’ relevant findings, source metadata, and explicit synthesis instructions. “Complete findings” means the full required result artifacts, not every intermediate search trace. Option C incorrectly assumes automatic context inheritance. Option A introduces callbacks that are neither necessary nor the standard handoff mechanism. Option D can be a valid custom architecture when a shared store has deliberately been implemented, but the question does not establish such infrastructure, and identifiers alone do not give the subagent information. The prompt should use clear sections or structured objects to distinguish web findings, document findings, sources, unresolved conflicts, and expected output. This preserves context isolation while providing everything the synthesis task actually requires.

================

The defects are coupled, so changing all three simultaneously would make it difficult to determine which modification caused an improvement or regression. Option C establishes a controlled sequence: correct the foundational column geometry, verify the resulting layout, format dates within the stabilized columns, and finally tune page breaks using the resulting content heights.

Anthropic recommends tight feedback loops and early course correction. It also advises supplying Claude with an executable or observable verification mechanism, such as a test, build result, generated fixture, or screenshot comparison. Claude can then make a focused change, inspect the output, and iterate until that specific condition is satisfied. ( https://code.claude.com/docs/en/best-practices )

Option A discards useful context from the functioning database implementation. Option B changes multiple interacting variables in one pass, making failures harder to isolate. Option D provides a useful visual target but does not replace precise technical constraints or incremental verification.

Each stage should have explicit acceptance criteria—for example, minimum column widths, expected date strings, and page-break fixtures using short and long content. Once a stage passes, its test becomes a regression guard for subsequent changes.

Official references/topics: Incremental Refinement; Tight Feedback Loops; Observable Verification; Regression Control.

Retry-with-error-feedback is effective when the required information is available and the defect concerns representation. Options A, C, and D are correctable formatting failures: the model can flatten an object into an array, remove thousands separators and emit an integer, or convert a datetime into the required date-only format. The validation message supplies enough information to revise the output.

Option B is fundamentally different. The complete co-author list is absent from the model’s input and exists only in an external document. No number of retries can recover evidence that was never supplied. Repeated attempts may instead increase the probability of fabrication. Anthropic’s hallucination guidance recommends restricting responses to available documents, allowing the model to acknowledge missing information, and withholding or retracting claims that cannot be grounded in the source. ( https://docs.anthropic.com/en/docs/test-and-evaluate/strengthen-guardrails/reduce-hallucinations )

The correct response is therefore to return an explicit missing-data state, retrieve the external document through a tool, or route the record for enrichment. Retrying without changing the information boundary cannot solve the problem.

Current Anthropic Structured Outputs can eliminate many shape-related failures by guaranteeing JSON Schema conformance, but they still cannot create unavailable source facts. ( https://platform.claude.com/docs/en/build-with-claude/structured-outputs ) This distinction—format failure versus evidence failure—is central to reliable extraction architecture.

Official references/topics: Retry Boundaries; Missing Context; Grounded Extraction; Structured Outputs; External Data Retrieval.

The root cause is an incomplete tool contract. Claude sees that process_refund requires an order_id , but the tool description does not explain the parameter’s trusted source or the prerequisite lookup sequence. Option A makes the dependency explicit and prohibits fabricated values.

Anthropic states that tool descriptions should explain what a tool does, when it should be used, how it behaves, and any important limitations. Its prompting guidance also states that dependent tool calls must be executed sequentially and that Claude must never use placeholders or guess missing tool parameters. ( https://platform.claude.com/docs/en/agents-and-tools/tool-use/define-tools )

Option B merely forces some tool use; it does not force the correct tool or prevent a fabricated identifier. Option C is an essential defense-in-depth control, but it detects the invalid ID after the model has already made the faulty call. It does not correct the selection logic that caused the fabrication. Option D works only when the customer actually provides an identifier and introduces an unnecessary preprocessing dependency.

The process_refund schema should describe order_id as a verified identifier returned by lookup_order , and the tool description should state that the tool is unavailable until the corresponding order has been retrieved and eligibility established.

Official references/topics: Tool descriptions, prerequisite tool calls, parameter provenance, sequential tool orchestration.

Option B eliminates an unnecessary agent boundary. The coordinator already possesses the accumulated findings and can answer a straightforward follow-up without serializing more than 80,000 tokens into a fresh subagent context, waiting for another model execution, and receiving the result back. Anthropic’s multi-agent research engineering guidance emphasizes scaling effort to task complexity: simple fact-finding or lightweight processing should use substantially fewer agents and tool calls than complex research. It also reports that multi-agent systems consume far more tokens than ordinary interactions, making avoidable delegation expensive and slow. Option A adds an interactive retrieval protocol between agents and additional round trips. Option C spends compute proactively on summaries that users may never request and creates cache-invalidation problems whenever findings change. Option D could reduce repeated input cost where caching is applicable, but the subagent still receives and processes an unnecessarily large context and still incurs spawning latency. Delegation is valuable when an isolated context or specialized capability materially improves the result. For a direct summary already supported by the coordinator’s active context, local handling is the faster and simpler architecture.

================

Path-scoped rules directly satisfy the requirement that instructions load only when Claude works with matching files. Each infrastructure domain can have a separate Markdown file under .claude/rules/ , with YAML paths frontmatter targeting Terraform files, Kubernetes manifests, or pipeline configuration.

Anthropic documents that .claude/rules/ keeps project guidance modular and supports conditional loading based on glob patterns. Rules with a paths field apply only when Claude works with matching files, reducing irrelevant context and token consumption. Rules without path frontmatter load unconditionally. ( https://code.claude.com/docs/en/memory )

Option B improves readability but leaves all 500-plus lines in every session. Option C can provide directory-specific CLAUDE.md guidance, but path-scoped rules are more precise when conventions depend on extensions or patterns spanning multiple directories. Option D still requires manual imports and does not provide the documented conditional rule-loading mechanism.

A suitable design would use rules such as terraform.md scoped to terraform/**/*.tf , kubernetes.md scoped to kubernetes/**/*.{yaml,yml} , and pipelines.md scoped to the pipeline directory. Broad project-wide commands and repository etiquette can remain in the root CLAUDE.md.

Official references/topics: .claude/rules/ ; Path-Specific Rules; YAML Frontmatter; Context-Efficient Instruction Loading.

Option C allows orchestration effort to scale according to the actual evidence and processing requirements of each request. A factual lookup might require one search operation and a direct coordinator response, while comparative research may justify parallel search, document analysis, synthesis, and formal report generation.

Anthropic’s orchestrator-workers guidance describes a central model dynamically decomposing a task, choosing workers, and combining their results. This pattern is particularly appropriate when required subtasks cannot be predicted reliably in advance. Anthropic’s multi-agent research architecture similarly uses a lead agent to analyze the query and determine an appropriate research strategy.

Option A creates an inflexible two-route system and still sends every non-factual query through the most expensive workflow. Option B requires labeled training data, an externally maintained classifier, and a stable definition of the optimal agent combination. Option D is less expensive to implement but becomes brittle as query types evolve beyond predetermined categories. Dynamic coordination uses the model’s existing reasoning ability to assess source requirements, analytical depth, expected output, and uncertainty before invoking only the specialists that materially improve the result.

================

This migration is a high-impact, cross-module change with several independent breaking changes. Before editing, Claude must determine how the callback-based API is currently used, where the restructured User fields propagate, whether deprecated methods are wrapped or re-exported, and which downstream modules depend on the affected behavior. Plan mode is therefore the correct starting point because it allows Claude to inspect the repository, identify affected code paths, and produce an implementation strategy without modifying source files.

Anthropic recommends separating exploration and planning from implementation when the approach is uncertain, the change affects multiple files, or the developer is unfamiliar with the impacted code. Direct execution is better reserved for small, clearly scoped changes that can be described as a simple diff. ( https://code.claude.com/docs/en/best-practices )

Option A applies transformations before establishing whether every usage follows the same pattern. Option B turns the test suite into a reactive discovery mechanism and may miss untested behavior. Option D provides useful migration documentation but assumes all 45 files can be changed uniformly. The reliable sequence is exploration, impact mapping, migration planning, implementation, and verification against tests and type checks.

Official references/topics: Plan Mode; Explore–Plan–Implement Workflow; Multi-File Migration Planning; Verification.

Option C gives the reviewer access to the evidence currently missing from its prompt. An agentic review can use Grep, Glob, Read, language-server tools, and test commands to locate callers, follow imports, inspect type definitions, and verify whether a suspected compatibility issue actually exists. A turn limit controls cost while still allowing targeted exploration.

Anthropic’s context-engineering guidance recommends just-in-time retrieval: agents should retain lightweight references and dynamically load the information needed for the current task instead of preloading a large fixed context. Anthropic has also reported that code-review performance improves when the necessary repositories are available for gathering complete context. Option A may load many irrelevant files while still missing reflection, generated interfaces, dependency injection, or indirect call paths beyond the arbitrary two-hop boundary. Option B cannot reason reliably about code that the model cannot inspect. Option D improves coverage but fragments repository-wide relationships and may duplicate substantial work. An agentic loop can begin with the diff, identify uncertain cross-file effects, search only relevant paths, and report findings only after locating supporting code. Anthropic context-engineering guidance , Claude Code quality report

================

The failure is caused by missing evidence, not insufficient reasoning over the supplied evidence. A static prompt containing only changed files cannot reliably identify callers, configuration dependencies, generated interfaces, or indirect relationships located elsewhere in the repository. Asking Claude to reason more deeply cannot recover code that it was never given.

Option A converts the review into a bounded agentic loop. Claude can search for symbol references, read relevant callers, inspect type definitions, and follow newly discovered dependencies before validating a potential defect. Anthropic describes the Claude Code agentic loop as gathering context, taking action, verifying results, and repeating based on tool feedback. A turn limit preserves predictable cost and execution time.

Option C improves coverage but imposes an arbitrary two-hop boundary and depends on the accuracy of a precomputed graph, which may omit dynamic imports, reflection, generated code, configuration references, or language-specific call relationships. Option D creates duplicated context and aggregation complexity while still limiting each reviewer to predetermined dependents. Option B changes the reasoning instructions but supplies no mechanism for checking unchanged files. Tool-enabled, just-in-time retrieval is therefore the most adaptable and reliable architecture for cross-file review.

================

Option A identifies the direct configuration contradiction. Each system prompt defines a specialized responsibility, but the corresponding tool allowlist presents unrelated actions as available capabilities. The synthesis agent may therefore interpret web searching as an acceptable way to fill evidence gaps, while the report generator may perform document analysis instead of limiting itself to report production.

Anthropic’s subagent documentation defines subagents as focused workers with their own prompts and specific tool access. Its tool-definition guidance also recommends reducing selection ambiguity by presenting clear, relevant tools. The appropriate correction is least-capability configuration: expose search tools to the search agent, document tools to the analyzer, synthesis utilities to the synthesizer, and formatting or output tools to the report generator.

Option B may affect token efficiency but does not explain the role-specific misuse pattern. Option C concerns delegation, whereas the improper calls occur after successful delegation. Option D is tempting, but Anthropic does not define four or five tools as a universal reliability threshold; 18 tools alone does not prove threshold failure. The decisive defect is misalignment between declared roles and permitted capabilities.

================

Option D directly addresses cache entries expiring before later batch requests are processed. Anthropic’s batch-processing documentation specifically notes that Message Batches can take longer than five minutes and recommends the one-hour prompt-cache duration for batches containing shared context. The prompt-caching documentation confirms that the default TTL is five minutes and that " ttl " : " 1h " creates an extended entry.

Option A may improve cache locality, but it introduces the sequential-processing latency explicitly prohibited by the requirement. Option B seeds the cache initially, but the prewarmed entry still expires after five minutes unless the TTL is extended; it therefore does not solve misses among requests scheduled later. Option C places the breakpoint on request-specific content, defeating reuse of the stable 8,000-token prefix and attempting to cache scripts that are not byte-for-byte identical.

The system should retain the breakpoint at the end of the shared system content and apply the one-hour TTL there. Cache-usage fields should then be monitored to confirm that cache_read_input_tokens rises and later batch requests reuse the intended prefix.

================

Option A defines what successful research must achieve without hard-coding a brittle search procedure. The subagent receives measurable objectives—breadth, diversity, recency, and relevance—but retains authority to reformulate queries, follow promising leads, and adjust source selection when the topic does not match familiar patterns. Anthropic’s account of its multi-agent research system states that subagents need an objective, expected output format, guidance about tools and sources, and clear task boundaries. This is more informative than option B’s vague instruction, yet more adaptive than prescribing every query. Option C improves only one known failure path and still constrains the agent to a predefined procedure that may be unsuitable for emerging subjects. Option D adds orchestration complexity and a potentially incorrect classification step without solving over-prescription within either category. The coordinator should describe mandatory constraints separately from strategic guidance: authoritative-source requirements and time boundaries can remain fixed, while query formulation and exploration paths remain agent-controlled. Evaluation should then measure source coverage, evidence quality, duplication, and discovery of relevant secondary leads rather than whether the subagent followed a particular series of searches.

================

The failure is caused by an underspecified extraction policy rather than an inadequate JSON structure. “Extract all skills mentioned” does not define whether coordinated phrases should be split, whether inferred capabilities qualify, or what level of specificity constitutes one skill. Few-shot examples can demonstrate all three decisions using concrete inputs and expected outputs.

Anthropic identifies examples as one of the most effective ways to improve output accuracy and consistency because they communicate behavior more precisely than abstract instructions alone. Representative examples can show that “Python and SQL” becomes two entries, that an unstated skill must not be inferred from a job title, and that broad descriptions should not be decomposed into dozens of speculative micro-skills. ( https://docs.anthropic.com/en/docs/about-claude/use-case-guides/ticket-routing )

Option A adds provenance and confidence metadata but does not define the correct extraction granularity. Option C addresses explicitness and splitting, but the arbitrary 10–20 limit can truncate documents containing more than 20 legitimate skills or force padding when fewer than 10 appear. Option D is useful for canonicalization and deduplication, but post-processing cannot reliably remove plausible implied skills or determine how the original phrase should have been interpreted.

The strongest prompt should combine explicit rules with diverse few-shot examples covering normal cases, compound phrases, implied information, duplicates, and unusually long or short skill lists.

Official references/topics: Few-Shot Prompting, Output Consistency, Explicit Extraction Criteria, Representative Examples.

Option A uses the limited review capacity as a risk-ranking mechanism rather than spending it uniformly. JSON Schema validation can prove that an output has the expected types and structure, but it cannot detect a semantically misplaced value such as a duration stored as an ingredient quantity. Field-level confidence can identify the exact parts of a record that warrant inspection, provided those scores are calibrated against labeled examples rather than trusted at face value. The labeled validation set must mirror the production distribution and include edge cases; Anthropic’s evaluation guidance explicitly recommends task-specific evaluations, representative distributions, measurable criteria, and automated grading where possible. Calibration then converts raw confidence into an empirically tested estimate of error risk, allowing reviewers to inspect the lowest-confidence records or fields first. Option C, random sampling, is useful for unbiased quality measurement and discovering new failure modes, but it does not maximize error detection within a fixed 20 percent review budget. Options B and D target narrow proxies—layout anomalies and missing required values—while the observed errors pass structural validation and may occur in ordinary-looking documents. The operational design should combine calibrated risk-based review with a smaller random audit sample to detect drift and overconfidence.

================

The primary risk is not implementation difficulty but incomplete requirements. Production caching introduces decisions involving invalidation, stale-data tolerance, cache keys, tenant boundaries, serialization, stampede prevention, failure behavior, observability, deployment topology, and consistency expectations. Implementing Redis with a five-minute TTL before resolving these questions can produce a technically functional but operationally unsafe design.

Anthropic recommends having Claude interview the user before beginning a larger feature when important requirements remain uncertain. The AskUserQuestion workflow is intended to surface technical implementation concerns, edge cases, trade-offs, and assumptions the user may not have considered. Anthropic further recommends converting the resulting answers into a self-contained specification with explicit scope and an end-to-end verification step. ( https://code.claude.com/docs/en/best-practices )

Option B provides useful codebase context but postpones requirement discovery. Option C creates avoidable rework by allowing architecture to emerge from production failures. Option D documents uncertainty but delegates unresolved design choices during implementation, when they may already constrain the code.

After the interview produces a caching specification, Claude can enter plan mode to inspect the endpoint and map those requirements onto the existing architecture before implementation.

Official references/topics: Requirements Interviewing; AskUserQuestion; Specification Development; Edge-Case and Trade-Off Discovery.

Option B preserves provenance as structured data throughout every handoff. Each finding should include the summarized claim and an associated source record containing its URL or document identifier, page or section location, relevant excerpt, and possibly retrieval date and confidence. The synthesis agent can combine claims without destroying this relationship, and the report generator can produce citations deterministically.

Anthropic’s multi-agent research system retains findings until a dedicated citation stage identifies the precise source locations supporting report claims. This demonstrates that citation provenance must remain available beyond initial retrieval and summarization.

Option A attempts to reconstruct provenance after it has been discarded, which is expensive and may associate a claim with a different or weaker source. Option C preserves evidence but wastes context by transferring approximately all raw search and document content. Option D is better than losing references entirely, but embedding citations only in prose makes programmatic validation, deduplication, and claim-to-source mapping less reliable. Structured content and source fields maintain both context efficiency and auditable attribution while allowing different agents to transform the narrative safely.

================

Forking the existing analysis session creates independent continuations that inherit the accumulated conversation context. Each branch begins with the same understanding of the service module, request flow, source files, and error-handling patterns, but subsequent work on one testing strategy does not alter the other branch or the original session.

Anthropic’s Agent SDK documentation states that sessions can be resumed with their full context and forked to explore different approaches. In the SDK, enabling fork_session while resuming causes the continuation to receive a new session identifier rather than modifying the original session. ( https://docs.anthropic.com/en/docs/claude-code/sdk?utm_source=chatgpt.com )

Option B wastes time, tokens, and tool calls by requiring both new sessions to rebuild the same 23-file analysis. Option C mixes two experimental implementations into one conversation, increasing the risk that assumptions, edits, or conclusions from the first strategy influence the second. Option D preserves only a manually selected summary, which may omit details contained in the full session history.

The appropriate design is to create one fork for the end-to-end strategy and another fork for the snapshot strategy. The original analysis remains a stable parent, while each child session develops and evaluates its approach independently.

Official references/topics: Agent SDK Sessions, Session Forking, Context Preservation, Alternative-Approach Evaluation.

Option B identifies escalation through direct operational criteria rather than indirect proxies. A customer’s explicit request for a person is unambiguous. A required policy exception defines an authorization boundary. An inability to make meaningful progress identifies a case where continued autonomous execution is no longer productive.

Anthropic describes agents as systems that act, observe results, adjust, and continue until the task is completed or human input is required. Its trustworthy-agent guidance also emphasizes that agents must recognize when to pause rather than pushing through uncertainty or decisions that only a human can settle. ( https://www.anthropic.com/research/trustworthy-agents )

Option A is too rigid for high-ambiguity support cases. Maintaining exhaustive mappings for every issue, product, and customer segment recreates the brittleness that agentic reasoning is intended to avoid. Option C treats repeated tool use as a substitute for semantic progress; one definitive authorization failure may require immediate escalation, while several legitimate diagnostic calls may not. Option D confuses emotional tone with operational necessity. A calm customer may require a policy exception, while a frustrated customer may still have a straightforward automated resolution.

The escalation criteria should be encoded in the system instructions and supported by evaluations covering explicit requests, authorization limits, unresolved ambiguity, repeated non-progress, and successful self-service cases.

Official references/topics: Human-control checkpoints, escalation criteria, authorization boundaries, progress-aware agents.

The evaluation results demonstrate prompt interference: improving attention to business-logic examples reduces performance on API design. Option C isolates the competing objectives so each model call can apply focused terminology, examples, evidence requirements, and evaluation criteria. The resulting structured findings can then be merged, deduplicated, and ranked before being posted.

Anthropic’s Building Effective AI Agents describes parallelization through sectioning, where independent aspects of a task are handled by separate model calls and subsequently aggregated. This pattern is appropriate when one prompt must evaluate several distinct considerations and a single call does not handle all of them reliably.

Option A increases context volume without resolving competition between the review objectives; irrelevant repository content may further dilute attention. Option B may improve known quiz-scoring cases but can overfit the reviewer to an incomplete checklist and does not restore API-design recall. Option D assumes that additional model capability will eliminate prompt interference without supporting evaluation evidence. Separate specialized review passes directly address the measured failure. Each pass should be evaluated independently, followed by an end-to-end evaluation confirming that consolidation preserves recall and does not introduce duplicated findings.

================

Direct @ references provide Claude with the exact implementations it must imitate. Anthropic documents that referencing a file with @ includes the full file content in the conversation, and multiple files can be referenced in one message. This gives Claude immediate access to the real transaction boundaries, exception structures, audit fields, naming conventions, and helper APIs used by the project. ( https://code.claude.com/docs/en/common-workflows )

Option B is inappropriate because the task is explicitly one-off and the conventions are already documented elsewhere. CLAUDE.md is loaded into every session and should contain concise information that broadly applies to the project. Adding detailed implementation material for a single integration would consume context unnecessarily. Anthropic recommends moving occasional procedures to skills and keeping CLAUDE.md limited to persistent, widely applicable guidance. ( https://code.claude.com/docs/en/memory )

Option C loses precision because a natural-language summary may omit subtle but important code behavior. Option D asks Claude to rediscover files that have already been identified, increasing exploration time and context usage.

The most effective prompt should reference all three modules, identify which pattern each demonstrates, specify the new module’s required behavior, and request focused tests proving that the established conventions were followed.

Official references/topics: @ file references, rich prompt context, CLAUDE.md scope, pattern-based implementation.

The reference to generic rendering patterns indicates that the current context has become saturated or that important earlier details are no longer receiving sufficient attention. Anthropic documents that performance can degrade as a Claude Code context window fills with conversation history, file contents, and command output; symptoms include forgetting earlier instructions and making less precise responses. ( https://code.claude.com/docs/en/best-practices )

Option C preserves the high-value rendering discoveries while isolating the physics investigation. The summary should identify the relevant rendering classes, synchronization boundaries, debug-overlay interfaces, and unresolved integration questions. A physics-focused subagent can then inspect collision and simulation code in its own context without adding dozens of additional files to the already crowded main conversation.

This explicit summary matters because an ordinary named subagent starts with a fresh, isolated context and does not automatically receive the parent’s full conversation history or previously read files. Claude constructs a delegation message containing the task context, so the essential rendering findings must be supplied deliberately. ( https://docs.anthropic.com/en/docs/claude-code/sub-agents )

Option A omits the integration context needed to guide the physics search. Option B destroys useful prior analysis. Option D keeps expanding an already degraded context and treats the symptom rather than controlling context growth.

Official references/topics: Context-Window Management; Subagent Isolation; Delegation Summaries; Codebase Exploration.

Option D is the closest match to Claude Code’s documented editing procedure. The Claude Code tools reference explains that Edit performs exact string replacement and requires old_string to appear exactly once. When the text occurs multiple times, the prescribed response is to include sufficient surrounding context to identify one occurrence uniquely. For this insertion, the match should span a distinctive boundary between the preceding function and the following function. It does not literally need 30 lines; it needs the smallest exact block that is demonstrably unique, but option D is the only answer expressing that method.

Option A would modify every occurrence of a repeated pattern and could insert the helper function multiple times. Option B places the function at the end rather than at the required architectural location. Option C can technically work, but Write replaces the complete file and increases the change surface. Anthropic explicitly states that Write creates or overwrites full files, while partial modifications should use Edit. A targeted, uniquely anchored Edit preserves all unrelated content and produces a smaller, safer diff.

================

Option A is correct because the failure results from excessive output volume, not from JSON or tool use. Anthropic documents that max_tokens is a hard output ceiling and that a response stopped at this limit reports stop_reason: " max_tokens " . Its tool-streaming guidance also warns that generation can stop midway through a tool parameter, leaving partial JSON that must not be treated as complete. Splitting the pull request into bounded file groups limits the number of findings produced by each call, preserves the report_findings schema, and allows the pipeline to validate every response independently before merging and deduplicating the arrays. Shared dependency context can still be included when cross-file analysis is required.

Option B only postpones the failure because the model’s output maximum remains finite. Option C abandons the structured contract and makes deterministic parsing less reliable. Option D changes the review requirements by suppressing potentially valuable lower-severity findings, while the retried request could still reach the same limit. Controlled partitioning followed by deterministic aggregation is therefore the most reliable and scalable design. Anthropic stop-reason guidance and tool-streaming guidance .

The error response must explicitly communicate both control semantics and user-facing meaning. Setting " retriable " : false tells the agent that repeating the same operation cannot change the outcome. Providing a customer-friendly explanation allows Claude to respond accurately without exposing internal implementation details or inventing its own interpretation of the business rule.

Anthropic recommends returning failed tool operations with an error indicator and sufficiently informative content so Claude can decide whether to retry, request another input, or explain the limitation. Tool interfaces should provide detailed descriptions and structured parameters rather than forcing Claude to infer operational behavior from ambiguous text. ( https://platform.claude.com/docs/en/agents-and-tools/tool-use/build-a-tool-using-agent?utm_source=chatgpt.com )

Option A appropriately limits automatic retries to technical failures, but it does not solve the stated customer-response problem unless business failures also carry clear semantics. Option B relies on fragile parsing of human-readable messages. Option C adds latency and another tool dependency, and eligibility may still change or fail for reasons not covered by the preliminary check.

A complete schema should identify the error code, category, retryability, customer-safe explanation, and permitted next actions. Technical errors can similarly return " retriable " : true with retry guidance and a maximum-attempt policy.

Official references/topics: Structured tool errors, retryability classification, customer-safe explanations, resilient MCP contracts.

Option D improves the generation conditions instead of filtering defective output afterward. Anthropic recommends using CLAUDE.md for repository-wide standards and information that Claude should apply in every session. The file can define what constitutes a useful test, require assertions on observable behavior, identify approved fixture factories, prohibit duplication of existing scenarios, and provide contrasting examples of strong and trivial tests. These instructions are available before Claude decides what tests to create.

Option A may remove some weak tests, but it doubles model work and still permits the first stage to generate low-quality material. Option B treats line coverage as a quality measure even though a trivial assertion can execute new lines without validating behavior. Option C abandons difficult areas rather than improving generation. The standards should also direct Claude to inspect nearby tests and fixtures before writing new cases, identify the behavior or regression each test protects, and run the relevant suite afterward. Because CLAUDE.md consumes context in every session, the guidance should remain concise; lengthy testing procedures are better placed in a reusable skill referenced from the project instructions.

================

Option B removes the ambiguity from the tool interface itself. The agent no longer needs to choose between separate functions that represent closely related business operations. Instead, a single compensation tool exposes an explicit action parameter, while the existing order lookup tool can optionally return delivery-tracking information through a clearly defined flag.

Anthropic’s tool-design guidance recommends consolidating related operations into fewer, more capable tools when separate functions create unnecessary semantic overlap. Claude selects tools primarily from their names, descriptions, schemas, and the current task. When multiple tools appear capable of satisfying the same request, selection accuracy declines because the agent must infer distinctions that should have been made explicit in the interface design.

Option A adds routing complexity but leaves overlapping financial operations available within the same sub-agent. Option C reduces the number of tools loaded initially, but it does not eliminate the semantic duplication between compensation operations or overlapping lookup functions. Option D may improve behavior through examples, but it compensates for a poorly designed tool surface rather than correcting the root cause.

The consolidated schemas should use enums for supported actions, clearly define when each action applies, and document the returned fields. This creates a smaller and more deterministic agent-computer interface.

Official references/topics: Tool consolidation, semantic tool boundaries, action parameters, MCP tool-selection accuracy.

Option A removes the semantic ambiguity created by one generic tool performing three substantially different operations. Each replacement tool can have a distinct name, focused description, appropriate required parameters, and an output schema designed for its task. For example, extract_data_points can return typed records, while verify_claim_against_source can return a verdict, supporting excerpt, and source location.

Anthropic’s tool-design guidance recommends thoughtful tools with clear, distinct purposes and natural task boundaries. Ambiguous or overlapping capabilities make it harder for agents to select the correct operation and interpret its results consistently.

Option B improves the existing interface, but the implementation and result contract remain overloaded, increasing the possibility that the model or tool will mix behavior across modes. Option C adds another probabilistic classification stage without repairing the underlying interface. Option D may reduce some errors, but free-text interpretation remains the principal control mechanism. Purpose-specific tools encode the intended operation directly into the callable interface, permit strict schemas tailored to each result type, and make evaluation failures easier to diagnose. This produces a stronger contract between the agent and deterministic document-processing system.

================

MCP prompts are exposed as user-invoked commands rather than autonomous tools or permanently loaded system instructions. Claude Code dynamically discovers prompts from connected MCP servers and displays them in the command list using the naming convention /mcp__servername__promptname .

Arguments are supplied as space-separated values after the command. When executed, the MCP server resolves the prompt and its returned content is injected into the active conversation. Anthropic’s official documentation provides examples such as /mcp__github__list_prs and /mcp__jira__create_issue " Bug in login flow " high . ( https://code.claude.com/docs/en/mcp )

Option A would consume context continuously and incorrectly treat optional workflow templates as mandatory system instructions. Option B confuses MCP prompts with MCP tools: tools are model-callable operations, while prompts are reusable prompt templates invoked as commands. Option C describes MCP resources, which can be referenced and attached but are a distinct MCP capability.

For the stated server, the team could invoke commands such as /mcp__devops__deploy_checklist or /mcp__devops__incident_response service-name . The exact server segment is derived from the configured server name, with normalization applied where necessary.

Official references/topics: MCP Prompts; Dynamic Prompt Discovery; MCP Slash-Command Naming; Prompt Arguments.

The key difference is reviewer independence. In the original session, Claude retains the reasoning, assumptions, implementation decisions, and intermediate conclusions that led to the refactor. That context can anchor the subsequent review toward defending or confirming the chosen approach instead of evaluating the resulting code independently. The separate CI review begins with fresh context and can assess the implementation solely against the code and review criteria.

Anthropic’s Claude Code best-practices documentation explicitly states that fresh context improves code review because Claude is not biased toward code it has just written. It recommends a writer/reviewer pattern using separate sessions or a review subagent with an isolated context.

Option B is possible in an uncontrolled comparison, but the scenario’s defining distinction is that one review occurs in the implementation session and the other is independent. Option C is false because local Claude Code can read and search the repository when permissions and tools permit it; it is not inherently restricted to the current file. Option D would require evidence of context saturation, such as degraded instruction following or an almost-full context window. No such evidence is supplied. Prior-reasoning bias most directly explains the observed discrepancy.

================

Option D builds an evidence-based architectural map without indiscriminately loading hundreds of files. Authentication entry points may include route handlers, middleware registration, token-validation functions, session constructors, or identity-provider callbacks. After Grep identifies those anchors, targeted Read operations can establish their responsibilities, while imports, call sites, and configuration references reveal the downstream authorization flow. Anthropic’s large-codebase guidance recommends scoping Claude to the portion of a repository touched by the task because unrelated instructions and file reads consume tokens and degrade performance. Its common workflows guidance similarly recommends beginning broadly and narrowing into specific components. Option A launches agents before the relevant service boundaries are known and may produce overlapping, inconsistent investigations. Option B is an uncontrolled lexical sweep that will include tests, documentation, unrelated tokens, and incidental terminology. Option C appropriately checks project guidance but incorrectly delegates technical file selection to a new engineer who may not know the architecture. Incremental dependency tracing maintains context efficiency while producing a verifiable end-to-end map grounded in actual code paths.

================

Project skills are stored at .claude/skills/ < skill-name > /SKILL.md . The directory name becomes the invocable command name, so .claude/skills/migrate-component/SKILL.md creates /migrate-component . Anthropic distinguishes project skills from personal skills: project skills apply only to the repository, while skills under ~/.claude/skills/ apply to one user across all projects. ( https://code.claude.com/docs/en/skills )

Committing the project skill to version control ensures that every developer receives the same workflow and that changes are reviewed, versioned, and synchronized with the codebase. Anthropic’s .claude directory guidance states that project configuration should be committed when it is intended to be shared with the team, whereas files under ~/.claude are personal. ( https://code.claude.com/docs/en/claude-directory )

Option A requires manual duplication across developer machines and allows versions to diverge. Option B loads the migration procedure into every conversation even when no migration is occurring; Anthropic recommends skills for reusable checklists and multi-step procedures because their bodies load only when used. Option C describes no valid mechanism for defining a skill’s content in settings.json .

Option D provides the correct scope, command name, on-demand loading behavior, and team distribution model.

Official references/topics: Project skills, SKILL.md structure, command invocation, version-controlled team configuration.

Resuming preserves the prior architectural analysis, dependency mapping, and conversation history, avoiding the cost of repeating an hour of valid work. Anthropic states that resuming by session ID restores the agent’s full prior context, including files read, analysis performed, and decisions made. ( https://code.claude.com/docs/en/agent-sdk/sessions )

However, the session represents historical knowledge rather than a repository snapshot. Because three files changed externally, the agent must be told which files are affected and directed to re-read them before relying on earlier conclusions. Anthropic clarifies that sessions persist the conversation, not the filesystem. ( https://code.claude.com/docs/en/agent-sdk/sessions ) Targeted re-analysis updates the stale portion of the agent’s model while retaining the nine unchanged files’ established context.

Option A discards valuable work even though most of the analyzed code remains unchanged. Option C is accurate but inefficient because it reprocesses all twelve files regardless of whether they changed. Option D is unsafe: the agent may continue reasoning from obsolete function signatures, dependencies, or control flows.

The continuation prompt should identify the changed files, summarize the merge’s purpose where known, and request a focused comparison against the earlier understanding. Any architectural conclusions affected by those changes should then be revised explicitly.

Official references/topics: Session Resume; Filesystem Versus Conversation State; Targeted Re-Analysis; Repository Change Awareness.

The investigation path cannot be reliably predetermined because the responsible files, components, and execution sequence are unknown. The agent should begin with available evidence—such as route definitions, stack traces, logs, or endpoint references—and use each discovery to decide the next search, file read, or diagnostic action.

Anthropic distinguishes predefined workflows from agents that dynamically direct their own processes and tool usage. Agents are appropriate for open-ended problems where the required number and nature of the steps cannot be predicted or encoded as a fixed path. During execution, the agent should obtain ground truth from tool results and adapt its plan based on that environmental feedback. ( https://www.anthropic.com/engineering/building-effective-agents )

Option A requires a comprehensive plan before the agent has inspected the code, so the plan would rest on unsupported assumptions. Option B forces every investigation through the same sequence even when an early discovery makes later steps irrelevant or identifies a different dependency path. Option C assumes the four layers can be investigated independently; tracing an intermittent request failure usually involves dependencies revealed sequentially across layers.

Option D implements an adaptive agent loop: inspect, form a hypothesis, use tools, evaluate the evidence, and generate the next subtask. The workflow should still include stopping conditions, testable hypotheses, and escalation when evidence remains inconclusive.

Official references/topics: Adaptive Agent Loops, Dynamic Task Decomposition, Tool Feedback, Open-Ended Coding Investigations.

Option C matches the distinction between reasoning about delegation and executing it. Defining subagents makes their descriptions available for selection, but the coordinator must still invoke the SDK’s subagent-spawning tool. Current Claude Agent SDK documentation calls this the Agent tool; Task was its earlier name and remains relevant to older SDK configurations. Anthropic’s Subagents in the SDK documentation instructs developers to include Agent in allowedTools so subagent invocations are approved automatically. Without that permission, an invocation can fall through to a permission callback or be denied under a non-interactive permission mode. Option A is unlikely because the configured subagent descriptions already tell Claude when each agent should be selected, although explicit prompting can improve invocation reliability. Option B misstates context isolation: context must be included in the spawning prompt, but that issue occurs after an invocation is attempted and does not explain the absence of all subagent executions. Option D would normally produce truncation evidence or incomplete output rather than consistent verbal promises with no tool call. The configuration should therefore permit Agent, explicitly request delegation where necessary, and log subagent invocation events.

================

Option A follows the MCP error contract. An error originating during execution of a valid tool call—such as an API failure, input-validation problem, or business-logic failure—should be returned inside the tool result with isError: true. The content should explain what happened and, where possible, provide actionable recovery guidance.

The official MCP tools specification distinguishes tool-execution errors from protocol-level errors and specifies that execution failures are reported through tool results using isError: true. Anthropic’s tool-using agent tutorial provides the equivalent Claude API pattern using is_error: true, allowing Claude to retry with corrected input, request clarification, or explain the limitation.

Option B falsely represents a failed operation as successful, weakening reliable failure detection. Option C deprives the agent of the information required to determine an appropriate recovery action. Option D may be converted into a tool error by some SDK runners, but uncaught exceptions are not the MCP-level response contract. The strongest implementation returns a concise, sanitized, actionable error result and separately records detailed diagnostics in server logs.

Option D preserves the evidence instead of manufacturing certainty. The two estimates are not directly interchangeable: one is an industry estimate with unspecified methodology, while the other is a peer-reviewed estimate with an explicit confidence interval. Converting both into model-generated confidence scores and calculating a weighted average would create a new figure that neither source reported and that may have no statistical validity. Anthropic’s hallucination-reduction guidance recommends making claims auditable through quotations, citations, and supporting evidence rather than presenting unsupported synthesis as fact. Its Citations documentation similarly emphasizes retaining the exact source passages supporting individual claims. Filtering uncertain findings, option B, would remove decision-relevant information. Requiring two-source corroboration, option C, could also discard credible evidence concerning emerging or specialized subjects. The synthesis agent should report the estimates separately, explain their methodological differences, identify which findings are strongly supported or disputed, and state what evidence would resolve the disagreement. This produces calibrated, useful reporting without arbitrary selection, excessive hedging, or false precision.

================

Option D addresses the observed inconsistency at the model-behavior level. A schema can require that materials be a string, but it cannot teach Claude which lexical form the application considers canonical or demonstrate when a source phrase should populate the field. Anthropic identifies examples as one of the most reliable ways to steer output format, structure, and consistency, recommending several relevant and diverse examples that mirror the real task in its prompting best practices . Complete input-output pairs show both recognition and normalization: for example, a description containing “60% cotton, 40% polyester” can consistently map to the chosen “cotton/polyester blend” representation. They can also include difficult cases where material information is embedded indirectly in prose. Temperature zero reduces sampling variability but does not repair an underspecified transformation rule. A more capable model likewise lacks the missing formatting convention. Making the field required is dangerous because documents may legitimately omit materials; it can force unsupported values and increase hallucinations. Few-shot examples therefore supply the missing decision boundary while preserving truthful absence handling. The examples should be evaluated on held-out descriptions and supplemented by deterministic post-processing if downstream systems require an exact controlled vocabulary.

================

The most reliable architecture separates semantic interpretation from deterministic normalization. Claude is well suited to identifying that “$12” and “12.00” represent prices, or that a leaf icon represents a dietary classification. However, canonical conversion—removing currency symbols, converting values to decimal types, mapping icons to controlled labels, and enforcing locale-specific rules—is more predictably performed in application code.

Structured Outputs guarantee that Claude returns valid JSON matching the supplied schema, but that guarantee concerns structural conformance. It does not by itself guarantee that every semantically equivalent source representation will be normalized identically. Anthropic’s evaluation guidance identifies code-based checks as the fastest, most reliable, and most scalable mechanism for rule-based validation. ( https://platform.claude.com/docs/en/build-with-claude/structured-outputs )

Option D therefore minimizes model responsibility: Claude extracts the evidence as represented, and deterministic post-processing converts it into the canonical downstream format. This also makes normalization rules independently testable, version-controlled, and auditable.

Option A increases latency and cost without solving normalization. Option B improves output structure, but prompt-based normalization can still vary across ambiguous formats. Option C introduces unnecessary stochasticity and majority-vote logic where explicit parsing rules are available. The downstream contract should remain stable, but format conversion should be implemented using deterministic transformations rather than repeated probabilistic inference.

Official references/topics: Structured Outputs—schema compliance; Evaluation Design—code-based validation; Reliable extraction pipelines.

Option C is the only approach that guarantees the required terminal condition independently of the model’s behavior. When the agent loop stops, the orchestration layer evaluates the recorded outcome. If neither a successful resolution nor a confirmed human escalation occurred, deterministic application code invokes escalate_to_human using the information accumulated before termination.

The max_turns limit is a host-controlled safety boundary. Once that boundary is reached, the model may no longer have an opportunity to follow a prompt instruction or make another tool call. Therefore, the required fallback cannot depend entirely on Claude deciding to escalate before its remaining turns are exhausted.

Option A escalates based on an arbitrary 80% threshold and may prematurely terminate cases that could have been resolved successfully within the remaining budget. Option B provides additional turn capacity but does not guarantee that the second agent will complete its work or escalate before its own limit is reached. Option D remains probabilistic and cannot operate after an unexpected termination has already occurred.

The orchestration fallback should be idempotent, ensuring that repeated completion checks cannot create duplicate escalation records. It should also include verified customer information, relevant order data, completed actions, failure reasons, and the unresolved request in the handoff payload.

Official references/topics: Agent-loop termination, deterministic fallback orchestration, terminal-state validation, human handoff guarantees.

Option C respects the customer’s explicit request for human assistance. The agent should not attempt to retain the interaction, gather additional account information, or require the customer to repeat the request. Because the escalation decision has already been made by the customer, further autonomous investigation would create unnecessary delay and disregard clear human direction.

Anthropic’s trustworthy-agent framework emphasizes maintaining meaningful human control over agent autonomy. Anthropic’s customer-support implementation guidance also recommends defining interaction branches and measuring escalation efficiency as part of the system’s success criteria.

Option A deliberately delays escalation despite an unambiguous request. Option B performs unnecessary tool calls and may expose or retrieve account information that is not required before transferring the conversation. Option D similarly introduces another conversational barrier. Since the current exchange is short and contains no tool-generated evidence, passing the available conversation history gives the human agent the immediate context—the customer’s frustration, repeated unsuccessful attempts, and explicit transfer request—without pretending that account investigation has occurred.

================

Option A implements an iterative orchestrator-worker loop in which synthesis is treated as an evaluation checkpoint rather than an irreversible transition to report generation. When synthesis identifies missing evidence, the coordinator can formulate focused follow-up tasks, send them to the agents with the appropriate tools, and repeat synthesis after receiving the additional findings.

Anthropic’s multi-agent research architecture follows this pattern: the lead agent synthesizes subagent findings and determines whether further research is required. If gaps remain, it creates additional subagents or refines the research strategy. This preserves specialization and centralized control.

Option B makes the incompleteness visible but does not improve research coverage. Option C may increase initial cost without guaranteeing that the specific gaps discovered during synthesis will be addressed. Option D weakens separation of concerns by giving the synthesis agent search capabilities that belong to the research specialists. Targeted redelegation is more efficient because the second research round is informed by concrete deficiencies rather than speculative breadth. It also allows the coordinator to track completeness explicitly before authorizing final report generation.

================

Option B correctly separates asynchronous bulk work from latency-sensitive operational work. Anthropic describes the Message Batches API as a cost-effective asynchronous service for high-volume requests that do not require immediate responses. Batch requests are processed independently, normally finish within an hour, may remain pending for up to 24 hours, and are billed at 50 percent of standard API prices. Those characteristics fit standard monthly reports because they are archived after processing and have no immediate business deadline. Urgent exception reports, however, must trigger an alert within 30 minutes. The batch service cannot guarantee that deadline, even if many batches finish quickly; a workload should not use typical completion time as a service-level guarantee. Routing exceptions through the synchronous Messages API provides the real-time response path needed for alerting, while the shared JSON schema keeps downstream records consistent across both routes. Option A knowingly permits delayed alerts. Option C introduces an hourly submission delay before processing even begins. Option D meets latency requirements but wastes the batch discount on non-urgent reports. A routing layer based on document priority therefore satisfies both the cost objective and the business deadline without changing the extraction contract.

================

The pipeline must preserve source evidence while making inconsistencies explicit. Option D records the amount stated on the invoice separately from the total derived from extracted line items. A mismatch then becomes a machine-detectable validation condition rather than an invisible extraction defect.

This approach is superior because it does not silently overwrite source data or ask another model to guess which value is correct. Anthropic’s evaluation guidance recommends automated, code-based grading whenever the criterion can be expressed deterministically. Arithmetic reconciliation is precisely such a criterion. ( https://docs.anthropic.com/en/docs/build-with-claude/develop-tests ) In production, the summation should preferably be calculated by application code using normalized decimal values, even though the option describes the model populating calculated_total . The essential design principle remains the same: preserve stated_total , compute an independent total, compare them, and route discrepancies for adjudication.

Option A might improve behavior but cannot resolve genuine OCR corruption and could encourage the model to modify extracted values merely to create mathematical consistency. Option B introduces a second probabilistic judgment without new evidence. Option C is unacceptable for accounting data because it fabricates adjusted amounts and destroys fidelity to the invoice.

The schema should therefore expose both values and attach a validation status or review reason when they differ.

Official references/topics: Deterministic Validation; Human-in-the-Loop Review; Structured Output Design; Source-Fidelity Controls.

Option C converts the linear pipeline into a controlled iterative research loop. The document-analysis agent is best positioned to identify precisely what the retrieved evidence fails to answer. It should return structured gaps containing the missing question, evidence already examined, preferred source characteristics, and the coverage criterion that remains unsatisfied. The coordinator can then issue focused searches and resubmit the new material for analysis.

Anthropic’s multi-agent research architecture uses a lead agent to decompose work, coordinate research agents, assess returned information, and continue investigation when further evidence is required. The guidance also stresses clear objectives, output formats, source requirements, and task boundaries to prevent gaps and duplicated work.

Option A may improve initial coverage but cannot anticipate every deficiency revealed only after sources are examined. Option B documents incompleteness rather than correcting it. Option D retrieves more information but does not ensure that the new evidence is analyzed and tested against the original gap. The loop in Option C establishes an explicit completion condition and preserves specialization: analysis identifies the gap, the coordinator orchestrates, search agents retrieve evidence, and analysis verifies whether the gap has actually been closed.

================