Claude Agents, Explained

Subagents are separate Claude instances that Claude Code spawns to handle a scoped task. The point is context isolation. A subagent that reads forty files to answer one question burns its own context window, not the main session’s, and returns a short report instead of the forty files.

They are configured as markdown files with YAML frontmatter, in .claude/agents/ for a project or ~/.claude/agents/ for everything you work on. The frontmatter names the agent, describes when it should be used, restricts which tools it may call, and can pin a model tier. The body is its system prompt.

The description field earns more attention than people give it. Claude Code uses it to decide when to delegate automatically, so a vague description produces an agent that never fires or one that fires constantly. You can also invoke a subagent explicitly when you want control rather than delegation.

Two practical notes. Restricting tools is a real control, not decoration: a review agent with read-only tools cannot edit files no matter what it concludes. And pinning a cheaper model on high-frequency subagents is the easiest cost lever in the whole setup, because those are the ones that run dozens of times a day.

Where subagents genuinely earn their keep is parallel work: several exploring different parts of a codebase at once, each reporting back a summary. Where they disappoint is tasks needing continuous back-and-forth with you, since the isolation that makes them cheap also means they cannot see the conversation you have been having.

Below the products, the primitive is tool use. You send Claude a list of tools, each with a name, a description written for the model, and a JSON Schema for its arguments. Claude replies either with text or with one or more tool-use blocks. You run them, send the results back, and repeat.

Two details trip people up on the first attempt. Tool results go back in a user turn, not an assistant one. And the assistant message must be appended verbatim, because each result references the id of the tool-use block that requested it. Claude can also request several tools in a single turn, so handle the list rather than the first element.

The Anthropic SDKs ship a tool runner helper that drives this loop for you, with hooks for approval, error handling, and retries, so you do not have to hand-roll the plumbing. Whether you use it or write the loop yourself, the parts that decide quality are the same: tight tool descriptions, server-side validation of arguments, and a turn ceiling.

For tool access at scale, MCP is the mechanism worth knowing. It standardises how an agent connects to external tools and data, so you attach an existing catalogue rather than writing an adapter per system. Claude Code, the Agent SDK, and the API all speak it.

Memory is the other design decision. The conversation is working memory: expensive, volatile, and capped by the context window. Long agent runs outgrow it, and the fix is compaction plus a durable store for facts that must survive. Claude’s newest models carry very large context windows, which delays the problem without removing it, and a large window is not free to fill. Context windows explained covers the arithmetic. The general build sequence, framework-neutral, is in how to build an AI agent.

Claude models have a reputation among agent builders for two specific things, and it is worth being precise about them rather than repeating the marketing.

The first is instruction adherence under pressure. Tell a Claude model not to call a tool under certain conditions and it tends to honour that across a long run, which is exactly what a multi-step agent needs. The second is tool-call formatting. Schema conformance is generally reliable, which means fewer runs lost to malformed arguments and fewer defensive retries in your loop.

Long-horizon coherence is the other frequently cited strength: staying on task across many turns without drifting into a different problem. That is the property that makes Claude a common default for coding agents specifically, where a task can involve dozens of file reads and edits.

The limits are equally real. Being a single vendor, capacity and rate limits are a shared resource, and a busy period is felt by everyone at once. Model deprecations happen on Anthropic’s schedule rather than yours, and a deprecated model behind a production agent is an unplanned migration. Pricing sits at the higher end for frontier tiers, so an agent that runs every model call on the top model will cost considerably more than one that routes. And on narrow, high-volume classification work, a cheap model from any vendor is usually the right answer regardless of which one is smartest.

Head-to-head comparisons live in Claude vs ChatGPT, and the tier decision within the family is covered in Claude Opus vs Sonnet.

Three operational realities separate a Claude agent that runs on a laptop from one a business depends on, and none of them are about prompt quality.

Availability. Providers have incidents. Providers also pull models: in 2026 a newly released frontier model was withdrawn days after launch, which we covered in the vendor fragility write-up. If your agent names one model in one SDK call, either event is an emergency. If fallbacks are declared in advance, it is a degradation.

Rate limits. Agent traffic is bursty by nature, since one triggered run becomes eight API calls in quick succession. Capacity that looks generous against average volume gets consumed by a queue draining after an outage. Overflow needs somewhere to go.

Attribution. Once several agents share a key, the invoice stops being diagnosable. Which agent, which step, which model, which team: without that breakdown the only available cost control is switching things off.

This is the layer Swfte Connect handles. Claude models sit alongside 50+ providers behind one API, with fallbacks declared per step, automatic failover when a provider degrades, and cost telemetry per call. Your agent keeps calling one endpoint while routing changes underneath it. For teams who would rather not write the orchestration at all, Studio builds agents visually on that same gateway, so choosing Claude for one step and something cheaper for the next is configuration.

Agent economics differ from chat economics in one structural way: the conversation is resent on every turn. A ten-turn agent does not cost ten times a single call. It costs more, because turn ten carries the whole accumulated history as input. That quadratic-ish growth is the single most surprising line on a first agent invoice.

Three levers apply, in descending order of impact.

Current per-model rates change often enough that quoting them here would age badly. Claude API pricing tracks them, and the token cost calculator turns them into a per-run figure for your own volumes. The mechanics of caching, including where the breakpoints go, are in prompt caching.

One habit worth building early: track cost per completed task, not cost per token. Tokens tell you nothing about whether the agent is getting more expensive because volume grew or because it started retrying. Cost per task tells you immediately.