Context

Choosing what the model can see on each request: which instructions, files, tool results and history go in, and which stay out. The prompt is what you say. Context is everything else it reads before it answers.

An agent gathers most of its context itself by calling tools, so your sentence is a small part of what it reads. Better wording can't supply a file it never opened. In chat you pasted everything in by hand. With an agent, you set up what it can reach and what it reads first.

Treating the window as money you spend. Each token that goes in stays in, gets sent again on every later turn, and leaves less room for what comes next. Test logs and whole files are the big purchases.

An agent spends this without asking. A test log nobody needed is read again on each turn after it, and billed each time. Larger windows moved the limit but not the logic. Claude Code's docs say you will "rarely run out", and still advise clearing between tasks, because "a focused context gets you better answers and costs less."

The informal claim that a model gets worse past some point in its window, so you should stay below it. That reliability falls as context grows has support. Any specific percentage is a working rule, because no one has shown us a measured line.

The habit it teaches is good: clear early, and keep noise out. But don't repeat a number as fact, least of all in an interview. Windows went from 200K to 1M, and a percentage and a token count now give very different answers. Watch for symptoms in your own sessions: rereading files, forgetting rules.

The limit you set on instructions that always load. AGENTS.md goes into every request, so each line has to earn its place on every task, including the many it has nothing to do with. Short and specific beats long and thorough.

Caching makes the dollars small, so that is not the main cost. Agents tend to do what these files say, so each needless requirement makes them do needless work, and a long file buries the rules that matter. Keep what the agent can't work out from the code, and cut the rest.

Starting the agent with a small entry point and showing it where to look next: a short index now, details when they are needed. A skill's description is the index entry, and its body is the detail.

You keep a whole shelf of procedures for the price of their labels. But the risk moves. The detail arrives only if the label matches, so a vague description means a procedure that never loads, and nothing tells you. Test the label, not just the procedure.

Keeping lightweight pointers, such as file paths and search patterns, and loading what they point to only when it is needed. The agent searches, reads twenty lines and moves on, and never holds the whole repo in view.

You pay only for what the task touches. And what it reads is current, whereas a file loaded an hour ago may have changed since. The price is more tool calls, and an agent that searches for the wrong word may not learn what it missed.

A short description of how a repo is laid out: which folder does what, and where to begin. It gives the agent a picture of the project without reading it, so its first search is aimed at something.

Without one, an agent can spend its first tokens wandering. But this is the most disputed advice in the chapter. Measured evidence says overviews often don't help, because agents find their way with ls and search anyway. So write down only what those can't show: the real entry point, what is generated, what owns what.

Telling the agent to copy something that already exists: "follow the pattern in src/db/users.ts". One path, and the code does the explaining. It is about the cheapest useful context there is.

Left alone, an agent writes what was common in its training text and not what is common in your repo. A pointer settles naming, errors and test layout in one line. It also copies the flaws, so point at the file you would want more of.

Searching a body of text, taking the top matches and putting them in the prompt so the model answers from them. Keyword search (BM25 is the standard scoring formula) finds exact words. Embeddings find related meaning. Each misses what the other finds.

The model sees only what came back, so a missed page may as well not exist, and the answer still sounds sure. For code, the leading agents have moved towards searching live. For big piles of documents nobody can grep usefully, retrieval still earns its place, if you measure it.

Making your tools print only what an agent can use: one tick when a check passes, and the full output only when it fails. The check still runs in full. Only the reading gets shorter.

A test run that prints 200 lines to say "all good" spends window on nothing, then gets read again each turn. Agents also trim noisy output themselves with head, which keeps only the first lines and can cut off the one failure and force a second full run. Let the exit code decide what gets shown, and not the model.

Sending noisy work, such as searching or reading big files, to a subagent, so the reading happens in its window and only a short summary comes back to yours. What you are buying is the clean window, not a specialist.

A search through 30 files shouldn't crowd the agent doing the careful work. But it isn't free: it costs more tokens in total, it may be slower because it starts knowing nothing, and you see only its summary, which can be wrong. Now that windows are big, keep it for work that is truly noisy.

A mistake that gets into the context and stays: a guess stated as fact, an invented function, a wrong summary. Every later turn reads it again and builds on it, so the agent's own earlier words keep arguing for the error.

A correction is one line against all the lines already written in favour of the mistake. So a third correction rarely works, and starting over with what you learned often beats arguing. Memory files can carry the same error into every future session.

A session slowly moving away from what you asked: the scope grows, an early rule stops being followed, the goal changes shape. No single turn looks wrong. You notice when the diff has things in it you never asked for.

Your first message becomes a smaller share of what the model reads, compaction may have removed it, and you are probably not watching closely by then. The defence is short sessions, rules kept on disk and not in chat, and comparing the diff with the original request.

Ending the conversation and beginning a new one with empty context, then giving it only what it needs. Your files and commits stay. What it read and said is gone, unless it was written down.

It costs nothing, and it removes every wrong turn at once. People resist because it feels like losing progress, but anything worth keeping should be in a file anyway. Do it between unrelated tasks, and after two failed corrections.

Replacing older turns with a summary, so a session can continue in less space. Most tools do it automatically near the limit, or when you ask. Whatever the summary leaves out is gone, and nothing flags the loss.

It is a summary you didn't write, and it loses things. A rule you typed in chat can vanish, and a wrong assumption can survive as fact. So keep rules on disk, where they get reloaded, and if you do compact, say what to keep. Doing it yourself, early, beats waiting for the automatic one.

A short file one session writes for the next: what is done, what failed, what was ruled out, what to do next and how to check it. It is all that crosses from one empty context to the next, so it has to stand alone.

The next session will otherwise pay to rediscover everything, or walk into the same dead end. What was ruled out is the part people forget, and it is the most expensive to find twice. A cheerful status report answers none of this, so write it for a stranger.

Splitting work into three phases. Research how the code works now and write it down. Turn that into a plan file. Implement from the plan. Each phase starts from the last one's file with a small window, and you review the files.

A research note and a plan are short enough to read properly, which a 2,000-line diff isn't. So you catch a wrong idea when it is one sentence and not a hundred files. For a small change it is overhead, so skip it. Nobody has measured this properly that we could find.

Keeping decisions, plans and how-tos as plain files next to the code, not in a wiki or a chat. The agent can search them with the same tools it uses on code, they change in the same commit as the code, and review covers them.

For an agent, a stale doc is worse than none: it believes what it reads, and states it with confidence. So docs in the repo need the same discipline as code, and the discipline can be a check. An agent can also keep them current, if you ask it to in the same commit.

The rule that anything the work depends on lives in the repo, in a form the agent can read. A decision in a meeting, a chat thread or your head doesn't exist for the agent until someone writes it where the agent looks.

It changes what counts as finishing a discussion: a decision isn't made until it is committed. It helps new people as much as agents. It has limits. Peter Naur argued in 1985 that part of a program's theory never gets written down, and a repo can't hold what nobody can say.

How easily an agent can find out what it needs by itself: names it can search for, errors that say what went wrong, logs it can query, an app it can start. Whatever an agent can't observe, it can only guess about.

Poor legibility is paid for in tokens and wrong guesses on every task. Most fixes are ordinary good engineering, with one twist: a name you can grep for now matters more, and code that assembles a name from pieces of text while it runs hides from search. Being findable saves reading, and so saves tokens.