You've used Claude Code in a terminal. It writes code, fixes bugs, answers questions. Maybe that's all you've used. This page is the ladder from "I use a coding assistant" to "I architect agentic systems" — one rung at a time, with a story at every rung explaining why the next thing exists.
Why take a certification at all?
Honest answer, for two different readers:
If you're newer: working from scattered blog posts gives you islands of knowledge with invisible gaps between them. You know prompting tricks but not why the agent loop terminates; you've heard "MCP" but couldn't say what problem it solves. A certification blueprint is a map of the whole territory — it tells you what a complete practitioner knows, so your learning has a shape instead of a drift. Study the blueprint honestly and the credential is a byproduct; the structure is the prize.
If you're experienced: you likely know 70% of this deeply and have never named the other 30%. The blueprint finds your blind spots (for most veterans: MCP primitives, caching mechanics, the official vocabulary). And in interviews, "I build this daily" plus a current credential beats either alone — the credential is independent verification that your experience maps to the industry's shared language.
Either way: the exam changed yearly-ish (12-month validity) precisely because the field moves — treating it as a refresh discipline is the architect habit itself.
Rung 1 · What is actually happening when you use Claude Code?
The story you've lived: you type "fix the failing test", and Claude Code searches (greps) the codebase, reads files, edits one, reruns the test, and reports success.
What you watched was an agent loop — the single most important concept in the entire certification:
flowchart TD
Y[You: fix the failing test] --> M[🧠 Claude decides: run the test first]
M --> T[Claude Code executes: npm test]
T --> O[Output appended to the conversation]
O --> M2[🧠 Claude decides: read auth.ts]
M2 --> T2[Executes: Read auth.ts]
T2 --> M3[🧠 …edit → rerun → done]
Two things to notice, because the whole exam hangs on them:
Claude never ran anything. It asked for each action; Claude Code's own program (the harness) executed it — after checking permissions. The model decides; the harness executes.
The loop ended because a condition was met (test passed). Loops need termination conditions, budgets, and gates — that's what "architecture" means here.
📖 Story: the day the loop needs a leash
A developer asks an agent to "clean up the repo." Twenty minutes later it's still working — it reorganized folders, rewrote half the README, and is now "improving" tests that were fine. Nothing malicious happened; the loop just had no leash: no budget (max turns/cost), no scope gate (which paths are off-limits), no definition of done.
Every architecture topic in Domain 1 — budgets, gates, human approval, termination — exists because of afternoons like this one. When the exam asks "how do you prevent X," it's asking where you'd put the leash.
Rung 2 · The same brain, called from Python
Here's the mental shift that makes everything below click: Claude is a thinking partner, not a vending machine. What you bring to the partnership is everything the model can't supply for itself — the context, the objective, the stage, the goals, the rules. When Claude Code feels magical, it's because Anthropic pre-built all five of those for the coding domain. The rest of this ladder is learning to build them yourself, for any domain.
Claude Code is one harness around the model. The Claude API — Anthropic's Messages endpoint, the HTTPS service that carries every model call in this guide, whether Claude Code makes it or your Python script does — lets you build your own. Here is the entire secret — the Claude API call at the bottom of everything:
PYTHON
import anthropic
client = anthropic.Anthropic() # ANTHROPIC_API_KEY in env
# Abridged: commit_log is a placeholder for your real commit text.
resp = client.messages.create(
model="claude-sonnet-latest",
max_tokens=1024,
system="You are a concise release-notes writer.",
messages=[{"role": "user",
"content": "Summarize these commits:\n" + commit_log}],
)
print(resp.content[0].text)
That's it. Claude Code, the Claude apps, and the agent products built on Anthropic's models are programs that construct a messages array, call this endpoint (or a supported Bedrock/Vertex route), and do something with the response.
🧭 Every field of that request — and of the response it returns — is specified on one page: The Messages API Spec. Read it once and every SDK call in this guide becomes legible: the SDK is sugar over those two JSON shapes.
Why would you drop from Claude Code to the Claude API? The story: your team loves that Claude Code writes release notes when asked. Now you want release notes generated automatically on every merge, inside CI (your continuous-integration pipeline), with no human at a keyboard. That's not an assistant anymore — that's a feature. Features are built on the Claude API (or the Agent SDK — rung 4).
Rung 3 · Giving the model hands — tools
The model — reachable only through the Claude API — can only talk. To let it do, you declare tools: JSON descriptions of functions your code implements. The model requests; you execute; you feed back the result.
PYTHON
# Abridged/pseudocode: MODEL and my_real_lookup() are placeholders for your model id + lookup function.
tools = [{
"name": "get_order_status",
"description": "Look up one order's shipping status by order id.",
"input_schema": {"type": "object",
"required": ["order_id"],
"properties": {"order_id": {"type": "string"}},
"additionalProperties": False}
}]
resp = client.messages.create(model=MODEL, max_tokens=500, tools=tools,
messages=[{"role": "user", "content": "Where is order A-1042?"}])
# resp.stop_reason == "tool_use" → the model WANTS the tool run:
block = next(b for b in resp.content if b.type == "tool_use")
result = my_real_lookup(block.input["order_id"]) # ← YOUR code acts
# …return a tool_result message, call the Claude API again, get the final answer.
This request-execute-return cycle is the agent loop from Rung 1, now in your own code. Congratulations — you've seen 27% of the exam.
Rung 4 · The Agent SDK — Claude Code's engine, as a library
Writing the loop, permissions, file tools, and retries yourself gets old. The Claude Agent SDK (Python/TypeScript) is the same engine Claude Code runs on, packaged for your programs: the loop, Read/Write/Bash/Grep tools, permissions, hooks, subagents, MCP — all included.
When the Claude API vs the SDK? — the story version:
You're building a support bot for your product that reads your docs and files tickets → Agent SDK (you want the loop + tools managed for you).
You're adding one AI feature — summarize this page, classify this email → plain Claude API (one call, no loop needed; the SDK would be a truck for a grocery run).
You're at a terminal developing software → Claude Code itself.
Same brain at every level; you're choosing how much harness you want prebuilt.
The decision table (bookmark this — it answers "SDK or API?" for every project):
Signal in your project
Build on
There's a loop — the model decides next steps, calls tools repeatedly, runs multi-turn
Agent SDK — it ships the loop, tool execution, permissions, subagents, hooks, MCP client, and context management (compaction included)
It's a single call — classify, extract, summarize, one shaped answer
Claude API — an agent engine here is a truck for a grocery run
A workflow — a few chained calls with checks between (Domain 1's patterns)
Claude API — chaining calls is plain code; no engine needed
Offline volume — 10,000 documents overnight
Claude API's batch API
You need exotic loop mechanics — custom orchestration research, a framework of your own
Claude API — owning the loop is the project
Your language isn't Python/TypeScript
Claude API (the Agent SDK ships in those two; everything else speaks HTTPS)
One disambiguation that trips everyone: pip install anthropic gives you the client library — a thin convenience wrapper (client.messages.create(...)) that is still "using the Claude API" in every sense above; you own the loop. The Agent SDK is a different, higher-level thing: the engine. Three layers, bottom up: raw HTTPS → client library (nicer syntax, same responsibilities) → Agent SDK (the loop machinery, prebuilt).
The smell test: if you find yourself hand-writing tool dispatch, permission checks, or compaction logic, you're re-implementing the Agent SDK one bug at a time — stop and adopt it. And the reverse smell: if your "agent" never loops, you didn't need an agent engine — you needed one well-shaped API call. (Hybrids are normal and good: an SDK-run agent whose harness makes cheap raw-API calls for classification side-tasks.)
Rung 5 · MCP — when your tools need to be plugs, not wiring
At Rung 3 you hand-wired one tool into one program. Now the story grows: your company has a CRM, a ticket system, and a wiki. You want them available in Claude Code, in Claude Desktop, and in the support bot you built with the SDK. Hand-wiring = 3 systems × 3 apps = 9 integrations, each maintained forever.
MCP (Model Context Protocol) fixes the multiplication: each system ships one MCP server; each app already speaks MCP as a client. 3 + 3 = 6 pieces, and any new app instantly gets all servers. It's USB-C for AI tools.
"Is MCP just a REST API?" — the comparison everyone needs
REST API
MCP server
Designed for
programmers reading docs and writing glue code
models discovering and calling capabilities at runtime
Discovery
read the docs, hardcode endpoints
client asks the server: "what tools do you have?" — self-describing
Descriptions
for humans
for the model — the description IS how Claude decides when to use it
Connection
stateless requests
stateful session — an initialization handshake, then negotiated capabilities kept for that connection
Extras
just endpoints
tools + resources (context data) + prompts (templates), each with a defined controller — tools are model-controlled (chosen, not executed, by it), resources app-controlled, prompts user-invoked
Relationship
MCP servers often wrap REST APIs
the adapter that makes an API model-usable
An MCP server is frequently a ~100-line wrapper around an existing REST API — the value is the standard plug, not new functionality.
Rung 6 · From "it works" to "it's an architecture"
The last rung is the exam's actual subject: taking rungs 1–5 and making them safe, cheap, and reliable — guardrails the model can't bypass, budgets that stop runaways, caching that cuts costs 90%, evaluations (evals) that catch regressions, and human approval where money moves. That's Domains 1–5, and you now have the context to read them in order.
Your path from here
You've got the ladder in your head now — so where do you actually start climbing? Find the row that sounds like you and follow it:
Exam Guide → skim domains for 🎯 exam-lens / 🪤 trap callouts → Practice → patch gaps
🎯 Tip for every path: dotted-underlined terms across this guide are clickable — each opens a card with the definition, how it looks in code, and a use-case story. Use them liberally; that's what they're for.