Developer Foundations — The Basics the Architect Exam Assumes

The short answer is that a loop is necessary but not sufficient. What makes a system agentic is who decides the next step. If the model chooses which tool to call next and when to stop, it is agentic. If your code fixes the path in advance, it is a workflow, even if a tool call is involved.

Beyond the focus section. Section 1 covers how a single call produces tokens. It doesn't define "agentic." The answer below uses general knowledge and Anthropic's published workflow-vs-agent distinction. It links back to Section 1 where it can.

The mental model

Section 1 says the model writes its answer "one token at a time" and that "the API is stateless: send the history every time." Put those together:

• One call = the model reads the context window and emits tokens. A tool_use block is also just emitted tokens. It is a request, and your code performs the action.
• The agentic loop = your code runs the requested tool and appends the tool_result to the messages array. It then calls the model again, and repeats while stop_reason is "tool_use". It stops when the model returns stop_reason: "end_turn".

The loop is the mechanism. Agency is the model controlling the loop: how many turns it takes, which tool it calls, in what order, and when it is done.

Your two examples

So the invoice pipeline is not agentic. It is a single LLM call with a forced tool acting as a JSON schema, and your code does the DB write. Section 1's recall question applies directly here: if the document has no vendor, the model will still produce a plausible one. That is why this design needs validation, not a loop.

The traps the exam sets

1. "Multi-turn = agentic." No. A chatbot that goes back and forth with a user over many turns but has no tools is not agentic. The agentic loop is several model calls within one user request, driven by stop_reason.
2. "Uses a tool = agentic." No. Forced tool_choice for extraction is structured output. The model has no choice to make.
3. "More autonomy is better." For a fixed, predictable task like invoice ingestion, the correct answer is the simplest design that works, which is a workflow. Choosing an agent there is over-engineering, and the exam treats it as a distractor.
4. Ending the loop. Exit on stop_reason: "end_turn". Don't exit by parsing the text for "done." Also cap iterations as a safety net.

A gray area: if the invoice call offers optional tools with tool_choice: auto and the model decides whether to call one, that is a single loop iteration where the model had a choice. That leans agentic, but it is a weak case. The exam cares about the clear endpoints.

Memory hook

Code picks the path → workflow. Model picks the path → agent. The loop is just how the model gets to keep picking.

★ Insight ─────────────────────────────────────

• The same messages array mechanics from Section 1 (stateless, resend everything) are why each loop iteration costs more input tokens than the one before. That cost is a real reason to prefer a workflow when the path is known.
• The two designs fail in different ways. A workflow fails on content: a fluent answer that is wrong, caught by validation. An agent fails on actions: the wrong step or the wrong order, caught by hooks and escalation. Getting the pattern right tells you which safeguards you need. ─────────────────────────────────────────────────

tool_choice is not a tool. It's the policy for whether Claude calls a tool (home ④ in the table: "Whether a tool call happens at all"). type names which policy you picked. Read "type": "tool" as "the mode is: force one specific tool."

The mental model: type picks the mode

tool_choice is a tagged union: one object that can take several shapes. type is the tag that says which shape you sent. Only one mode needs extra fields, and that's why a tag is required.

This is why a plain string wouldn't work. "tool" alone doesn't say which tool. The object form lets it carry name:

"tool_choice": { "type": "tool", "name": "record_invoice" }

Beyond the section (general API knowledge): the same object can also carry "disable_parallel_tool_use": true. It can't be a bare string because it holds more than one setting.

The traps the exam sets

1. any vs tool. Both force a call. any means "some tool, you pick." tool + name means "exactly this one." For single-schema extraction like the invoice example, the answer is { "type": "tool", "name": "record_invoice" }. Using any with several tools defined leaves Claude free to pick the wrong schema.
2. Forcing a call is not the same as forcing correct content. ④ guarantees a call happens. ③ (input_schema + strict) guarantees its shape. Neither guarantees truth. Only ⑥, your code after the response, checks that. If a question offers "force tool_choice" as the fix for wrong totals, it's a distractor.
3. ④ vs ⑤. If you want structured JSON and don't need a tool, use output_config.format. Don't build a fake tool and force it with tool_choice. Both are valid, but the section's framing (option B, "Without a tool") marks ⑤ as the direct home for the final answer's shape.
4. Beyond the section: extended thinking. With extended thinking on, only auto and none are supported. Forcing with any or tool errors. This is a classic "why did my request fail" item.

Why type shows up everywhere

The same tag pattern runs through the whole API:

• output_config.format → "type": "json_schema"
• Content blocks → "type": "text" / "tool_use" / "tool_result"

Each time, the key answers "which variant of this object is this?" It's never "is this a tool?"

★ Insight ─────────────────────────────────────

• A tagged union makes invalid combinations easy to reject. name is only legal when type is "tool", so the API can validate the object's shape before the model sees anything.
• The name of the field (tool_choice) says what topic the object is about. type says which option you chose within it. Keep those separate and every type in the API reads the same way. ─────────────────────────────────────────────────

Memory hook: tool_choice is the policy, type is the mode: auto = may, any = must (any tool), tool = must (this one, add name), none = mustn't.

Yes. Every property in input_schema can have its own "description", and Claude reads it. It guides the model but is not enforced. The focus section's example leaves property descriptions out. It only has a tool-level "description": "Record the extracted invoice. Use once per document." So most of what follows comes from general knowledge of the API and is labeled that way.

The mental model

Split the schema into two layers:

(Beyond the section:) Here is a property with a description:

"total_cents": {
  "type": "integer",
  "description": "Invoice grand total in cents, including tax. Convert $12.50 to 1250. Never include currency symbols."
},
"vendor": {
  "type": ["string", "null"],
  "description": "Legal name of the seller as printed. null if no seller is named. Do not guess from the email domain."
}

The model uses that text to decide what value goes in the field: units, format, how to tell apart look-alike fields, and when to use null. Anthropic's tool-use guidance treats detailed descriptions (for the tool and its parameters) as the biggest lever on how well tools get called.

The trap the exam sets

1. "The description says cents, so the value is guaranteed to be in cents." Wrong. strict guarantees that total_cents is an integer. It does not guarantee the integer is correct. A value in dollars, like 12, is still a valid integer. Checking the truth belongs to ⑥: "Your code, after the response… Checked truth."
2. "Putting the rule in a description makes it enforced." Wrong. An instruction doesn't become enforced just because it sits inside the schema. Only the structural keywords are enforced.
3. The recall-check pairing still applies. The section says the null rule needs both an instruction and a nullable type. (Beyond the section:) A property description is a valid second place for the "when to use null" instruction, and it sits right next to the field. The type still has to allow null (["string", "null"]), or there's no legal way to express "missing".

(Beyond the section, worth knowing:) Structured outputs don't support every JSON Schema constraint. Examples include numeric bounds and string-length limits. Anthropic's SDK helpers handle this by removing the unsupported keywords and moving them into the description. That downgrades them from enforced to guidance. It's the same pattern again: you still need to validate them in your own code.

Contrast the exam may force

• Tool description tells the model whether and when to call the tool. With tool_choice: auto or any, it drives which tool gets picked. With a forced tool, as in the section's example, the choice has already been made.
• Property description tells the model what to put in each argument.
• system holds rules that apply to the whole task (role, extraction policy, few-shot examples).
• The same logic applies to ⑤ output_config.format.schema. Descriptions there also guide what fills each field of the final answer.

Memory hook: Keywords are the fence, descriptions are the signpost, and your code is the inspector.

★ Insight ─────────────────────────────────────

• The section says each instruction has "exactly one home." description is the one place where that gets blurry. It sits in the enforced part of the request (③) but only guides, like ①. Sorting a request by strength (guides, enforces, or checks), not by location, answers most structured-output questions on the exam.
• A strong distractor is "add a clearer description" when the actual failure is a wrong type or a missing null option. Those are fixed with schema keywords. The reverse is also true: a wrong-but-valid value (dollars instead of cents) is fixed with a description, few-shot examples, and validation in ⑥ followed by a retry. ─────────────────────────────────────────────────