Claude Architecture Explained: 5 Layers and 2 Cross-Cutting Planes

June 23, 2026 · updated June 25, 2026 · How Claude Actually Works (part 31)

▶ Watch on YouTube & subscribe to The Stack Underflow

Every Claude release note, every new MCP server, every Agent SDK update — they all land somewhere on the same five-layer stack. If you do not have that map in your head, each announcement feels like a separate surprise. If you do have it, you can read a changelog headline and immediately know: layer zero or layer four? New protocol surface or new reach primitive? The stack is not a taxonomy you memorise once; it is a reasoning tool you use every day.

This is the finale episode of “How Claude Actually Works.” It stitches every concept in the series into a single coherent structure. New here? This is the orientation that makes every other episode click. Returning? This is the cheat-sheet you pin to the wall.

The one-sentence version: The Claude stack is five layers (model → protocol → reach → orchestration → surfaces) plus two cross-cutting planes (prompts and context/reliability/cost) — each layer resting on the one below, so any new feature has exactly one place to land.

Layer 0 — The Model

Layer 0 is the absolute ground floor. It is the neural network itself: a function that takes a sequence of tokens (the byte-pair-encoded chunks your text is split into) and returns a probability distribution over the next token, repeated until a stop condition is reached. That is the whole job. Nothing else happens here.

Every other layer in the stack rests on this one. When Anthropic ships a new model — the Opus 4 family (Opus 4.0 through 4.8 as of mid-2026), the Sonnet 4 family (Sonnet 4.0 through 4.6), or the newer Fable 5 tier (docs.anthropic.com, 2026) — it drops into layer zero. The model weights change, the context window (the maximum number of tokens the model can process in one call) may change (the Opus 4.6 and Sonnet 4.6 models both expose a 1M-token context window at standard pricing), and the per-token price may change. But the layers above do not care which weights are running. They only care that something takes tokens and returns tokens.

Layer 0 — MODEL
┌───────────────────────────────────────────────┐
│  tokens in → [transformer weights] → tokens out │
│                                                 │
│  Examples (June 2026):                          │
│    claude-opus-4-8       1M ctx  highest capability │
│    claude-sonnet-4-6     1M ctx  balanced           │
│    claude-fable-5        GA      next tier          │
└───────────────────────────────────────────────┘

Anchoring here first is important: everything above is machinery built on top of token prediction, not a different kind of intelligence. Once you see that, the rest of the stack becomes obvious.

Layer 1 — The Protocol

Layer 1 is messages.create — the HTTP API call that turns “tokens in, tokens out” into a structured conversation. The Messages API gives you a vocabulary: system prompt, user and assistant turns, tool_use content blocks, tool_result content blocks. Without the model below it, the protocol has nothing to wrap. Without the protocol, you are typing directly at raw weights — which you cannot do.

The single most important field the protocol exposes is stop_reason. It tells you why the model stopped generating. There are six values in current production (docs.anthropic.com, 2026):

stop_reason: "tool_use" is the hinge that makes agentic loops possible. Every multi-step agent you have ever seen is a while stop_reason == "tool_use" loop. If you do not understand this field, you do not understand agents — which is why understanding stop_reason has its own episode in this series.

POST /v1/messages
{
  "model": "claude-opus-4-8-20260528",
  "max_tokens": 8192,
  "system": "You are ...",
  "messages": [{ "role": "user", "content": "..." }],
  "tools": [...]
}

Response:
{
  "stop_reason": "tool_use",   ← the hinge
  "content": [{ "type": "tool_use", "name": "read_file", ... }]
}

Layer 2 — Reach (Tools and MCP)

Layer 2 is how the model touches the outside world. It encompasses tool definitions, tool calls, tool results, and the Model Context Protocol (MCP) — the open standard that lets any server expose tools, resources, and prompts to any MCP-compatible client.

Without layer 1 below it, there is no way to even describe tools to the model. Tools arrive in the tools array of the API request; the model emits a tool_use block; your code executes the function and returns a tool_result. MCP standardises that surface at scale. As of late 2025, Anthropic donated MCP to the Agentic AI Foundation under the Linux Foundation (modelcontextprotocol.io, 2025). The ecosystem now has 500-plus public servers and over 97 million monthly SDK downloads across TypeScript, Python, C#, Java, and Swift. The current stable spec is 2025-11-25, with a 2026-07-28 release candidate adding a stateless HTTP core and a Tasks extension.

Layer 2 — REACH
┌───────────────────────────────────────┐
│  Tool definitions (tools[] in request) │
│  Tool calls     (tool_use in response) │
│  Tool results   (tool_result in turn)  │
│                                        │
│  MCP = the USB-C for AI tools          │
│    Local process MCP servers           │
│    Remote HTTP MCP servers (2025+)     │
└───────────────────────────────────────┘
        │
        │ rests on
        ▼
    Layer 1 (Protocol)

A new tool type, a new MCP server, a new API integration — all land here. Same plug, same socket. No layer above or below needs to change.

Layer 3 — Orchestration

Layer 3 turns a single API call into an agent. The minimal agentic loop is just: check stop_reason, execute the requested tool, feed the result back as a new tool_result turn, call messages.create again, repeat. That loop is orchestration.

Layer 3 also covers:

• Sub-agents: spawning one Claude instance to delegate work to another, each with its own isolated context window. Useful for parallelisation and for keeping total token cost manageable (Claude Agent SDK, 2025).
• Memory: injecting prior context — retrieved facts, summarised history — into the system prompt or early turns so the model “remembers” across sessions.
• Hooks: callback functions that fire at fixed lifecycle points — PreToolUse, PostToolUse, Stop, SessionStart, SessionEnd. Hooks are what separate a demo from something you can run unattended. They are how you gate irreversible actions, enforce audit logs, and implement human-in-the-loop escalation.

Without reach (layer 2), the loop has no actions to choose between. It is just a text box you keep resubmitting.

Layer 4 — Surfaces

Layer 4 is the shapes you actually touch. Three surfaces ship today:

1. Claude Code — the CLI-native coding agent. It exposes the agentic loop as a terminal REPL, adds a skills/plugins system, hooks config via CLAUDE.md, and runs headlessly in CI/CD (Anthropic engineering blog, 2026).
2. Claude Agent SDK (renamed from Claude Code SDK in September 2025) — the programmatic library (claude-agent-sdk on npm and PyPI) for building your own agents using the same harness that powers Claude Code. It manages orchestration for you; you supply reach configuration and system prompts.
3. Managed Agents — Anthropic-hosted agents where Anthropic manages uptime, scaling, and the orchestration loop. You configure intent; the infrastructure runs.

A surface is an opinionated wrapper around orchestration. It makes choices about UI, interruption points, and output formatting so you do not have to. New surfaces land here; the layers below remain untouched.

Layer 4 — SURFACES
┌────────────────────────────────────────────────┐
│  Claude Code         CLI agent, skills, hooks  │
│  Claude Agent SDK    programmatic agent harness │
│  Managed Agents      hosted, Anthropic-run      │
└────────────────────────────────────────────────┘
        │ rests on
Layer 3 — ORCHESTRATION (loop, sub-agents, memory, hooks)
        │ rests on
Layer 2 — REACH (tools, MCP)
        │ rests on
Layer 1 — PROTOCOL (messages.create, stop_reason)
        │ rests on
Layer 0 — MODEL (tokens in → tokens out)

The Two Cross-Cutting Planes

Behind all five layers sit two planes. They are not layers — they have no specific position in the stack. They influence every layer simultaneously.

Plane 1 — Prompts and Structured Output. System prompts, user-turn formatting, few-shot examples, context stuffing, JSON mode. The way you frame language shapes model behavior at layer zero and propagates through every layer above. A poorly written system prompt degrades agent reliability at layer three even if the orchestration logic is perfect. This plane is covered in depth in the prompts episodes of this series.

Plane 2 — Context, Reliability, and Cost. Token budgets, prompt caching (cache writes at 1.25x the input rate, reads at 0.1x — a 90% discount — with 5-minute or 1-hour TTL; up to four cache_control markers per request; workspace-level cache isolation as of February 2026), retry logic, error handling, eval design, and human-in-the-loop routing. These concerns matter equally at layer 1 (a one-shot call) and at layer 3 (a 50-step agent).

How the Stack Absorbs Change

The payoff of this model is that it absorbs every new Claude announcement gracefully.

Read a release note, ask “where does this go?” — the stack gives you the answer in under five seconds. That is the entire point of building this mental model.

How to Apply This Right Now

Concrete steps you can take with the stack today:

Debugging an agent that loops unexpectedly. Start at layer 1. Log every stop_reason. If you see tool_use when you expected end_turn, the model is requesting a tool that was not properly resolved — a layer 2 issue. If you see max_tokens, you are hitting a layer 0 / plane 2 constraint; increase max_tokens or prune context.

Reducing API cost on a long-running agent. Reach for plane 2. Add cache_control: { type: "ephemeral" } to your system prompt and static tool definitions. On a production agent calling the same 5K-token system prompt thousands of times, cache reads at 0.1x versus writes at 1.25x represent a dramatically lower steady-state cost (docs.anthropic.com/prompt-caching, 2026).

Choosing between Claude Code, Agent SDK, and Managed Agents. You are choosing at layer 4. If you need a terminal coding agent out of the box, use Claude Code. If you need to build a custom agent with your own tools and business logic, use the Agent SDK. If you need Anthropic to host and scale it for you, use Managed Agents. The layers below are identical in all three cases.

Adding a new data source to an existing agent. That is a layer 2 change. Wrap the data source in a tool or MCP server, register it in your tools array or MCP config, and the orchestration and surface layers carry on unchanged.

Common Misconceptions

“The layers are independent — I can skip the ones I do not need.” No. Each layer depends on the one below it. You cannot use orchestration without reach, reach without the protocol, or the protocol without a model. Skipping a layer does not simplify your system; it just means you are implicitly depending on it without knowing it.

“MCP replaces the Messages API protocol layer.” MCP lives at reach (layer 2). It standardises how tools are described and invoked across clients and servers. The underlying messages.create API at layer 1 is still the mechanism by which the model learns about those tools; MCP does not replace it.

“Surfaces like Claude Code are completely separate products from the raw API.” They are layer-4 wrappers around the same stack. When you understand layers 0 through 3, you understand what Claude Code is doing — which means you can extend it with hooks and skills, debug its behavior, and predict what will change when a new model ships.

“Prompts are a layer 1 concern.” Prompts are a cross-cutting plane. A vague or contradictory system prompt degrades model behavior at layer zero, makes tool descriptions harder to follow at layer 2, and causes the agentic loop at layer 3 to oscillate. The prompts plane touches every layer simultaneously.

Frequently Asked Questions

Where does RAG (retrieval-augmented generation) fit in the stack? RAG is primarily a layer 2 concern — you are calling a retrieval tool or MCP server to fetch documents. But the retrieved chunks land in the context window (a layer 0 constraint) and must be formatted carefully (a prompts plane concern). Caching a stable knowledge base with cache_control is a plane 2 optimization. RAG touches three parts of the stack at once, which is exactly why it can go wrong in three different ways.

If I am building with the Claude Agent SDK, which layers am I working at? The Agent SDK is a surface (layer 4) that manages orchestration (layer 3) for you. You are still responsible for reach configuration (layer 2 — which tools and MCP servers to register), the prompts plane (system prompts for each agent), and cost/reliability decisions (plane 2 — caching strategy, token budgets, retry logic).

Does a multi-agent system change the stack structure? No — it multiplies it. Each sub-agent is its own stack instance with its own context window. The orchestrator at layer 3 coordinates between stacks, but each individual Claude call still follows the same model → protocol → reach → orchestration path. Sub-agents are useful precisely because they provide context isolation: only the relevant result comes back to the orchestrator, not the sub-agent’s full working context.

When Anthropic ships a new Claude model, do I need to change my orchestration code? Typically no. Layer 0 absorbs the new model; layers 1 through 4 are model-agnostic by design. You may want to update system prompts (prompts plane) to take advantage of new capabilities, and you should check for context-window or pricing differences (plane 2). Structurally the stack holds. The model ID in your config changes; nothing else has to.

What is the pause_turn stop_reason, and when does it appear? pause_turn appears when a server-side sampling loop (used with certain managed tool configurations) reaches its iteration limit before the agent has finished its task. It signals that the current turn was paused, not completed — you should inspect the partial output and decide whether to resume or escalate. It is a layer 1 signal, but it tells you something important about layer 3 loop design: long-horizon tasks need explicit iteration budgets.

Is MCP still controlled by Anthropic? No. As of December 2025, Anthropic donated MCP to the Agentic AI Foundation (AAIF) under the Linux Foundation. OpenAI, Block, AWS, Google, Microsoft, and others joined as founding members (modelcontextprotocol.io, 2025). MCP is now a vendor-neutral open standard, which is why it has become the de facto integration layer for multi-tool agents across the industry.

Where This Fits in the Series

This recap is the finale of How Claude Actually Works. If you are reading this before watching the series, start at the very bottom: The Claude Stack Mental Model introduces the full picture, and How LLM Tokens Work grounds layer zero before anything else. For the protocol layer, Understanding Stop Reason is the essential deep-dive. For reach, What Is MCP covers the protocol end-to-end. For orchestration, How Claude Code Works and Claude Code Hooks Explained go deep on the loop and lifecycle boundaries. Browse all tutorials to follow the complete series.