Foundations: Speaking the Language
prerequisiteAlmost every intimidating term in Domains 1–5 is built on three plain ideas: (1) you send messages and get a response, (2) the model can ask you to run a tool and you feed the result back, (3) doing that in a loop is an 'agent'. Everything else is naming conventions on top.
Layer 1 — The API Fundamentals: how you talk to the model
Everything starts here. Stripped of jargon, using Claude is a single HTTP request: you POST a list of 'messages' to the Messages API, and you get back a response. A message has a 'role' ("user" or "assistant") and 'content'. You can also send a 'system' prompt — standing instructions that frame the whole conversation ("You are a careful code reviewer..."). The model replies with assistant content and a field called stop_reason that tells you WHY it stopped talking. That's the whole foundation. An 'LLM call' or 'completion' or 'inference' all refer to this one round trip. When people say 'context' or 'context window', they mean everything you packed into that request (system + all prior messages + tool results) — the model only knows what's in front of it on THIS call; it has no memory between calls unless you resend it. This single fact explains half of Domain 5.
Skills to demonstrate
- Read a Messages API request and name its parts: model, max_tokens, system, messages[] (each with role + content).
- Explain that the model is stateless between calls — 'memory' is just you resending prior messages each time.
- Define stop_reason and name the two you'll see constantly: "end_turn" (the model finished its reply) and "tool_use" (the model is pausing to ask you to run a tool).
- Map the everyday synonyms: 'LLM call' = 'completion' = 'inference' = one Messages API round trip.
Distractor traps
- Thinking the model 'remembers' earlier turns on its own. It doesn't — you resend history every call. (This is why long conversations cost more and why context management is a whole domain.)
- Confusing the system prompt (standing instructions) with a user message (a turn in the conversation).
- Assuming stop_reason is decorative. It's the control signal your whole agent loop hinges on in Domain 1.
Open the Claude API docs and make ONE real call (or read a complete example). Identify by name: the system prompt, the messages array, max_tokens, and the stop_reason in the response. Then write one sentence in your own words: 'The model is stateless, which means ___.' If you have an Anthropic API key, send a two-message conversation and watch how you must include the first exchange in the second request for it to 'remember'.
Check yourself
You send Claude a question, get an answer, then send a follow-up that says 'expand on your second point.' For the model to know what 'your second point' refers to, what must be true of your second API request?
In a Messages API response, what does stop_reason = "tool_use" tell you?
Layer 1.5 — Tools: how the model reaches outside itself
A model on its own can only produce text. A 'tool' is how it does anything else — look up an order, query a database, search the web. Mechanically, a tool is just a named function you describe to the model in your request: a name, a description, and an input schema (what arguments it takes). You are NOT giving the model the ability to run code. You're giving it a menu. Here's the actual flow, and it surprises people: (1) you send messages + a list of available tools; (2) the model, instead of answering, replies with a tool_use block saying 'call lookup_order with {id: 12345}' and stops with stop_reason "tool_use"; (3) YOUR code runs the actual function and gets a result; (4) you send that result back as a new message (a 'tool_result'); (5) the model reads it and continues. The model never executes anything — it requests, you execute, you report back. The tool's DESCRIPTION is how the model decides which one to pick, which is why Domain 2 obsesses over writing good descriptions.
Skills to demonstrate
- Define a tool as: name + description + input schema, supplied by you in the request — a menu, not executable code.
- Walk the tool round trip: model requests (tool_use) → your code executes → you return tool_result → model continues.
- Explain that the model picks a tool primarily from its DESCRIPTION, which is why vague descriptions cause wrong-tool selection (Domain 2.1).
- Distinguish tool_use (model's request, in the assistant message) from tool_result (your answer, in a user message).
Distractor traps
- Believing the model runs the tool. It only emits a request; your code does the work and reports back. This separation is the whole security and control story.
- Thinking the model picks tools by reading their code or names alone. It reads the DESCRIPTION you wrote. Bad descriptions = bad selection.
- Forgetting that the tool_result has to be sent back in a follow-up call — it's another round trip, more context spent.
Find the tool-use guide and trace one complete example end to end. On paper, draw the five steps: request-with-tools → model emits tool_use → you execute → you return tool_result → model continues. Then connect it to your own work: in YesChef, what would a 'lookup_booking' tool's description need to say so the model never confuses it with a 'lookup_customer' tool? That instinct is literally Domain 2.
Check yourself
When Claude 'uses a tool' to look up an order, who actually executes the lookup against your database?
Your app has two tools, lookup_customer and lookup_order, both described only as 'Retrieves data.' The model keeps calling the wrong one. Based on how tool selection works, what's the root cause?
Layer 2 — What an ‘agent’ actually is (the loop, demystified)
Here's the demystification: an 'agent' is the tool round trip from Layer 1.5, run in a loop until the model says it's done. That's it. You send messages + tools. If stop_reason is "tool_use", you execute the tool, append the result, and call again. If it's "end_turn", the model is finished and you stop. Loop. The model is 'driving' because IT decides which tool to call next based on what it has seen so far — you didn't hardcode the sequence. That's the line Anthropic draws: a 'workflow' follows a path YOU predetermined in code; an 'agent' lets the model direct its own steps and tool use. Neither is better — Domain 1.6 is about choosing. A 'subagent' is just an agent that another agent (a 'coordinator') calls to handle a piece of work, like delegating to a specialist. 'Multi-agent' systems are coordinators plus subagents. The 'Agent SDK' is Anthropic's library that runs this loop FOR you so you don't hand-write it; the raw version (you write the while-loop yourself) is the 'Client SDK' / direct API. Same concept, two levels of convenience — and Domain 1 tests that you know which is which.
Skills to demonstrate
- State the agent loop in one breath: call model → if stop_reason is tool_use, run tool, append result, call again → if end_turn, stop.
- Articulate the workflow-vs-agent distinction: predetermined code path (workflow) vs model-directed steps (agent).
- Define coordinator, subagent, and multi-agent in plain terms (a manager delegating to specialists).
- Distinguish the Agent SDK (runs the loop for you) from the raw Client SDK / direct API (you write the loop) — and know that the exam's Domain 1.1 language describes the raw loop.
Distractor traps
- Thinking 'agent' implies something mystical or self-aware. It's a loop with a model deciding the next step. Demystify it and Domain 1 gets easy.
- Assuming agents are always better than workflows. Predetermined workflows are more reliable when the steps are known — Domain 1.6 is exactly this tradeoff.
- Conflating the Agent SDK (autonomous loop handled for you) with hand-writing the loop. The exam expects you to know stop_reason control flow even though the SDK hides it.
- Believing subagents share memory with the coordinator automatically. They don't — context must be passed explicitly (Domain 1.3). This trips up almost everyone.
Read 'Building Effective Agents' (it's short and plain-spoken). Then write the agent loop as 4 lines of pseudocode from memory — call, check stop_reason, execute tool / append, repeat. Connect it to something you've built: your Idea Router classifies text and routes it. Was that a WORKFLOW (you coded the path) or an AGENT (the model chose)? Defending your answer in one sentence is real Domain 1.6 reasoning.
Check yourself
In the simplest terms, what makes a system an 'agentic loop'?
A coordinator agent delegates part of a research task to a subagent. The subagent produces a weak result, seemingly unaware of facts the coordinator already gathered. What's the most likely cause?
Layer 3 — MCP & Claude Code: naming what you’ve half-built
Two more terms and you can read the whole exam. MODEL CONTEXT PROTOCOL (MCP) is a shared standard for how a model connects to external tools and data. Think of it like USB: instead of every app inventing its own way to expose tools, MCP is a common plug. An 'MCP server' is a program that exposes some capability (your database, GitHub, Jira) as MCP 'tools' (actions the model can request) and MCP 'resources' (read-only content the model can browse, like a catalog or a schema). The payoff: you write the integration once to the standard, and any MCP-aware client can use it. CLAUDE CODE is Anthropic's terminal-based coding agent — the agent loop from Layer 2, wired to your filesystem and shell with built-in tools (Read, Write, Edit, Bash, Grep, Glob). You steer it with a CLAUDE.md file (standing project instructions — like a system prompt that lives in your repo), custom slash commands, and 'skills' (on-demand instruction bundles). If you've ever pasted project conventions into a prompt so the model would follow them, you've reinvented CLAUDE.md. Domains 2 and 3 are mostly the disciplined, named versions of things you've already improvised.
Skills to demonstrate
- Explain MCP with the USB analogy: a common standard for connecting models to external tools/data, written once, usable by any MCP client.
- Distinguish MCP tools (actions the model requests) from MCP resources (read-only content it can browse).
- Define Claude Code as an agent loop wired to your filesystem/shell with built-in tools (Read/Write/Edit/Bash/Grep/Glob).
- Map CLAUDE.md to 'a system prompt that lives in your repo' — standing instructions the agent always loads.
Distractor traps
- Thinking MCP is a product or a model. It's a protocol — a shared format. The 'server' is what implements it.
- Conflating MCP tools and resources. Tools DO things (and may have side effects); resources are content you READ to reduce exploratory tool calls. Domain 2.4 leans on this.
- Assuming Claude Code is a different kind of AI. It's the same model running the same agent loop — just pointed at your codebase with file/shell tools.
Two small things. (1) Read the MCP intro and write one sentence: 'MCP is like USB because ___.' (2) If you haven't, install Claude Code in a throwaway folder and create a tiny CLAUDE.md with one rule (e.g., 'always use two spaces after a period' — your actual writing preference). Watch it obey. That file IS the thing Domain 3 spends a fifth of the exam on. You'll have built the foundational artifact before you study it.
Check yourself
What is the Model Context Protocol (MCP), most precisely?
In a Claude Code project, what role does the CLAUDE.md file play?
Teach it back
Without looking, explain to an imaginary junior dev: what a single Claude API call looks like (what you send, what comes back), what happens when the model wants to use a tool, and what makes something an 'agent' rather than just an API call. If you can say all three in your own words, you're ready for Domain 1.