The agent

A model, a loop and some tools. The model asks for a tool, a program runs it and hands back the result, and this repeats until the model says it has finished.

The loop is what changes your job. A chat reply is one answer you can read before anything happens. An agent takes many actions before you look, so your attention moves from what it said to what it did.

The cycle inside every agent: send the context to the model, read its reply, run any tools it asked for, add the results to the context, and send it all again. It ends when the model stops asking for tools.

The whole context goes back on every turn, so it only grows, and a wrong assumption from turn two is still being read on turn twenty. Slow late turns, rising cost, and an agent stuck on an early mistake all come from this.

Everything in an agent except the model: the loop, the tools, the instructions, the permissions, the hooks, the sandbox. It decides what the model sees and what happens to what it asks for.

You can't change how the model thinks, but you can change nearly everything it sees and can do. The same model in a different harness does different work, and the harness is the only part of that you own.

A function the harness offers the model, described by a name, a purpose and the inputs it takes. The model can only write a request to use it. The harness checks the request, runs the function and returns the result.

Tools set the limit of what an agent can do, and their output is how it learns what happened. An error that names the fix makes it better without touching the model. A 5,000-line dump makes it worse and costs you for the privilege.

An agent whose tools can read and edit files and run commands, so it can write code, run it, see what broke and try again. Claude Code, Codex and Cursor's agent are coding agents.

Running what it wrote is the difference. Chat hands you code you have to test yourself. A coding agent can run it, which means a check you set up can reach the agent while you are somewhere else. Everything in chapter 9 depends on this.

Building with a model and not reading the code it writes. You accept every change, paste errors back in, and judge only by whether it seems to work. It describes how you work, not which tool you use, and it is fine for throwaway projects.

Agents make it easy to go far past the point where you understand the code, and it feels the same all the way. So ask what happens if this is wrong. For a weekend toy, nothing: vibe code it and enjoy the afternoon. For anything holding other people's data, that answer changes.

Building software with coding agents while staying answerable for the result. You set the goal, decide what the checks are, and can explain what shipped. The agent types, and you are still the engineer.

This is what an employer pays for and what a sceptic will test. Typing stopped being scarce. Knowing what to build, and being able to prove it works, did not. Agents make the gap between the two people much wider, because the output looks alike until something breaks.

A plain text file in your repo that the agent loads when it starts: build commands, a map of the code, things not to do. AGENTS.md is the name shared across tools. CLAUDE.md is Claude Code's own.

It goes into the context of every request, and it is only advice. Claude Code's docs say these files are "context, not enforced configuration". So short and specific beats long and thorough, and anything that must always hold belongs in a hook or a deny rule, both coming shortly.

Instructions that load only when they apply, usually when the agent touches certain files. A rule for database code stays out of the context until the agent opens database code.

One big instructions file is paid for on every request, even when a tenth of it matters. Scoped rules keep that file short. The risk is the opposite one: if the agent never opens a matching file, it never sees the rule.

A folder holding a SKILL.md file: a name, a one-line description and steps to follow, sometimes with scripts beside it. Only the name and description load at first. The agent reads the rest when the description matches what it is doing.

You can keep fifty procedures available for roughly the price of fifty one-liners. That makes the description the part that matters most: write it vaguely and the skill never fires, and you will think the agent ignored you.

A word starting with / that you type to make the harness do something right now: clear the context, switch mode, or run a saved prompt. You type it, not the agent.

It turns a long instruction you repeat into one word, so the careful version becomes the easy version. If you type the same review prompt every day, it should be a command the whole team shares.

A script the harness runs at a set moment, such as just before a tool runs or when the agent tries to stop. It can block the action. The model has no say in whether it runs.

A line in AGENTS.md saying "never run rm -rf" can be ignored. A hook that blocks it can't, as long as the hook recognises the command. A script looking for rm -rf will wave through rm -r -f, and in Claude Code, by default, the only exit code that blocks is 2.

A second agent the main one starts for a side job. It gets its own context window and its own instructions, and hands back a summary. The thousands of lines it read never enter the main conversation.

Searching and reading are noisy, and a subagent keeps that noise away from the agent doing the real work. A fresh one also hasn't seen the reasoning it is checking. The cost: it starts knowing nothing, so your brief to it is all it has.

Model Context Protocol: a standard way for an agent to use tools that live outside it. A server offers tools such as "search issues", and any agent that speaks the protocol can list and call them.

One integration works across every agent, so you don't rebuild the link to, say, your bug tracker for each one. But each tool definition costs tokens on every request, and a server's tools run real code. Treat installing one like adding a dependency that has your agent's access.

A list of code you can pull into your repo as files you own, with a command that works out what else each piece needs. You end up with source in your tree that you can edit, and not a dependency someone else updates for you.

An agent can read, change and test code in your repo, which is harder with what sits inside a package. You pay in upkeep: nothing tells you when the original gets a fix, and code you copied without reading is still a stranger's code. Nobody we found has measured whether agents do better this way.

A setting for how much the agent may do before it has to stop and ask you. Modes run from asking about nearly everything to asking about almost nothing.

With an agent running for an hour you can't read every prompt, so the honest question is which actions you want stopped. Choosing a mode is choosing what you will no longer see. The names mislead too: Claude Code's acceptEdits also approves rm inside your project.

A list of actions the agent may take without asking. Anything not on it still stops for approval. Rules like Bash(bun test) are how you cut prompts without turning them off.

It is the cheap way to fewer prompts, but a pattern allows more than it looks like. Bash(git *) allows git push --force. Rules also match the text of a command, so a deny rule stops the usual spelling and can miss the same program written another way.

A boundary enforced by the operating system that limits what a running command can touch: which folders it can write to, which it can read, and where it can connect. It holds even when the agent has been tricked.

Prompts depend on you paying attention, and rules match text. A sandbox doesn't care how a command is spelled, which is what makes long unattended runs reasonable. But read the defaults before you rely on one, because they are not what most people assume.

A mode where the agent can read and explore but can't edit your source files. It writes a plan, you read and change it, and only then does the work start.

A wrong plan takes a minute to fix, and a wrong diff can take an hour to unpick. It is also the cheapest moment to find out the agent misunderstood you. People do skip it: Elicit's interviewers report that "Plan-first thinking is rarer than we expected."

One run of an agent from its first message to its last, with its own growing context. When it ends, that context is gone unless you resume it, or the agent wrote something to a file.

An agent doesn't remember yesterday. Whatever a session decided and didn't write into the repo is lost to the next one, so a good session leaves files behind. Keeping to one task per session also keeps one job's clutter out of the next.

Whatever carries over from one session to the next. There is nothing magic in it: it is files, put back into the context when a session starts. Some you write yourself. Some the tool writes for itself.

Without it, every session pays again to find out what the last one learned. With it, a wrong note gets loaded into every session too, possibly one you have never read. Treat memory like code: look at it, and delete what is wrong.

Running an agent with nobody at the keyboard: one command, one prompt, and output a script can read. It is how an agent runs on a schedule, or in continuous integration, the automatic checks on a server that chapter 9 covers.

There is no one to answer a prompt, so whatever would have asked must be decided in advance. Allow too little and the run achieves nothing. Allow too much and nothing is watching. And never trust its final message: have the script run the checks itself.

A scale for how much of the work an agent does before a person looks at it. At one end you approve every line. At the other you write a spec and judge only the result.

Each step up removes a check you were doing, and it is only safe if something else now does that check. People talk about the levels as if higher were better. The honest question is what replaced you at each one.

A person has to approve at a chosen point before the work continues. That point could be each command, each plan or each merge.

An approval only counts if it gets read. Ask too often and people click yes without looking, and then there is a human in the loop but no check. A few approvals on things that matter beat fifty on things that don't.

Anything that can't easily be undone: deleting data, force-pushing, dropping a table, sending an email, spending money. An ordinary mistake gets another attempt. These may not.

An agent is as confident about these as about anything else, and the loop means it can reach one many steps after you stopped watching. So keep the undo out of its reach: commit first, keep a backup it can't delete, and don't give it production credentials.

Everything the agent could touch if it wanted to, or if someone tricked it: your files, your environment variables, your logins, your network. That reach, and not the task you gave it, is the size of what could go wrong.

Anything it reads can contain instructions, and a model can't reliably tell your words from an attacker's. So you judge a setup by its reach. If private data, outside content and a way to send data out are all in one agent, you have a problem whatever the task is.