What Agents Actually Are

Claude in VS Code: Pair Programming already covered the assistant you're used to talking to directly — the one that explains code, refactors it, writes tests, and debugs alongside you inside your own conversation. This course is about something different: subagents — separate, purpose-built agent instances you can delegate specific work to, each with its own context and its own restricted set of tools. Understanding exactly how a subagent differs from the assistant you already know is the foundation everything else in this course builds on.

The Default Assistant You're Already Using

Every message you send in a normal Claude Code session goes to the same assistant, in the same ongoing conversation. It remembers everything said earlier in that conversation, has access to whichever tools your setup grants it, and handles your request directly — reading files, editing code, running commands, all within that one continuous thread. This is exactly what Claude in VS Code: Pair Programming taught, end to end, and this course assumes it's already comfortable ground.

What a Subagent Actually Is

A subagent is a genuinely separate agent instance, launched to handle one specific task, rather than a continuation of your own conversation. It starts with its own independent context — it does not automatically inherit everything said earlier in your conversation with the default assistant — and it works through the task it's given, then reports back a result to whoever launched it. Some subagents run in the background, continuing their work while you keep talking to the default assistant about something else; others run synchronously, pausing the conversation until they finish.

Tool Permissions: Not Every Agent Gets Everything

A crucial structural fact about subagents: each agent type is defined with its own specific set of tools it's allowed to use — not necessarily the full set the default assistant has access to. A fast, read-only search agent built for exploring a codebase might be explicitly denied the ability to edit or write files at all, restricted to reading and searching only. A narrowly-scoped configuration agent might be granted only the two or three tools its one job actually requires, and nothing else.

Why Restrict Tool Access? This Is "Isolation"

Restricting an agent's tools isn't a limitation to work around — it's a deliberate design choice, and it's what this course means by isolation. An agent built purely to search and report back has no legitimate reason to modify a single file, so denying it write access isn't overly cautious — it's a guarantee: however that agent behaves, it structurally cannot alter your codebase, only describe it. The same logic applies to any narrowly-scoped agent — the tighter its allowed toolset matches what its actual job requires, the less that agent can do wrong, by construction rather than by hoping it behaves.

A Concrete Example: A Search Agent vs. Doing It Yourself

Suppose you ask where user authentication is handled in a large, unfamiliar codebase. The default assistant could search directly itself — running several greps, reading a handful of candidate files, gradually narrowing in — but every one of those intermediate searches and file reads becomes part of your own conversation's context, whether or not any of it turned out to be useful. Delegating the same task to a dedicated search agent instead means all of that exploratory noise happens inside the agent's own separate context; only its final, distilled report — "authentication is handled in these three files, here's how" — comes back into your conversation. The search still happens; where the mess of getting there lives is what changes.

Hands-On Exercises