CCAR-F Agentic Architecture and Orchestration Practice Question
An architect is building a Claude agent that must extract structured data from scanned invoices and then call an ERP API for each invoice. During early testing, the agent occasionally calls the ERP API with incomplete fields because it invents missing values. The architect wants to prevent these hallucinated field values from reaching the ERP. Which approach best addresses this requirement using the Anthropic Messages API?
⚠ Common exam trap
The trap here is assuming that forcing a specific tool_choice or switching to a smaller model will eliminate hallucinated field values, when only schema constraints plus source verification actually address the problem.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Define the ERP submission tool with a strict JSON Schema that marks required fields and adds a second validation tool Claude must call before erp_submit to confirm extracted values against the source text.
Tool schemas in the Anthropic Messages API constrain the shape of tool_use input, so required fields and typed values are enforced structurally. Pairing that with an explicit verification step before the ERP tool closes the loop on values Claude could not actually read from the scan. Increasing tokens, streaming, or relying on downstream ERP validation leaves hallucinated content in the pipeline and does not satisfy the goal of preventing invented fields from reaching the ERP.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Switch the model to a smaller Claude Haiku variant to reduce creative generation, and rely on the ERP API's own field validation to reject bad submissions.
Why it's wrong here
Model size does not eliminate hallucination; smaller models can be less reliable at structured extraction. Delegating validation entirely to the ERP API pushes the problem downstream and may cause failed submissions, duplicate retries, and inconsistent ERP state. The architect wants prevention before the call, not rejection after it, so this does not meet the requirement.
- ✓
Define the ERP submission tool with a strict JSON Schema that marks required fields and adds a second validation tool Claude must call before erp_submit to confirm extracted values against the source text.
Why this is correct
A strict input_schema with required fields and constrained types forces Claude's tool_use block to conform structurally, and a preceding verification tool that re-checks extracted values against the source text surfaces discrepancies before the ERP call. Together they reduce hallucinated values reaching downstream systems, which is exactly the architect's stated goal for scanned invoice extraction.
- ✗
Increase the max_tokens value and add a system prompt instructing Claude to be accurate when reading invoices, then enable streaming so partial tool inputs arrive faster.
Why it's wrong here
Max tokens and streaming affect output length and delivery latency, not factual grounding. A system prompt asking for accuracy is a soft nudge that does not enforce schema constraints or verify values against the source. Streaming partial tool inputs would actually make it harder to validate the complete JSON before submission, worsening the risk described in the scenario.
- ✗
Set the tool_choice parameter to {"type": "tool", "name": "erp_submit"} so Claude must call the ERP tool on every turn, and validate the fields inside the ERP tool handler.
Why it's wrong here
Forcing tool_choice to the ERP tool guarantees the tool is called, but it does nothing to stop Claude from fabricating values for fields it could not read. Validation inside the tool handler would reject bad payloads, but the agent would still generate hallucinated values and could loop indefinitely retrying. This approach addresses call frequency, not the root cause of invented field content.
About these practice questions
This CCAR-F question is part of Courseiva's 271-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Anthropic exam blueprint
This CCAR-F practice question is part of Courseiva's free Anthropic certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the CCAR-F exam.