Claude's 5-Layer Stack: MCP, Hooks, Skills, and Subagents Explained

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

▶ Watch on YouTube & subscribe to The Stack Underflow

Anthropic ships something new every few weeks — a new transport for MCP, a hook lifecycle event, a plugin format, an Agent SDK rename — and each release triggers the same cycle: excited thread, a dozen confused replies, nobody agreeing on whether they need it. The confusion is structural. There is no shared map.

This tutorial gives you that map. Five horizontal layers and two vertical planes account for every feature Anthropic has shipped or is likely to ship. Once you have the grid in your head, placing any new release takes about five seconds: which layer, which plane, what does it depend on. That filter is the whole game.

The one-sentence version: Claude’s feature surface organizes into five layers (tokens → API call → tools → agent loop → installed products) and two cross-cutting planes (prompts, cost/reliability), and knowing which slot a feature occupies tells you exactly what it needs and whether you need it at all.

The Five Layers at a Glance

L4  Claude Code · Agent SDK · Managed Agents · Plugins
L3  Agent loop · Hooks · Subagents · Sessions · Memory
L2  Tool choice · Input schema · MCP · Transports
L1  messages.create · stop_reason · Streaming · max_tokens
L0  Tokens · Context window · Extended thinking · Tokenizer

Each layer depends on the one below it and adds exactly one new capability. The model lives at L0. A single API call is L1. Handing the model tools is L2. Looping that call into an agent is L3. Packaging the whole thing for humans and teams is L4. Nothing at a higher layer can exist without the layers below — and that dependency chain is what makes the filter useful.

L0 — The Model Substrate

L0 is facts about the model itself. Nothing here knows about tools, loops, or installed products.

Tokens are the unit the model processes. Your text is broken into tokens by the tokenizer before the model ever sees it — the model does not read characters or words, it reads integers representing subword chunks. The context window is how many tokens the model can hold in attention at once. As of mid-2026, the Claude Sonnet 4.x family ships with a 1 million token context window (docs.anthropic.com, 2026). Extended thinking — also called effort or budget tokens — lets the model spend additional tokens reasoning before producing a visible response; this is an L0 capability because it is purely about how the model processes, not about what it can reach.

If a feature is purely about what the model is or how it processes text, it lives at L0.

L1 — The Single API Call

L1 is one HTTP request, one response. The entry point is messages.create, which is the Anthropic Messages API endpoint that every Claude integration eventually resolves to.

The stop_reason field is more important than it looks. As of the current API spec (docs.anthropic.com, 2025-2026), the values are:

tool_use is the hinge between L1 and L3. When you see it, the agent loop at L3 is supposed to pick up and keep going. Nothing at L1 does that automatically — L1 is passive.

L2 — Reaching the World (Tools)

L2 is where the model gets hands. Three concepts live here.

Tool choice controls when the model is allowed to call a tool: auto lets it decide, required forces a call, none blocks all tool calls, and a specific tool name forces exactly that tool. Input schema describes the shape of each tool call in JSON Schema so the model knows what arguments are valid and can construct well-formed calls.

MCP (Model Context Protocol) is the standardized open protocol by which external services expose themselves as tools (modelcontextprotocol.io, 2025). MCP is not a layer on its own — it is a feature at L2. It sits on top of the raw tool-call machinery defined at L1 and standardizes the handshake so you do not have to describe every external tool from scratch.

The transports are how MCP connections physically run:

stdio transport      — server runs as a local child process
                       stdin/stdout carry the JSON-RPC messages
                       best for: local dev tools, CLI helpers

Streamable HTTP      — server runs as an independent HTTP service
                       POST for client→server, optional SSE for server→client
                       best for: remote servers, production multi-client deployments

The MCP spec released its March 2026 version with Streamable HTTP as the canonical remote transport, replacing the earlier SSE-only approach (spec.modelcontextprotocol.io, 2025-03-26). A next specification release is in progress as of mid-2026, targeting a stateless core that scales on ordinary HTTP infrastructure (blog.modelcontextprotocol.io, 2026).

L3 — Turning Calls into Behavior (The Agent Loop)

A single tool call is L2. The agent loop is what transforms that call into work that spans multiple steps: read stop_reason, if tool_use then execute the tool and feed the result back, call messages.create again, repeat until end_turn. That loop is entirely in your code (or in the Agent SDK) — the model itself does not loop. Understanding this is critical: the model is stateless. The loop is yours.

while True:
    response = messages.create(...)
    if response.stop_reason == "end_turn":
        break
    if response.stop_reason == "tool_use":
        result = execute_tool(response.tool_call)
        messages.append(tool_result(result))
    # other stop_reasons: handle or raise

Key features at L3:

Hooks are callbacks that fire at lifecycle events in the agent loop. Claude Code exposes PreToolUse, PostToolUse, Stop, and others (docs.anthropic.com/en/docs/claude-code/sub-agents, 2025-2026). Hooks let you intercept, log, validate, or block what happens at each step without touching the core loop. A PreToolUse hook can examine a tool call before it executes and block it if it violates a policy — this is your gating layer for irreversible actions.

Subagents solve the context window pollution problem. When a task is large enough that all its tool-call noise — file reads, search results, intermediate outputs — would fill the parent’s context window before the task is done, you spawn a subagent. A subagent is a fresh messages.create call with its own context window. The parent delegates a bounded task, the subagent runs independently, and only the result comes back. The Claude Agent SDK (anthropic.com, 2026) supports subagents natively, including parallel subagent spawning for independent workstreams.

Sessions persist state across turns within a conversation. Memory carries information across sessions entirely — across conversations.

L4 — The Things You Actually Install or Open

L4 is L0-L3 packaged for humans and teams.

Claude Code is the terminal agent most developers encounter first. It runs an L3 agent loop under the hood, connects to MCP servers at L2, and reads your CLAUDE.md file — a project-level config file that lives in your repository and tells Claude Code about the project context, constraints, and conventions. CLAUDE.md is an L4 artifact; it does not appear anywhere in the raw API.

The Claude Agent SDK (formerly the Claude Code SDK, renamed in late 2025 to reflect its broader applicability — anthropic.com, 2026) is the library for building L3 agent loops programmatically. Apple’s Xcode integration, third-party IDEs, and custom enterprise tooling are all built on it. It ships the same core tools, context management, and permissions framework that powers Claude Code itself.

Managed Agents are Anthropic-hosted agent infrastructure — you describe the task, Anthropic handles the runtime. Plugins are installable bundles that can contain skills, hooks, and MCP servers together in one unit (anthropic.com/news/claude-code-plugins, 2026). Installing a plugin wires up all three at once.

L4: Claude Code / Agent SDK / Managed Agents / Plugins
     │
     └── each is L0–L3 packaged differently
         Claude Code    → interactive terminal, reads CLAUDE.md
         Agent SDK      → programmatic, you own the loop
         Managed Agents → Anthropic-hosted runtime
         Plugins        → bundled skills + hooks + MCP servers

The Two Cross-Cutting Planes

Some features are not a layer — they cut vertically across all of them.

The Prompts Plane contains techniques that affect how the model behaves at any layer above L0.

• Few-shot examples shape the model’s output format, tone, and reasoning pattern. They’re not a layer; they’re a pattern applied anywhere in the message array.
• JSON schema enforcement via a fake tool call forces structured output by using the tool-call mechanism as an output formatter. The model fills in a tool-call JSON shape instead of writing free text. It sits across L1 and L2 simultaneously — technically a tool call (L2), but used purely to control output shape (prompting concern).

The Cost and Reliability Plane contains features whose primary job is economic or operational.

• Prompt caching avoids re-encoding the same prefix on every API call. You mark a prefix with a cache_control block; Anthropic stores it for a TTL (5 minutes by default, 1 hour at additional cost) and charges a reduced rate on cache hits — up to 90% cost reduction on long prompts (docs.anthropic.com/en/docs/build-with-claude/prompt-caching, 2025). It operates at L1 (the API call) but its purpose is cross-cutting.
• Compaction (also called context summarization) summarizes long histories to keep them fitting inside the context window. It is an L3 concern operationally — it fires during the agent loop — but its purpose is cost and window management.
• Evals measure whether any of this is actually working. Evals are not a product feature; they’re the feedback loop behind every layer.

Cost & Reliability Plane    |   Prompts Plane
caching · compaction · evals|   few-shot · schema enforcement
                            |
cuts vertically across L0–L4, not a layer itself

Skills: A Feature in Two Places

Skills are the one feature that deliberately lives at two layers. At L4 they ship as an open-standard folder format (anthropic.com/engineering, 2026) — organized folders of instructions, scripts, and resources that Claude Code (or any compatible agent) can discover and load dynamically. At L3 they are callable units of behavior accessible programmatically via the Agent SDK. Same feature, two valid homes. The rule: name both, pick the one that matches your deployment context.

Applying the Filter: Three Questions for Every New Release

The practical payoff of having this map is a decision filter. Next time something ships and your feed lights up:

1. Which layer? Place the feature on the grid — is it about the model itself (L0), a single API call (L1), tool access (L2), loop behavior (L3), or a packaged product (L4)?
2. Which plane? Does it affect cost and reliability, or prompting behavior? If so, it’s a cross-cutting concern, not a new layer.
3. Dependency check? What does it depend on that you’re already using? If it depends on L3 and you’re running L1 calls only, you probably don’t need it yet.

If the answer to question 3 is “nothing I have,” you can safely park it. The stack is a filter before it’s a feature list.

Common Misconceptions

• “MCP is its own layer.” MCP is a protocol feature at L2. It standardizes how tools expose themselves to the model — it does not add a new abstraction layer above the tool-call mechanism. When someone says “we use MCP,” they mean their L2 tool definitions follow the open spec rather than being ad-hoc.
• “Hooks are part of the model.” Hooks live at L3, in the agent loop runtime. The model itself at L0 has no concept of hooks; they are lifecycle callbacks in the orchestration code wrapped around the model. The model never sees a hook fire.
• “CLAUDE.md is an API feature.” CLAUDE.md is an L4 artifact — Claude Code’s project-level config file. It does not appear anywhere in the raw Messages API. If you are calling messages.create directly, CLAUDE.md does nothing.
• “Skills and plugins are the same thing.” Plugins are installable bundles at L4 that can contain skills, hooks, and MCP servers. Skills are callable units of behavior that can surface at L3 (programmatic, via Agent SDK) or L4 (Claude Code). A plugin may include skills, but they are not synonyms — a skill is a capability unit, a plugin is a deployment package.

Frequently Asked Questions

Where does prompt caching fit — is it an L1 feature? It’s in the cost and reliability plane, not a strict layer. Prompt caching operates by marking a prefix in the API request at L1, but its purpose is economic and it applies across your entire stack. Think of it as a vertical slice: the mechanism is at L1, but the concern is cross-cutting. The dedicated tutorial Prompt Caching: Cut Your AI Bill covers the implementation details.

If subagents get their own context window, are they separate API calls? Yes, exactly. Spawning a subagent means issuing a fresh messages.create call with its own context. The parent agent delegates a bounded task, the subagent runs its own L3 loop independently, and only the final result comes back to the parent. The isolation is the point — it prevents the subagent’s tool-call noise from filling the parent’s window and degrading reasoning quality.

Do I need to understand all five layers to use Claude Code? No. Claude Code at L4 packages the layers below so you can use it without thinking about them. But when something breaks — a tool call misbehaves, a hook fires unexpectedly, memory does not persist, a subagent keeps failing — knowing which layer is involved cuts your debugging time dramatically. The stack is most useful as a diagnostic tool.

Is the Agent SDK the same as the Claude Code SDK? They are the same thing under different names. Anthropic renamed the Claude Code SDK to the Agent SDK to better reflect that it is a general-purpose library for building agents at L3, not just a companion to the Claude Code terminal product. The rename happened in late 2025. If you see older tutorials referencing the “Claude Code SDK,” they are describing the same library.

What is server_sampling_loop_limit and when do I see it? This stop_reason appears when a server-side sampling loop — for example, one involving the server-hosted web search or web fetch tools — hits its iteration ceiling (default 10 per request). It is an L1 signal that the server-side loop exhausted itself before end_turn. Your agent at L3 should treat it like a soft failure and decide whether to retry with adjusted parameters or surface an error to the user.

Where do evals belong on the stack? Evals are in the cost and reliability plane, not any layer. They are the feedback loop that tells you whether everything else is working — they touch L0 (is the model reasoning correctly?), L1 (are stop reasons what you expect?), L2 (are tool calls well-formed?), and L3 (does the agent actually complete tasks?). The dedicated tutorial How to Write LLM Evals covers the mechanics.

Where This Fits in the Series

This tutorial is the orientation map for the “How Claude Actually Works” series. Every episode that follows descends into one of these layers in detail. If you have not yet read the foundational mental model, start with The Claude Stack Mental Model — it establishes the “why” behind the layering. From here the series goes deeper in two directions: downward into L0 with How LLM Tokens Work and Your AI Bill and How the Context Window Works, and outward into tools and agents with What Is MCP: Model Context Protocol and How Claude Code Works: The Agent Loop. Browse all tutorials to follow the full course in order.