What are Claude Code agents and why should you care

March 6, 2026 | 11 min read |

“Agent” is the most overused word in AI right now. Everyone talks about agents. Anthropic announces agent features. Twitter/X debates agent architectures. And if you’re a normal person using Claude Code to build things, you’re sitting there thinking: what does any of this actually mean for me?

You’ve been using an agent the whole time. You just didn’t know it had a name.

Claude Code is an agent

There’s a difference between asking AI a question and having AI do the work.

When you paste code into a chat window and ask “what’s wrong with this,” you get an answer. You read it, copy the fix, paste it into your editor, hope it works. If it doesn’t, you go back and ask again. That’s a chat.

When you open Claude Code and say “add a dark mode toggle to my site,” it doesn’t answer. It acts. It reads your files to understand how your project is structured. It decides which files to change. It writes the code. It runs the build to check if it broke anything. If it did, it reads the error and fixes it. Then it tells you what it did.

That loop - read, decide, act, check, repeat - is what makes something an agent. It doesn’t wait for you to tell it what to do next. The difference is like asking someone for directions versus handing them the steering wheel.

What an agent can do

An agent has tools. It can read files, write code, edit existing files, run commands in your terminal, search through your project. Every time it does something, it picks a tool, uses it, looks at the result. Then decides what’s next. You see this in real time. It reads a file, edits three lines, runs the build. Error. Reads the error, fixes it, runs the build again. That’s the agent loop.

You don’t control which tools it uses or in what order. You describe what you want. It figures out the how. I once watched it read every file in my project before changing a single line of CSS. Why? I’d given it too much freedom. It could access everything, so it read everything. Tightened the permissions, now it stays focused.

Subagents: when one agent isn’t enough

Claude Code can create separate agents to handle specific jobs. These are subagents. Each one gets its own instructions, its own tools, its own memory. Not copies of the main agent. Specialists built for one task.

Say you’re building a feature. You want someone to review security while someone else checks performance. Claude Code launches two subagents in parallel. They work at the same time, each with their own context, and report back.

Why not just have one agent do everything? Context. Claude Code has a limited amount of space to think - its context window - how much it can hold in one conversation. Throw too much at it in one session - build this, review that, check performance, update docs, run tests - and it starts forgetting. The early instructions get pushed out by the new ones.

Subagents solve this. Each one gets a clean slate focused on one job. The security reviewer isn’t distracted by performance work, and the performance reviewer isn’t thinking about error handling.

Claude Code comes with some built-in subagents, but you can also build your own. I set up a custom code review that launches three subagents at the same time:

Security reviewer - looks for passwords accidentally left in the code, security holes, things a hacker could exploit
Performance reviewer - checks if the app loads fast, doesn’t download unnecessary files, and remembers things it shouldn’t have to load twice
Reliability reviewer - checks what happens when things go wrong. Network drops, two users clicking at the same time, empty data

They each produce findings. Then they challenge each other. Does the performance fix create a security problem? Does the security fix slow things down? What survives is the final recommendation.

Each reviewer is a markdown file (a text file with simple formatting). What to focus on, what tools to use, how to report back. Writing good agent instructions takes work. You’re defining what a specialist thinks about and what they ignore. But once the file exists, it works every time.

Skills: recipes you can reuse

Skills are predefined workflows. Type / followed by the skill name (like /commit) and it runs. Sometimes Claude activates them on its own when it recognizes the situation.

When you type /commit, it doesn’t just save your changes to Git. It reads what you changed, writes a message describing what and why, picks the right files, creates the commit. A sequence of steps packaged into one command.

Two recent additions:

/simplify - you build a feature, then run /simplify. It launches separate agents that check your code - is it clean, is it fast, does it follow your CLAUDE.md rules. Three lines instead of twelve. Also catches things that drift from how your project is supposed to work.

/batch - automates repetitive changes across your whole project. If you need to update the same pattern in fifty files, /batch goes through each one, makes the change, and verifies it works. Instead of you doing it file by file for three hours.

Other skills: /plan makes Claude think before it builds. /init generates a starter CLAUDE.md from your project. You can write your own too. I have a /code-review skill that launches the three-reviewer setup I described above.

The difference between a skill and just asking Claude to do something: consistency. When you type “review my code,” Claude might check three things or thirty depending on the day. When you type /code-review, it follows the exact same process every time. Same agents, same checklist, same output format.

Agents vs skills vs subagents

	What it is	When to use it
Agent	Claude Code itself. Reads, decides, acts, repeats	Always. You’re already using it
Subagent	A specialist with its own prompt and tools	When you need focused work without overloading the main conversation
Skill	A reusable workflow triggered by /command or auto-detected	When you want the same process every time. Commit, review, plan

You can build your own

Agents and skills aren’t locked features. They’re text files.

An agent is a markdown file that says “you are a security reviewer, you have access to these tools, focus on these things.” That’s it. Claude Code reads it and becomes that specialist.

I built four design agents that handle brand, UX, visual design, and UI architecture. All markdown files. One says “you are a brand strategist, when no brand exists, ask four rounds of questions to figure out the direction before writing anything.” Another says “never use opacity-only hover effects, always spec every section of a landing page.”

They check each other’s work. Visual proposes a design, UX reviews the flow, brand flags anything off-voice. When one agent’s suggestion breaks another’s rules, you see it in the output. What comes out is better than what any single agent would produce.

The CLAUDE.md setup is what ties it all together. It tells Claude Code where your agents live, what skills exist, and how to use them.

Build your first agent

Create a file at ~/.claude/agents/a11y-checker.md. This is an accessibility agent (a11y is shorthand for “accessibility” - count the letters between a and y). It catches problems before Google Lighthouse does.

I built this one after shipping a page that looked perfect and then failed an accessibility audit. Missing label. Contrast ratio just below the line. You know the rules, but when you’re deep in layout and spacing, the checklist stuff slips. Now the agent runs it before I push. Beats finding out after the site is live.

---
name: a11y-checker
description: Checks HTML for accessibility issues
tools:
  - Read
  - Grep
  - Glob
model: sonnet
---

You are an accessibility specialist. Check the given files for:

1. Images without alt text
2. Buttons and links without accessible names
3. Heading levels that skip (h1 to h3 with no h2)
4. Form inputs without labels
5. Color contrast below WCAG AA (4.5:1 for text, 3:1 for large text)
6. Missing aria-labels on interactive elements
7. Missing lang attribute on html tag

For each issue:
- File and line number
- What's wrong and why it matters
- The fix (show the corrected code)

If the page is clean, say so. Don't invent problems.

The section between the --- lines at the top (called frontmatter) defines the name, the tools, and the model. Everything below shapes how this specialist thinks.

How to test it:

Build something first - a new page, a form, a navigation. Then tell Claude:

run a11y-checker on this project,
I don't want Lighthouse yelling at me again

The agent reads the file, checks against its rules, and reports back. If it misses something you care about, edit the markdown file. Add rules. Remove ones that produce noise.

My first agent took about ten rewrites before it did what I wanted. The biggest problem wasn’t the rules. It was the tone. AI defaults to agreeing with you. “Great job, looks clean, maybe one small suggestion.” I don’t need a helper that nods along. I need one that tells me the heading structure is broken and the contrast ratio fails. Before I push, not after. So I wrote that into the instructions: zero sugarcoating, flag every problem or don’t bother responding. That’s when it stopped being polite and started being useful.

Things to adjust after testing:

Flagging things that aren’t real problems? Make rules more specific. “Images without alt text” might become “Images without alt text, excluding decorative images with role=presentation”
Missing obvious issues? Add them. The agent only checks what you tell it to check
Too slow? Switch model: sonnet to model: haiku for faster runs. Use opus only for deep analysis
Wrong files? Add a paths field to the top section so the agent only triggers on matching files like *.astro or *.html

Build your first skill

Create a folder at ~/.claude/skills/pre-push/ with a file called SKILL.md:

# Pre-Push Check

Before pushing to GitHub, run these steps in order:

1. Run the build (`npm run build`). If it fails, stop and fix
2. Search for console.log in src/ files. List any found
3. Search for TODO and FIXME comments. List any found
4. Check that no .env files or API keys are staged for commit
5. Run tests if they exist (`npm test`)
6. Report: ready to push, or list what needs fixing first

That’s a working skill. When you type /pre-push or when Claude recognizes you’re about to push, it runs these steps in sequence.

How to test it:

Make a change to your project, leave a console.log in there on purpose, then:

I'm about to push this to GitHub,
run the pre-push skill first

If it catches the console.log, the skill works. If it misses something you care about, edit the steps. If a step is unnecessary, remove it. Skills should be short - five to eight steps max. If you need more, you probably need an agent instead.

Skill vs agent - when to use which:

A skill is a checklist. Same steps, same order, every time. Good for: saving code, pushing to production, running checks before you ship.

An agent is a thinker. It decides what to do based on what it finds. Good for: analyzing code, finding bugs, reviewing accessibility, making architectural decisions.

If you can write it as a numbered list, it’s a skill. If the answer depends on what the agent discovers, it’s an agent.

Start small

Pick one thing you keep repeating. “Check the build before I push.” “Review this file for security issues.” “Create a new component with the same structure as the existing ones.”

Write it as a skill if it’s a checklist. Write it as an agent if it needs judgment. Test it. Fix it. Test it again. Give it a week. You’ll have two or three that save real time.

The CLAUDE.md post covers how to set up the configuration layer these plug into. The design agents post shows what happens when you take this further than most people would.