Architecting production agentic systems requires moving past "hoping" Claude follows a text-based format. This task focuses on leveraging Tool Use (Function Calling) as the primary mechanism for structural enforcement. You will learn to design schemas that acts as "input masks," forcing Claude to return validated, typed data for reliable downstream consumption.
tool_choice StrategiesImagine you hire a data entry clerk. Text Formatting is like giving them a blank Excel sheet and saying, "Please put the names in column A and birthdays in column B." They might mistakenly use MM/DD/YYYY or DD/MM/YYYY, or even put notes in the middle. Your "Extraction" is now a "Cleanup" task.
Tool Use (JSON Schema) is like giving them a web form where the "Birthday" field only accepts a date-picker, the "Name" field is required, and the "Country" field is a dropdown menu. They cannot submit the form unless the data matches your rules. Domain 4.3 is about building the 'Web Form' for Claude.
For an Architect, the decision between "Output in JSON" and defining a tool is about Probability vs. Certainty.
| Method | Mechanism | Reliability | Architecture Impact |
|---|---|---|---|
| Prompt Hinting | "Please use JSON." | Low | High risk of "preamble garbage" breaking parsers. |
| XML Wrappers | <json> tags | Medium | Better, but still requires post-extraction logic. |
| Tool Use | JSON Schema (API-level) | Highest | Claude's "brain" is shifted into a structured data-selection mode. |
The most resilient production tool definitions use precise field types and descriptions that tell Claude exactly what the data represents.
{ "name": "report_finding", "description": "Used to record a security finding for downstream analysis.", "input_schema": { "type": "object", "properties": { "severity": { "type": "string", "enum": ["CRITICAL", "HIGH", "MEDIUM", "LOW"] }, "code_snippet": { "type": "string", "description": "The EXACT line of code from input containing the bug." } }, "required": ["severity", "code_snippet"] } }
For high-complexity extractions (e.g., mapping a 50-page contract), Claude might struggle to jump straight to a complex JSON structure. Use the **Chain of Extraction** pattern.
<system> 1. First, extract all raw quotes related to "Indemnity" into <thinking> tags. 2. Only after analyzing the logic, call the `record_contract_clause` tool. </system>
By forcing Claude to "think before it calls," you ensure it has the context it needs in the **Active Window** to populate the JSON properties correctly, significantly reducing "Empty Property" errors.
An architect must decide when to let Claude choose its tool and when to force it into a machine-only mode.
Using "description": "the result" for every field. Problem: Claude doesn't know how to map raw input into that field.
Defining a field as "type": "integer" but telling Claude in the prompt to "return the price as a currency string like $50.00".
Creating a tool with a single "json_blob": { "type": "string" }. Problem: You've lost all the benefits of API-level validation.
Forgetting to populate the "required" array. Problem: Claude will "lazy-out" and omit fields it finds difficult to extract.
Scenario: You've built an AI agent to extract "Risk Levels" (High, Medium, Low) from news articles. Occasionally, Claude outputs "Very high risk!" instead of "HIGH".
Question: Which design change removes this variability permanently?
report_risk with a field risk_level that has an enum: ["HIGH", "MEDIUM", "LOW"].Correct Answer: B. Enums in a JSON schema through Tool Use provide a strict boundary. Claude is forced to pick one of the allowed strings.
enum is your best friend for reducing false variation.