Me, and the AI thingy

Context Engineering: Deciding What the Model Sees

Context engineering is the discipline of deciding which tokens fill the model’s window on every step of a task. Not one clever prompt. The whole evolving set of information the model reads, chosen fresh each time it runs. If the model is an instrument, context engineering writes the score it plays. And the score gets rewritten at every bar.

The term has a birthday. It was named in mid-2025, and the people who named it were precise about why. This piece is about that discipline: what it is, what it covers, and where it stops. Its twin, the machine that runs the model, is a separate piece. I draw the line here from the content side.

TL;DR. Context engineering is deciding which tokens the model sees at every inference step, not writing one good prompt. The name is only months old: Tobi Lütke floated it on 2025-06-19, Andrej Karpathy defined it days later, Anthropic formalized it that September. LangChain’s taxonomy names four moves: write, select, compress, isolate. It is a decision discipline, human taste picking the configuration of context most likely to produce the behavior you want. Its twin, harness engineering, builds the machine around the model; I draw the functional line here (content vs machine) and say plainly that I am drawing it. On Anthropic’s internal evaluations, context editing and memory cut token use 84% on a 100-turn eval and lifted task performance up to 39%.

The four moves of context engineering, write, select, compress, and isolate, arranged around a central context window holding the model.

A named discipline, with a birthday

Context engineering is young enough to date. It did not drift into the vocabulary. Two people put it there, on the record, in the space of a week.

Tobi Lütke went first, on X, on 2025-06-19. “I really like the term ‘context engineering’ over prompt engineering,” he wrote. “It describes the core skill better: the art of providing all the context for the task to be plausibly solvable by the LLM.” Note what he is doing. He is not naming a new trick. He is renaming the skill to point at the right object.

Days later Andrej Karpathy gave it the definition that stuck. Context engineering, he wrote, is “the delicate art and science of filling the context window with just the right information for the next step.” Two phrases carry the weight. “Just the right information,” so not everything you have. “For the next step,” so not once, but again and again.

By September the definition had hardened into engineering prose. Anthropic called it “the set of strategies for curating and maintaining the optimal set of tokens (information) during LLM inference” (Anthropic, Effective context engineering for AI agents, 2025). Curating and maintaining. That is the job.

A horizontal timeline: a long prompt-engineering era, then Lütke coining the term on 2025-06-19, Karpathy defining it around 2025-06-25, and Anthropic formalizing it on 2025-09-29.

From prompt to context: a progression, not a rename

It is tempting to read this as old wine, new label. It is not. It is a change in what you are optimizing.

A prompt is the words in one instruction. You write it once, you word it well, and you send it. Prompt engineering treated that string as the unit of work. Get the phrasing right and you were done.

Context engineering treats a much larger object as the unit. Anthropic scopes it plainly: the context is the system instructions, the tools, any MCP connections, external data, the message history, memory, and every line of tool output (Anthropic, 2025). Your carefully worded instruction is one item on that list. It shares the window with everything the agent has done, read, and called since the run began.

So the object grew, and it started moving. A prompt is static. A context is a live, accumulating token set that looks different on step 40 than it did on step 1. Karpathy’s “for the next step” is the whole shift. You are not composing a message. You are governing a state that changes under you. Prompt engineering is a subset of this, the way tuning one string is a subset of scoring the piece.

The four moves: write, select, compress, isolate

If context engineering is governing that state, what are the actual moves? LangChain gave the field its working taxonomy: write, select, compress, isolate (LangChain, Context Engineering for Agents, 2025). Four verbs, and every context decision is one of them.

Write is saving context outside the window so it survives. Scratchpads, memory files, notes the agent can come back to. You are not spending window space to remember; you are parking it and pulling it back on demand.

Select is the retrieval move: pulling the right tokens back in when the step needs them. The relevant file, the relevant memory, the relevant tool result. Not all of them. The right ones.

Compress is shrinking what is already there. Summarizing a long transcript, trimming a bloated tool output, keeping the signal and dropping the rest. It is the move that fights accumulation.

Isolate is splitting the work so no single window has to hold it all. Sub-agents, separate contexts, each with a clean slate for its slice of the task.

LangChain frames the whole thing with an operating-system analogy: the model is the CPU, the window is the RAM, and context engineering is what a good OS does, deciding what stays resident in scarce memory (LangChain, 2025). The four moves are how you manage the RAM.

It is a decision discipline

Here is the part that resists automation. The four moves are not a pipeline you run once and forget. Each one is a judgment call, made again on every step, about what configuration of context most likely produces the behavior you want.

That is why Karpathy called it a “delicate art and science,” not a procedure. Harrison Chase of LangChain put the same emphasis on judgment: context engineering is “building dynamic systems to provide the right information and tools in the right format such that the LLM can plausibly accomplish the task.” Dynamic. Right information, right format. Plausibly. None of those words describe a fixed recipe.

Think about what a single select actually asks. Which of forty files is relevant here? Which three lines of that test log matter, and which four hundred are noise? Compress this transcript now, or hold it one more turn because the next step needs the detail? These are taste calls. They depend on the task, the model, the moment. A machine can execute the compression once you have decided to compress. Deciding to compress, and deciding what survives it, is human work. The discipline is the deciding.

Where context engineering ends and the harness begins

So where does this stop? Draw the line by object. Context engineering engineers the content: which tokens go in the window, curated, selected, compressed, ordered. Its twin, harness engineering, engineers the machine: the runtime scaffold around the model, the loop, the tools, the guardrails, the orchestration, the code that actually runs a compaction pass. Content versus machine. Score versus instrument.

The two meet at one seam: context management, the compaction and truncation that trims a running window. That seam is a harness capability that executes a context-engineering decision. You decide what the window should hold. The machine enforces it. The score says play softer; the instrument is what makes the sound.

A two-layer diagram: an outer harness box wrapping an inner context window holding the model, with context engineering owning the content and harness engineering owning the machine, meeting at context management.

I should be honest that the field does not agree on how these nest. LangChain treats the harness as the container, calling harnesses “largely delivery mechanisms for good context engineering” (LangChain, Anatomy of an Agent Harness). Birgitta Böckeler, writing on Martin Fowler’s site, nests it the other way: “a harness is a specific form of context engineering.” Anthropic keeps them apart and never uses the word harness in its context-engineering post. Three respectable views, three different diagrams. So I am not claiming the true topology. I am drawing a functional line by object, content versus machine, because it is the line that helps you decide what to work on. The machine side is its own discipline, and its own piece: harness engineering, the machine side.

It pays off

None of this is aesthetics. Curating the token set moves the numbers, and the numbers are large.

🔬 Curation moves the numbers. On Anthropic’s internal evaluations, context editing cut token use by 84% over a 100-turn web-search task (Anthropic / Claude Developer Platform, Managing context, 2025). Same work, a sixth of the tokens. On an internal agentic-search eval, memory plus context editing lifted task performance by 39%, and context editing on its own lifted it by 29%.

Three horizontal bars from Anthropic internal evaluations: an 84% token cut on a 100-turn web-search eval, a 39% lift from memory plus context editing, and a 29% lift from context editing alone.

Read those figures with the label attached. They are Anthropic’s own internal evaluations, reported without sample sizes, and I have not seen them independently reproduced. Treat them as a vendor’s directional evidence, not a settled benchmark. Even discounted for that, the direction is the point: the same model, on the same task, does measurably better when the window is curated instead of left to fill on its own. Good scoring, not a bigger instrument.

What this hands off to

This piece names the discipline and draws its border. It leans on other pieces for the parts it does not carry.

For the mechanism underneath, why the window is finite, why a longer one costs more than linearly, and why capacity is not reliability, see the piece on the term itself: what a context window is. Context engineering is the practice; that piece is the machinery it operates on.

For technique, two spokes go deeper than a definition can. On keeping a running window lean on purpose, and why a bigger window just hides the rot, that is a spoke of its own. On which tokens actually earn their place in the preload, lexicon first, that is another.

Hold on to the one idea. Context engineering is not a prompt you perfect. It is a score you keep rewriting, deciding at every step which tokens the model gets to read. The instrument was always capable. The score is where the work is.

Sources

context-engineering primer
Newsletter

One email a month — what I'm working through, and the posts it produced. One click to leave.

Malo Couaran
Got a reaction, a correction, or a better idea? Reply by email.