Context engineering in practice

What AI coding tools actually are, and the habits that decide how well they work.

This piece is adapted from a talk I gave. Its companion, Working With AI, covers getting value out of language models more generally.

Every AI coding tool I have used, whether it is Claude Code, Codex, Cursor or the minimal open-source Pi, does the same thing: it puts together a block of text and sends it to a language model. What goes into that text determines what comes back out of it, and deciding what goes in is the part of the work that is mine.

How these show up in practice

Each of the four causes a problem you will recognise. Once you can name the cause, the fix is obvious.

How confident it sounds tells you nothing about whether it is right.

The harness is the program around the model. It gathers the text to send, runs the tools the model asks for, and decides when to stop. There is less to it than the marketing suggests, and every tool I have worked with runs roughly this loop.

context = [system_prompt, AGENTS_md, tool_schemas, user_message]

while not done:
    response = llm(context)          # one API call
    if response.tool_call:
        result = execute(tool_call)  # bash, edit, read
        context += [response, result]
    else:
        done = True                  # agent yields

1. 1

   The context window is assembled

   Everything the model can see, collected again from scratch

2. 2

   The model predicts the next step

   One API call, and the model responds with text

3. 3

   A tool is called

   The harness runs it and adds the result to the context

4. 4

   No tool is called

   The loop ends and the agent replies

What one turn sends

This is roughly what gets sent on a single turn, in the order the harness puts it together.

Reading the system prompts

The better tools are not better because of a secret ingredient. The instructions they give the model are ordinary text, and several are published. When I give this talk I open one on screen and scroll through it, because thirty seconds of that makes the point.

The tools I have used

Since the loop is the same everywhere, these tools do not compete on what they can do. They differ in how many decisions they make for you.

What MCP costs

MCP is the most common way to give an agent tools that live outside it. The cost is easy to miss: every server you connect is paid for on every turn, whether you use it or not. On the setup I work with day to day, the connected servers add about 10k tokens to every single request, and that figure scales with how many servers and tools you attach. Measure yours rather than guessing. Most tools can show you what they are about to send, and in Claude Code that view is /context.

The file that made the biggest difference

The model forgets everything, so the only memory that survives between my sessions is a file I maintain. Most tools read AGENTS.md or CLAUDE.md from the repository and include it in every turn. I now treat it the way I treat code: reviewed, kept in version control, and cut back regularly.

The change that paid off most

Reviewing a plan takes me a couple of minutes. Reviewing several hundred lines of changes I was not expecting has taken me an afternoon, more than once.

Long sessions get worse

This failure is silent. As a session grows, the things you said early on drift out of the model's attention, and quality drops with nothing to warn you.

Skills

A "Skill" is a small directory of instructions that teaches an agent to do a task your way. Unlike AGENTS.md it loads only when the agent decides it is relevant, so it costs nothing on unrelated messages. That is what makes them worth writing.

pr-review-checklist/
├─ SKILL.md      # required, and its description decides IF and WHEN it triggers
├─ scripts/      # deterministic steps
└─ references/   # read on demand

You do not have to write them all yourself. There is an open standard at agentskills.io, a community library in obra/superpowers, a published set from Anthropic, and Pi packages on npm and git. Install one first, and write your own where your practices differ.

Two toolkits worth knowing

Both turn the practices above into tooling. I use superpowers every day, and reach for spec-kit in specific circumstances, mostly new feature development. Before you adopt either, it is worth understanding how it wants you to work, because that, rather than the feature list, is what decides whether it fits.

Four things to get right

Where to start

The specifics here will date. The loop underneath has not changed since the first agentic tools appeared, though, and everything above follows from it. Deciding what the model should see is the part I do not expect to hand over.

That decision has a price, and the price is easier to read than most people assume. I work through the token accounting on one of my projects, and the five habits that came out of it, in The economics of an agent's context window.