Claude Agent Framework: Which Layer of the Stack Do You Need?

Search for a Claude agent framework and you get a mix of GitHub projects, wrapper libraries, and official docs that all describe different layers of the same thing. The confusion is understandable, because Anthropic does not ship one framework. It ships a stack, and each layer answers a different question about how much of the agent loop you want to own. This page maps the layers, what each one provides, and the part no layer provides at all.

What Counts as the Claude Agent Framework?

Four first-party layers plus one protocol make up the stack. Each layer up trades flexibility for infrastructure you no longer have to build.

Layer	What it is	You own	Best fit
Claude API + tool use	Messages endpoint with tool calling	The whole loop	Custom harnesses, maximum control
Claude Agent SDK	The official agent harness	Task logic, tools	Production agents you host yourself
Claude Code	Packaged coding agent	Config and skills	Software engineering work
Managed Agents	Hosted runtime, Anthropic runs the loop	Agent config	Long-running sessions without infra
MCP	Open tool and context protocol	Tool servers	Integrations reused at every layer

The bottom layer is the Messages API with tool use, where your code calls the model, executes the tools it requests, and loops until done. Everything above it is packaging around that same loop, which is worth internalizing, because it means the claude agent framework question is never “which technology” but “who runs the loop.” At the bottom you do. In the middle the SDK does, on your machines. At the top Anthropic does, on theirs.

How Do You Choose a Layer?

Working through a few concrete cases settles the choice faster than feature tables. A team building a support agent that must live inside an existing backend, with custom approval gates before any customer-visible action, belongs on the API with tool use, because the approval logic is the loop and no harness should own it. A team building an internal research agent that reads files, calls APIs, and writes reports belongs on the Agent SDK, which provides the loop, the subagents, and the context management that team would otherwise spend a quarter rebuilding. A team that wants agents working through engineering backlogs adopts Claude Code directly and spends its effort on skills and configuration. And a team shipping a long-running agent product without an infrastructure budget starts with Managed Agents and revisits when its needs harden.

Two rules of thumb generalize the cases. Drop down a layer when your control requirements outgrow the packaging. Move up a layer when you notice the harness, not the agent, is where your engineering time goes. And revisit the choice as the product hardens, because starting on Managed Agents and graduating to the SDK once you have infrastructure opinions is a cheaper path than building the harness first and discovering you never needed to own it.

What Does the Claude Agent SDK Give You?

The Agent SDK is the layer most teams building claude agentic ai systems actually want, and Anthropic’s engineering write-up is explicit about its design principle: give the agent a computer. Instead of a chat loop with function calls bolted on, the SDK hands the agent a file system, a terminal, and code execution, so it can work the way a person at a keyboard does.

The loop it implements runs gather context, take action, verify work, then repeat. Around that loop the SDK provides the pieces that are tedious to build well: agentic search over files, subagents for parallel work with isolated context, compaction so long sessions survive the context window, tool definitions, and MCP servers as a first-class tool source. It is the same infrastructure that runs Claude Code, which is a useful signal, because the harness you inherit is one that carries production traffic. The anthropic agent sdk docs cover the bindings, and the same loop concepts transfer to whatever language you run.

The verify stage deserves the emphasis Anthropic gives it. The write-up treats verification as a first-class loop step with three concrete mechanisms: rules the output must satisfy, visual feedback where the agent inspects what it produced, and LLM as a judge for qualities no rule can check. That framing is unusual candor for framework documentation, since it concedes that a claude agent framework can guarantee the loop runs but not that the loop converges on correct work. The teams that thrive on the SDK are the ones that build that verify stage out rather than treating it as optional.

Where Do Claude Code and Managed Agents Fit?

Claude Code sits one layer up, a finished agent rather than a framework. You configure it with skills, subagents, and MCP servers rather than writing a harness, and the claude code docs cover that surface. Teams often meet the stack here first, then drop down to the SDK when they need an agent that is not a coding assistant.

Managed Agents goes the other direction and removes your infrastructure entirely. You define a versioned agent configuration, and Anthropic runs the loop and hosts a sandboxed workspace per session, streaming events back to your application. It fits long-running, stateful agents where you would rather not operate containers, at the cost of running your tools inside someone else’s runtime.

Versioning is the underrated part of that layer. Agent configurations are persisted objects, sessions pin to a version, and updates create new immutable versions rather than mutating the running agent. Anyone who has hot-patched a system prompt in production and broken every in-flight conversation will recognize what that design is for, and it previews a theme that runs through the whole claude agent framework stack: the higher layers encode operational lessons the lower layers leave you to learn yourself.

What About Third-Party Frameworks?

The ecosystem wraps the stack rather than replacing it. Microsoft’s Agent Framework documents direct integration with the Claude Agent SDK, positioning a Claude agent as one building block in a provider-mixed multi-agent system. General-purpose frameworks treat Claude as a model provider behind their own abstractions, and community projects on GitHub layer opinionated harnesses over Claude Code.

The honest trade is uniform across all of them. A wrapper buys portability across providers and costs you a layer of indirection over the surface where new API features appear first. If your agents are Claude-first, the first-party SDK is the shorter path. If you are orchestrating agents across several providers, a wrapper earns its keep.

One caution applies specifically to the community projects that rank for claude agent framework searches. Many are excellent, but they are opinionated harnesses maintained at repository speed, and the official stack underneath them moves quickly. Before adopting one, check whether what it adds is configuration you could express in Claude Code’s own skills and subagents, because the first-party surface has absorbed several waves of community innovation already, and a thin wrapper abandoned by its maintainer is a worse position than either layer it sits between.

Where the Framework Stops: Proving the Agent Works

Every layer of the stack gives you a better loop. No layer tells you whether the agent built on it actually works, and Anthropic’s own SDK guide is candid about this, closing on verification approaches like rules, visual feedback, and LLM as a judge rather than declaring the problem solved by the harness.

The field data says this is where the pain concentrates. In Mutagent’s community-research corpus, the two failures builders report most often are agents that get stuck in loops or hangs and hallucinations that nobody catches. Both happen on every claude agent framework layer alike, because they are properties of autonomous execution, not of any harness. What fixes them is the discipline around the loop: tracing every run, designing orchestration with termination guarantees, and choosing an architecture that contains failures instead of spreading them.

The practical takeaway is a division of labor. Let the stack own the loop, the tools, and the runtime, since those are solved problems you should not rebuild. Keep for yourself the three things no layer ships: the eval set that defines what correct means for your task, the traces that make failures diagnosable, and the regression gate that decides whether a change to the agent actually improved it.

One naming note keeps the current model surface unambiguous, because it moves faster than most docs. When you configure any layer of the claude agent framework, the model identifiers are the plain family names, and the most capable models today are Claude Opus 4.8 and the Claude Fable 5 tier above it, with Sonnet and Haiku filling the faster and cheaper slots. Pin an explicit model in your agent configuration rather than relying on a default, so a platform-side default change never silently shifts the model your evals were calibrated against.

Mutagent builds on this stack ourselves, and our production agents run on Claude Code and the Agent SDK. The agent lineup covers the layer the framework leaves open: evals, diagnostics, and regression gates for the agents you ship.