Claude Agent Explained: Claude Code, Agent SDK, Subagents & Managed Agents

Key Takeaways

• Claude Agent is best understood as a family of agentic Claude workflows, not one interchangeable Anthropic product.
• Claude Code is the ready-to-use agent surface; the Claude Agent SDK embeds the same agent loop in Python or TypeScript.
• Claude Managed Agents shifts the agent harness and session infrastructure to Anthropic, reducing runtime operations while preserving tool and permission controls.
• Permissions, verification, and task design matter as much as model capability because agents can read data, run tools, and make external changes.

“Claude agent” is a useful search term, but the current Anthropic product stack is more specific. Claude Code is an interactive agent for delegated work, the Claude Agent SDK packages the same agent loop for custom Python or TypeScript applications, and Claude Managed Agents hosts the agent harness for longer-running production workflows. Subagents, Skills, MCP connections, and hooks then extend those core execution paths rather than replacing them.

The category lines become clearer when the software stack is separated by responsibility.

Claude agent systems combine a Claude model, an agent loop, context management, tools, permissions, and an execution runtime to pursue multi-step goals. Anthropic currently exposes three primary execution paths: Claude Code for direct interactive work, Claude Agent SDK for developer-operated processes, and Claude Managed Agents for Anthropic-hosted agent infrastructure.

That distinction matters because the same model can feel very different depending on who owns the loop, tools, runtime, and approval boundaries.

What Is a Claude Agent?

A Claude agent is an application or workflow that lets Claude plan steps and call tools until a task reaches a defined stopping point. Anthropic’s current official Agent SDK overview describes an agent as an application that plans its own steps and calls tools such as file readers, command runners, and code editors. The defining feature is therefore not a special “agent model”; it is the execution loop around Claude.

The simplest definition: Claude with a goal, tools, and an execution loop

The simplest mental model is goal + context + tools + feedback. A user gives the system an outcome, Claude gathers the information needed to work, chooses an action, calls an allowed tool, observes the result, and decides whether another step is necessary. A one-shot chatbot usually stops after producing an answer; an agent can continue because tool results become new context for the next decision.

The “agent” label describes behavior more than interface. The same underlying loop can appear in a terminal, a developer library, a hosted service, or a product that exposes only a narrow task-specific UI. A coding agent may inspect a repository and run tests, while a research agent may search sources and update a report. Both rely on repeated model decisions connected to tools and verification.

Why “Claude Agent” does not refer to one interchangeable product

Anthropic separates the Claude agent stack into several products because each places operational responsibility in a different place. Claude Code is designed for direct use. The Agent SDK is designed for builders who want the Claude Code agent loop inside an application they operate. Managed Agents is designed for teams that want Anthropic to host more of the harness and runtime. Anthropic’s Agent SDK branding guidance also permits SDK-powered partner integrations to label an option “Claude Agent,” which explains why the phrase appears in more than one context.

Search intent therefore matters before implementation begins. A developer asking how to “build a Claude agent” is usually looking for the Agent SDK or direct API architecture. A developer asking Claude to fix a repository may simply need Claude Code. A platform team asking how to run thousands of durable agent sessions is closer to the Managed Agents problem. Treating those as the same product leads to avoidable complexity.

Claude agent vs ordinary Claude chat

The practical boundary is whether the system can take and verify actions, not whether Claude can reason well. Ordinary chat can explain a bug, draft a plan, or summarize pasted material. An agentic setup can read the relevant files, edit them, run a test suite, inspect failures, and repeat. Tool access, persistent context, permission policy, and verification convert model output into an execution workflow.

Claude Agent Types: The Main Anthropic Agent Surfaces

Four surfaces account for most “Claude agent” questions in 2026. Claude Code, Claude Agent SDK, Claude Managed Agents, and Claude Code subagents overlap in capability but solve different operational problems. The comparison below separates interface, runtime ownership, and best-fit use case rather than treating every feature as a standalone product.

The main distinction is operational ownership. Claude Code gives users the agent experience directly, Agent SDK gives developers the loop to embed, Managed Agents gives production teams a hosted harness, and subagents give a parent Claude workflow additional isolated workers. The same organization may use more than one surface because interactive development, embedded applications, and hosted production sessions have different requirements.

Claude Code vs Claude Agent SDK vs Managed Agents

Claude Code, Agent SDK, and Managed Agents should be chosen by who needs to operate the agent rather than by feature count. All three can involve Claude, tools, context, and multi-step execution. The meaningful differences are interface, hosting, session durability, security boundary, and how much infrastructure the team wants to own.

Claude Code: use the agent directly

Claude Code is the shortest path when the user wants Claude to work on technical tasks directly. It is an agentic coding product available across terminal and other supported interfaces, with built-in capabilities for reading code, editing files, running commands, and working through multi-step changes. The user steers and reviews the work instead of embedding the agent loop inside another application.

Claude Code also makes sense beyond a single command because the product carries the orchestration layer for the user. Repository exploration, debugging, migrations, implementation, and verification can stay inside one interactive workflow. Developers still need appropriate permissions and review, but they do not need to implement the core tool loop before assigning useful work.

Claude Agent SDK: put the agent loop inside an application

Claude Agent SDK is the right layer when a team wants to build its own product or workflow around the Claude Code agent loop. The SDK exposes built-in tools, hooks, sessions, permissions, subagents, Skills, and MCP support to Python and TypeScript applications. The developer operates the process, decides what tools exist, and owns deployment choices around the agent.

Agent SDK reduces orchestration boilerplate without removing product responsibility. A team does not need to recreate the entire gather-context, tool-call, observe, and repeat loop, but it still needs to decide which tasks are appropriate, how permissions work, where secrets live, what users can authorize, how output is verified, and how sessions behave in production.

Managed Agents: let Anthropic host the agent harness

Claude Managed Agents moves more infrastructure responsibility to Anthropic. Anthropic describes the service as a hosted way to run long-horizon agents through durable interfaces for sessions, the agent harness, and execution sandboxes. The Managed Agents engineering overview explains how Anthropic separated the “brain,” session log, and execution environments so components can fail, scale, or change independently.

Managed Agents is not simply the Agent SDK running on someone else’s server. The hosted architecture changes which layer manages session state, sandbox provisioning, credential exposure, and agent-loop operations. Anthropic’s current platform documentation lists Managed Agents as beta, so production teams should review current availability, data-handling constraints, and service limits before committing a regulated workload.

Which one should you choose?

The best starting point is the surface that leaves the least unnecessary infrastructure in the user’s hands. Claude Code fits direct technical work; Agent SDK fits a custom application that needs the Claude loop inside a developer-controlled process; Managed Agents fits hosted, durable execution where operating the harness is not the product’s differentiator. Direct Messages API calls remain appropriate when a team wants to design and own the loop itself.

The hardware analogy is straightforward: the same engine can sit inside a finished vehicle, a kit for builders, or a managed fleet, but the ownership model changes what the operator must maintain.

Claude Code, Claude Agent SDK, and Claude Managed Agents differ primarily in interface, runtime ownership, and infrastructure responsibility. Claude Code provides an interactive agent surface; Agent SDK embeds the Claude Code agent loop in Python or TypeScript; Managed Agents moves the loop, sessions, and sandbox orchestration into Anthropic-managed infrastructure.

That ownership split is more useful than asking which option is “most agentic,” because the core decision is who must run, secure, observe, and recover the workflow.

How a Claude Agent Works: Tools, Context and the Agent Loop

A Claude agent works by turning tool results into the next decision. Anthropic’s agent design guidance describes a feedback loop in which Claude gathers context, takes an action, verifies the result, and repeats. The loop creates useful autonomy only when each action returns evidence the model can inspect instead of assuming a command succeeded.

Step 1: Gather context

Context gathering determines what the agent can reason about before acting. A coding agent may inspect repository files, logs, tests, and configuration; a research agent may retrieve webpages and documents; an internal agent may query approved databases or SaaS tools. Good context design avoids loading everything at once and lets the agent retrieve only the material needed for the current step.

Step 2: Decide what to do next

Agentic execution differs from a fixed workflow because Claude can choose the next step from the current state. A deterministic script follows a predefined branch. An agent can discover that a test failed for an unexpected reason, inspect the relevant file, revise the plan, and continue. That flexibility is useful when the path is uncertain, but it also makes constraints and observability more important.

Step 3: Call a tool

Tools convert model reasoning into observable operations. Built-in Agent SDK tools can read, write, and edit files, run commands, and search the web; MCP or custom tools can expose other systems. Tool availability and tool approval are separate design questions: an application can expose a capability while still requiring confirmation before consequential calls.

Step 4: Observe and verify

Verification is what prevents a plausible plan from being mistaken for completed work. A file edit should be followed by a test or diff when possible. A database update should be confirmed in the destination system. A generated report should be checked against required fields or source evidence. Agents become more reliable when the environment returns concrete signals that Claude can evaluate.

Step 5: Continue, stop, or ask for approval

A useful agent needs an explicit way to stop and an explicit reason to escalate. Completion can be tied to tests passing, required artifacts existing, an external confirmation arriving, or a bounded number of turns. High-impact actions can require human approval even when earlier read-only or reversible steps run automatically. Autonomy is therefore a permission policy, not a binary feature.

The loop can be summarized as a sequence of evidence-producing decisions rather than a chain of confident guesses.

A Claude agent loop follows a feedback cycle: gather context, choose an action, call an authorized tool, inspect the result, verify progress, and repeat until a completion condition is reached. Reliable execution depends on bounded tools, explicit permission rules, durable context, and independent checks for consequential external actions.

That feedback structure explains why a well-scoped agent can recover from intermediate failures, but it also explains why broad permissions increase the potential impact of a wrong decision.

Subagents, Agent Skills, MCP and Hooks: What Each One Actually Does

Subagents, Skills, MCP, and hooks solve different layers of the agent stack. Subagents divide work, Skills package repeatable know-how, MCP connects external capabilities, and hooks run policy or automation at specific lifecycle events. Combining them can make a workflow more capable, but adding every mechanism to a simple task usually creates more context, more permission surface, and more debugging work.

Subagents execute separate work

A Claude Code subagent is an isolated Claude instance with its own context window that returns a result to the parent workflow. Anthropic’s official Claude subagents guide recommends subagents for research-heavy exploration, independent parallel work, fresh review, and pipeline stages where context isolation creates a real benefit. Different subagents can also receive different tool permissions.

Subagents carry overhead and should not be treated as free parallelism. Each worker needs its own context and consumes additional tokens. Tightly sequential tasks, small fixes, or multiple agents editing the same file can become slower or more error-prone. Anthropic also notes that ordinary subagents return to the main conversation rather than coordinating directly with one another, which limits designs that require peer-to-peer collaboration.

Skills provide reusable know-how

Agent Skills package reusable instructions and optional resources for tasks that should follow a repeatable method. A Skill can define a reporting procedure, validation checklist, template, reference material, or script. Skills do not create a new model and do not silently grant access to tools. The host agent still decides when a Skill is loaded and which actions are actually permitted.

Skills are most useful when the missing ingredient is procedure rather than connectivity. A weekly briefing may need a standard structure and evidence rules; a code-review Skill may define required checks and output sections. Readers who need the file-format and portability details can use the Agent Skills vs MCP guide, which separates reusable instructions from external tool connections.

MCP connects tools and external systems

Model Context Protocol provides a standardized way for AI applications to reach supported tools, data, and resources. MCP is therefore an integration layer, not an agent by itself. An agent can use an MCP server to search a database, call a service, or retrieve a resource, but the agent still needs task instructions, authorization, context, and a policy for deciding when the operation should run.

Skills and MCP often work together because one defines how work should be done and the other exposes what the agent can reach. A Skill may instruct Claude to prepare a meeting brief with four sections; MCP may provide the calendar and document retrieval tools needed to assemble the evidence. Neither layer guarantees a correct result without an agent that applies the procedure and verifies outputs.

Hooks control what happens around tool execution

Hooks add deterministic control points around an otherwise probabilistic agent workflow. A hook can run checks before or after tools, enforce local policies, trigger tests, or block an agent from stopping until a condition is met. Hooks are especially useful when a requirement should execute every time rather than depend on Claude remembering an instruction in a long session.

The Claude agent stack

The clearest architecture separates reasoning, procedure, connectivity, authority, and runtime. Claude provides model reasoning; the agent loop decides and iterates; sessions/context preserve working state; Skills provide reusable procedure; tools and MCP provide actions and data; permissions and hooks constrain execution; the runtime determines where code and tool calls actually run.

This stack prevents category confusion. Adding an MCP server does not create an agent, installing a Skill does not grant tool authority, and spawning a subagent does not automatically improve a tightly coupled task. Each component should exist because it solves a specific limitation in the workflow.

When Should You Use a Claude Agent?

Claude agents are most valuable when the task requires repeated decisions across changing evidence. A useful agent task has more than one step, cannot be fully scripted in advance, benefits from tool access, and has clear ways to verify progress. Research, codebase changes, incident investigation, document production, and multi-system operational work can fit that pattern.

Good agent tasks

• Multi-step investigation: the next action depends on what earlier searches, tests, or files reveal.
• Tool-rich work: the job requires reading, editing, running commands, calling services, or retrieving external data.
• Recoverable execution: the system can detect failures and try a different path instead of stopping after one error.
• Verifiable outcomes: tests, diffs, receipts, records, or structured checks can confirm whether the work actually succeeded.
• Bounded autonomy: low-risk steps can run automatically while consequential actions remain behind approval or policy gates.

Tasks that probably do not need an agent

Simple and deterministic work is often better served by a direct model call or conventional software. Classification, short extraction, fixed-format transformation, one-pass summarization, and predictable API sequences do not automatically benefit from an agent loop. Adding autonomy can increase latency, token use, and failure modes without increasing user value.

More autonomy is not automatically better architecture. A reliable fixed workflow is preferable when the path is known and the expected output can be validated deterministically. Agents earn their complexity when the environment changes, the path must adapt, or several tools need to be coordinated based on intermediate results.

How to Build a Claude Agent: Choose the Simplest Starting Point

The simplest build path should match the amount of control the team actually needs. Starting at the lowest useful layer reduces deployment work and makes failures easier to understand. A team can move downward toward custom orchestration only when the product needs capabilities the higher-level surface does not expose.

Want Claude to do work directly? Start with Claude Code

Claude Code is the default starting point for developers who want to delegate technical work rather than build an agent product. The user can test real tasks, learn which permissions are acceptable, and identify where Claude needs better context before writing any orchestration code. That practical experience often reveals whether a custom agent is necessary at all.

Want an agent inside an application? Use Claude Agent SDK

Claude Agent SDK fits products that need programmable access to Claude Code-style agent behavior. Developers can configure system prompts, tools, permissions, hooks, sessions, MCP servers, and subagents inside Python or TypeScript applications. The surrounding application can stream progress, collect approvals, store product state, and convert agent events into a user interface.

Want Anthropic to operate the runtime? Evaluate Managed Agents

Managed Agents fits teams that want a hosted agent harness rather than another long-running orchestration service to operate. The service can reduce the amount of custom session and sandbox infrastructure required, but beta status, data handling, networking, cost, and approval requirements still need evaluation against the workload. A managed runtime does not remove the need for product-level controls.

Need full orchestration control? Build with the Claude API

Direct Claude API calls remain appropriate when the team wants to own the loop itself. The application can send each model request, execute every tool call, append results, decide when to stop, and design its own state model. That approach offers maximum flexibility, but it also makes the team responsible for orchestration, retries, permissions, observability, and recovery logic that higher-level agent products already provide.

Claude Agent Pricing and Access

Claude Agent does not have one universal price because access depends on the surface and authentication path. Claude Code is included in Anthropic’s paid Claude plans. Agent SDK can use plan-backed authentication in supported cases or API-key billing, and Managed Agents is a Claude Platform service. Teams should therefore compare subscription limits, API credits, model usage, and runtime charges rather than searching for a single “Claude Agent subscription.”

Is Claude Agent free?

The answer is “not as a single product.” Claude’s Free plan does not include Claude Code on Anthropic’s current pricing page, while paid individual and organizational plans include Claude Code with plan-specific usage limits. Agent SDK and Managed Agents can also incur API-related usage, so a free chat account should not be treated as evidence that a deployed agent application is free to run.

Claude Code subscription access

Claude Code currently draws from the usage pool associated with the user’s paid Claude plan when used through plan authentication. Usage is not a fixed number of tasks because long contexts, larger models, tool activity, and task complexity consume capacity differently. The important procurement question is whether the expected workload fits the plan’s limits, not how many simple chat messages the subscription advertises.

Agent SDK and API usage

Anthropic updated Agent SDK plan guidance on October 7, 2026. The Agent SDK plan guidance states that Claude Max, Ultra, and Team plans include monthly API credits covering the Claude API, Claude Managed Agents, Agent SDK, and `claude -p` when an API key from the linked Claude Console organization is used. The same guidance says Agent SDK and `claude -p` continue to draw from subscription limits when the user signs in with the Claude plan.

Authentication therefore changes which pool is charged. A developer testing locally with plan-backed access can experience different accounting from a deployed product using an API key. Production budgeting should separate plan usage from API usage and record the actual model, tool, runtime, and session behavior of the target workload.

Managed Agents billing

Managed Agents adds platform economics on top of model usage rather than replacing token costs with a flat subscription. Anthropic’s pricing is subject to change, and the service remains beta, so teams should verify the current Claude Platform rate card before launch. Long-running sessions, sandbox activity, tool use, and model selection can all affect the effective cost of completed work.

Claude Agent Security, Permissions and Real-World Limits

Agent security is primarily a question of what Claude can reach and what Claude can change. A model that can only read a selected repository has a different risk profile from an agent that can execute shell commands, reach cloud credentials, send messages, or modify production systems. Capability should expand only when the task demonstrates a real need for that authority.

More tools mean a larger permission surface

Every added tool creates another path from model output to a real system. Permissions should distinguish availability from automatic approval and should restrict sensitive operations as narrowly as possible. Read, prepare, and commit are useful layers: an agent may be allowed to inspect data, then draft a change, while a human or policy gate controls the final external action.

Prompt injection matters more when an agent can act

Prompt injection becomes more consequential when untrusted content can steer an agent with powerful tools. A malicious webpage, document, email, tool response, or copied instruction can attempt to redirect the workflow. Model-level resistance helps, but Anthropic’s own security guidance treats model behavior as only one layer; tool restrictions, sandbox boundaries, credential isolation, approvals, and independent verification remain necessary controls.

Subagents can increase context and compute costs

Parallel agents trade additional compute for context isolation and speed on independent work. A research branch, implementation branch, and review branch can be useful when tasks are separable, but each agent carries its own context and token use. Teams should measure whether parallelism shortens the critical path enough to justify the extra cost rather than assuming more agents always mean better throughput.

External actions need independent verification

An agent’s statement that a task is complete is not proof that an external system changed correctly. Code changes need tests and diffs; messages need the correct recipient and sent-state confirmation; deployments need service health checks; financial or administrative actions need destination-system records. The broader personal AI agent safety guide explains why permission scope, approval rules, and independent verification should be evaluated together.

Start with least privilege

Least privilege is the safest default for a new Claude agent workflow. Start with the smallest data scope, the smallest tool set, and reversible actions. Add write access only when read-only testing proves insufficient, and add unattended execution only after the team can observe, pause, and audit the workflow. A successful low-risk pilot is evidence for that task, not blanket authorization for unrelated systems.

Which Claude Agent Should You Use?

The right Claude agent surface follows the user’s task, runtime responsibility, and tolerance for operational complexity. The decision does not require a universal ranking because Claude Code, Agent SDK, Managed Agents, and direct API orchestration occupy different layers. The most efficient choice is usually the highest-level surface that still exposes the control the workflow needs.

Broader agent comparisons become useful only after the Claude-specific architecture is clear. Teams choosing between Claude and other personal or task agents can use a personal AI agent comparison to evaluate action scope, permissions, persistence, cost, and verification across vendors. That is a separate decision from choosing among Claude Code, Agent SDK, and Managed Agents inside Anthropic’s own stack.

Claude Agent FAQ

Is Claude Code a Claude agent?

Yes in the functional sense: Claude Code is an agentic product that uses Claude, tools, context, and iterative execution to complete technical work. Anthropic calls Claude Code an agentic coding tool, while the Agent SDK documentation distinguishes the Claude Code interface from the SDK used to embed its agent loop. “Claude Code” is therefore the product name; “Claude agent” is the broader functional description.

Is Claude Agent SDK the same as Claude Code SDK?

Claude Agent SDK is the renamed successor to the Claude Code SDK. Anthropic changed the name to reflect the fact that the same agent harness can power workflows beyond coding. Existing projects should follow the current migration documentation rather than assuming older package names, authentication behavior, or examples remain current.

What is the difference between a Claude agent and a subagent?

A Claude agent is the primary goal-directed workflow; a subagent is a delegated worker with separate context inside that workflow. Subagents are useful when a focused research, review, or parallel task benefits from isolation. They add execution capacity but also add context and token overhead, so the parent agent should delegate only when separation improves the work.

Does Claude Agent SDK require coding?

Yes, Claude Agent SDK is a developer library rather than a no-code product. Anthropic currently documents programmable Agent SDK use in Python and TypeScript. Users who want Claude to perform technical work without embedding the loop in an application should start with Claude Code instead of creating an SDK project.

Do Claude agents need MCP?

No, MCP is optional. A Claude agent can work entirely with built-in tools or custom tools that do not use Model Context Protocol. MCP becomes useful when the application needs standardized connections to external tools and data sources. The need for MCP is therefore an integration decision, not a requirement for agentic behavior.

Is Claude Agent SDK free?

There is no universal “free Agent SDK” answer because usage is tied to authentication and Claude usage limits. Anthropic’s October 2026 guidance says plan-authenticated Agent SDK usage continues to draw from subscription limits, while linked Console API-key usage can draw from included API credits on eligible plans and then from API billing. Current terms should be checked before deployment.

Can Claude agents work in the background?

Background execution depends on the surface and hosting model. Claude Code can run delegated tasks and subagents within its supported session model; an Agent SDK application needs a process or deployment that remains available; Managed Agents is designed for hosted, long-horizon sessions. “Background” should therefore be defined by where the runtime lives and how the user can observe or stop it.

Which Claude agent should beginners start with?

Most developers should start with Claude Code before building with the Agent SDK. Direct use reveals which tasks benefit from autonomy, what context Claude needs, which permissions feel acceptable, and how results should be verified. Agent SDK becomes useful when the goal changes from “use an agent” to “ship an agent experience inside another application.”