What Are Claude AI Agents?

Ask four people what a Claude agent is and you will get four answers. One means the coding tool. One means the thing you define in a markdown file to review pull requests. One means the folder of instructions that teaches Claude a workflow. One means the developer kit for building agents into their own product.

All four are right, which is the problem. "Claude agent" is not one feature; it is a layer of related things that share a name, and the only way to make a sensible decision about any of them is to separate them first.

This is a map rather than a tutorial. By the end you should know which of the four you actually want, and — more usefully — when the answer is that you do not want an agent at all.

What Are Claude AI Agents?

A Claude agent is Claude given a goal, a set of tools and permission to work through a task over multiple steps on its own, instead of answering a single question and stopping.

That is the whole idea. An ordinary chat turn is one exchange: you ask, it answers. An agent runs a loop — it decides what to do, uses a tool, looks at the result, decides again, and keeps going until the task is done or it hits a limit you set. The difference is autonomy over several steps, not intelligence.

In practice the word gets attached to four distinct things in Claude's ecosystem: the agentic coding tool, subagents you define yourself, Agent Skills, and the Agent SDK. They are complementary rather than competing, and most people only need one or two.

Running agents over your own content is a lot more useful when that content is actually findable. Get a free SEO audit and see where your pages stand.

The Four Things People Mean by "Claude Agent"

Each of these solves a different problem. Mixing them up is what leads to people building a subagent when they needed a skill, or reaching for the SDK when the terminal tool would have done it.

Claude Code

The agentic tool that works in your codebase and your terminal. It reads files, runs commands, edits code and iterates on the results. When someone says they are "using a Claude agent" to refactor something, this is almost always what they mean.

It is the most common entry point because it needs no building. You install it, point it at a project, and the agent behaviour is already there.

Subagents

Specialised assistants the main agent delegates to. Each one runs in its own context window with its own system prompt, its own tool access and its own permissions, and when it finishes it hands back only a summary.

That last detail is the real point. A search across a large codebase produces an enormous amount of output; a subagent absorbs all of it and returns a paragraph, so the main conversation stays clean. There are built-in ones for exploration and planning, and you can define your own.

Agent Skills

Packaged procedural knowledge — instructions, and optionally scripts and reference files, that Claude loads when the task calls for it. A skill does not add new abilities; it teaches Claude how you want a particular job done.

Skills are a directory with a SKILL.md file at the root, carrying name and description in YAML frontmatter. The description is what matters most, because it is what Claude matches against to decide whether the skill is relevant.

The Agent SDK

The developer path. If you are building agent behaviour into your own product rather than working in a terminal, the SDK is what you use, and skills and subagents are available as building blocks inside it.

How to Create a Subagent

A subagent is a markdown file with YAML frontmatter, and the body of the file becomes its system prompt. Only name and description are required.

Where you put the file decides its scope. A file in .claude/agents/ belongs to one project; the same file in ~/.claude/agents/ is available across all of your projects, and project-level definitions win when names collide.

The optional fields are where the control is:

• tools is an allowlist, so a reviewer can be given read access and nothing else
• disallowedTools is the inverse, a denylist
• model picks which model runs it, including cheaper ones for simple work
• maxTurns caps how long it can keep going
• skills preloads specific skills into its context
• memory gives it persistence across invocations

Omit tools entirely and the subagent inherits whatever the main conversation has, which is usually more access than a narrow worker needs. Being explicit here is the difference between a constrained reviewer and a general agent that happens to be called a reviewer.

Delegation is driven by the description. Claude reads the descriptions of the available subagents and matches the task against them, so a vague description produces a subagent that never gets used, and you can always invoke one by name instead.

Clear, well-structured content is what both search engines and AI assistants reward. Request a free audit to see how yours reads to a machine.

How Agent Skills Work

The mechanism that makes skills practical is progressive disclosure: Claude does not load the whole skill up front. It loads it in stages, and that changes what is worth putting in one.

• The name and description are always loaded, at a cost of roughly a hundred tokens per skill
• The body of SKILL.md loads only once the skill is triggered
• Bundled files load only when something actually needs them
• Scripts are run rather than read, so only their output enters the context

The consequence is counterintuitive and genuinely useful: unused reference material is free. A skill can carry a long specification, several reference documents and a handful of utility scripts, and none of it costs anything until the moment it is needed. Keep SKILL.md short and push the detail into files alongside it.

Skills work across the Claude apps, Claude Code and the API, though the details differ by surface — in Claude Code they are filesystem-based folders, while the apps and the API have their own upload paths and plan requirements. Check the current documentation for which surface you are on rather than assuming they behave identically.

When to Use an Agent and When Not To

The honest answer is that agents are worth the setup less often than the enthusiasm suggests. The cases where delegation clearly pays off are specific.

Reach for a subagent when the work produces a lot of output you do not need to see, when you want tool access genuinely restricted, when the task is self-contained enough to come back as a summary, or when you keep spawning the same kind of worker with the same instructions. That last one is the strongest signal: repetition is what justifies writing a definition down.

Stay in the main conversation when the task needs back-and-forth, when several phases share context, or when you are making one small targeted change. A fresh subagent starts with no knowledge of your conversation, so everything it needs has to be packed into the delegation prompt — and for a quick fix, writing that brief costs more than doing the work.

• Verbose, self-contained work that returns a summary — delegate
• Repeated identical tasks — delegate, and write a definition
• Work needing restricted tools or permissions — delegate
• Iterative refinement with a lot of shared context — stay in the main thread
• A quick, targeted edit — stay in the main thread

Knowing when a simpler tool wins is the same judgement SEO rewards. Request a free audit and find the pages worth the effort.

The Limitations Worth Knowing

• A subagent does not see your conversation history, so an underspecified delegation prompt produces confidently wrong work
• Agent requests consume the same usage budget as everything else; delegation moves context around, it does not make the work cheaper
• Many subagents returning detailed results can fill the main context anyway, defeating the purpose
• Skills can direct Claude to run code, so a skill from an untrusted source is a real security concern and the bundled files are worth reading before use

The last point deserves more weight than it usually gets. A skill is executable instruction material, not a document. Treat installing one with the same caution you would give any dependency you are about to run.

The first point is the one that bites most often in practice. When a subagent returns something that misses the mark, the delegation prompt is almost always the cause, not the subagent definition.

Auditing what you publish is the same discipline as auditing what you install. Start with a free SEO audit.

Claude Agents vs the Alternatives

The comparison worth drawing is not Claude against other vendors but agent against simpler tool, because the simpler tool wins more often than people expect.

A plain prompt handles anything you will do once. A project instruction file handles standing context that should apply to everything in a repository. A skill handles a repeatable procedure. A subagent handles a repeatable procedure that also needs isolation or restricted tools. Only reach for the SDK when you are shipping agent behaviour inside your own product.

Against other coding agents the practical trade-offs are about ecosystem and workflow rather than raw capability, and they move constantly — our comparison of Claude Code and GitHub Copilot goes through those use case by use case.

• One-off task: a prompt
• Standing project context: an instructions file
• Repeatable procedure: a skill
• Repeatable procedure needing isolation: a subagent
• Agent behaviour inside your own product: the SDK

Final Thoughts

The useful mental model is a stack rather than a menu. Skills are knowledge, tools and connectors are capability, subagents are isolation, and the SDK is distribution. Asking "do I need a Claude agent?" is the wrong question; asking which of those four layers your problem actually lives in gets you somewhere.

Most people, most of the time, need a skill rather than a subagent. Writing down how you want a job done is a smaller commitment than defining a worker to do it, and it is reusable across every surface Claude runs on.

And if you are building agents that read the web, it is worth remembering that they read it the way search engines do — structure, clarity and findability decide whether your content is the thing an agent cites or the thing it skips.