Chapter 1: Anatomy of an agent
"Agent" is used for everything from an autocomplete with a planning step to a system that runs unattended for hours. This chapter fixes one definition, opens the box, and explains why the thing inside eventually stops working well on its own.
The definition
An agent is a model that runs in a loop and acts on the world through tools until a stopping rule says it is done. A chat answers once; an agent keeps going.
Each turn of the loop: the agent reads what it has (the task, the files it opened, the output of the last command), decides on the next step, calls a tool (read a file, edit, run tests, search), looks at what came back, and goes round again. When the stopping rule fires - tests pass, the task is marked complete, a budget is exhausted, or you interrupt - it reports.
Four components
| Component | What it is | In Claude Code | In Cursor | In GitHub Copilot |
|---|---|---|---|---|
| Model | The reasoning engine; decides the next step | Claude family | Several vendors, selectable | Several vendors, selectable |
| Tools | The actions the agent may take | Read, edit, bash, grep, web, MCP servers, sub-agents | Read, edit, terminal, search, MCP, browser | Read, edit, terminal, MCP; GitHub API in the cloud agent |
| Memory | What persists across turns and sessions | Context window + CLAUDE.md + auto-memory files | Context window + rules + per-project memory | Context window + instructions files |
| Stopping rule | When to stop looping | Task complete, turn limit, user interrupt, permission denied | Same, plus background-agent time limits | Same; cloud agent stops at "PR opened" |
Nothing in this table is exotic. An agent is a while loop around a model call with a tool
dispatcher. The engineering is in the tools (what they can do and to what), the memory (what
survives), and the stopping rule (what counts as done).
What makes it different from chat
- It sees the consequences of its actions. The test output is in its context on the next turn. This is what lets it fix its own mistakes - and also what lets it fix them in the wrong direction three times in a row.
- It makes many decisions you did not review. In a thirty-turn session, the agent chose thirty next steps. You reviewed the first instruction and the final diff.
- It has permissions. A chat can only suggest. An agent can
rm -rf,git push, call an API. Permissions are the real safety boundary; Module 5 covers the policy and this module's Chapter 3 covers who gets what.
Why one agent stops scaling
Agents work well on tasks that fit in one head. Three things break as the task grows.
1. Context pollution
Every file read, every command output, every failed attempt stays in the context window. By turn forty, the context contains the full text of twelve files, six test runs, two abandoned approaches and the task - and the task is the smallest part. The model's attention is spread across all of it. Symptoms:
- It re-reads a file it already has.
- It "forgets" a constraint stated at the start.
- It reintroduces a bug it fixed ten turns earlier.
- Quality of each step degrades even though nothing changed.
Tools mitigate this with compaction (summarising old turns) and by letting you start fresh, but summaries lose detail and starting fresh loses everything. The structural fix is to not put everything in one context in the first place - which is what sub-agents are for (Chapter 2).
2. Serial execution
One agent does one thing at a time. A feature with a database migration, three API endpoints, a frontend component and tests is a sequence of five tasks. If each takes eight minutes, that is forty minutes of wall clock for work that has no dependency between endpoints two, three and four. Parallelism needs more than one agent.
3. One set of permissions
The agent that needs to run the test suite needs shell access. The agent that reads an untrusted GitHub issue to understand the task should not have shell access (prompt injection, Module 5). If it is the same agent, it has both, and the issue can make it run commands. Separating "reads untrusted input" from "has write permissions" needs two agents with two permission sets.
Reading a session
Before delegating anything, learn to read a single agent's session - it is the skill that everything in Chapters 2 and 3 builds on. Watch for:
| Signal | What it means | Response |
|---|---|---|
| Same test failing on the third attempt | The agent is patching symptoms; the approach is wrong | Stop. Restate with a tighter spec (Module 2) |
| Files opened outside the task's area | Exploring, or scope drift beginning | Ask "why that file?" or stop |
A tool call you would not have made yourself (git push, deleting, installing) | Permission boundary is too wide | Deny, tighten the permission set |
| Turn count climbing with no new test passing | Context pollution | Stop, summarise what was learned, restart fresh with that summary |
| The agent asks a question | Spec gap | Answer in the spec file, not just in chat |
The habit this builds - reading the loop rather than waiting for the diff - is what lets you run five agents at once later. You will not read five transcripts in full; you will read five transcripts for these signals.
Summary
- An agent is a model in a loop with tools and a stopping rule. Four components; the engineering is in tools, memory and the stopping rule.
- Chat suggests; agents act and see the consequences, so they can self-correct - or self-mislead.
- One agent stops scaling for three reasons: context pollution, serial execution, a single permission set. All three are solved by splitting the work across agents.
- Learn to read a session for its five warning signals before you run more than one.