CCAR-F Agentic Architecture and Orchestration Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Validate the tool input against the JSON Schema in the orchestrator and return a corrective `tool_result` when validation fails.

  Why this is correct

  Even with a schema-bound tool, models can occasionally omit required fields or use wrong types. Validating in the orchestrator and returning an error `tool_result` lets the agent self-correct within the same loop. This creates a closed feedback cycle that raises first-pass validity without human review.

• ✗

  Ask the agent to output the JSON twice and compare the two strings for equality.

  Why it's wrong here

  Double generation doubles cost and latency, and string equality is a poor validator because formatting differences (key order, whitespace) can cause false mismatches. It also does not detect two consistently wrong extractions. Schema validation and a schema-bound tool address correctness far more directly than redundant sampling.

• ✗

  Set the model temperature to its maximum so the agent explores multiple extraction interpretations.

  Why it's wrong here

  Maximum temperature increases variability and the likelihood of malformed or inconsistent field values. For strict schema extraction, determinism and adherence matter more than exploration. High temperature would make outputs less repeatable and more likely to violate the schema, directly conflicting with the reliability goal.

• ✓

  Define a tool whose input schema is the target JSON structure, and instruct the agent to return extracted fields through that tool.

  Why this is correct

  Using a tool whose input schema mirrors the target structure makes the model emit arguments conforming to that schema. Tool inputs are validated against the declared JSON Schema, so malformed shapes are caught at call time. This turns a free-form generation problem into a constrained one, which is far more reliable for strict contract fields.

• ✗

  Remove the OCR tool so the agent relies solely on the model's vision capability.

  Why it's wrong here

  Removing OCR eliminates a fallback for unreadable scans, which the scenario states are common. The model may then guess at illegible fields, producing plausible but wrong values that still pass schema validation. The OCR tool exists to supply ground truth, so removing it reduces accuracy rather than improving schema reliability.