Prompt engineering was about the wording of one message. Context engineering is about curating everything in the window on every turn — and it’s the skill that separates a slick demo from an agent that survives step 30.
The first agent I was genuinely proud of worked beautifully for about ten minutes. It was triaging support tickets — read the ticket, check the docs, draft a reply — and the early runs felt like magic. Then, somewhere past the tenth ticket in a session, it started drafting a reply for a ticket it had already closed, citing a doc it had never opened. I did what everyone does first: I blamed the model and reached for a bigger one. It didn’t help. The model was fine. Its context had turned to soup — and no model is smart enough to reason over soup.
If you’ve shipped anything agentic, you’ve probably hit this exact cliff: strong for a while, then a slow slide into forgetting the goal, repeating tool calls, contradicting itself. The good news is that the fix isn’t a secret prompt or a frontier model. It’s a skill, and it has a name.
The frontier quietly renamed the job. “Prompt engineering” — hunting for the magic phrasing of a single instruction — still matters, but it’s a rounding error next to the real work: deciding what information occupies the model’s limited window at each step of a long-running loop. Anthropic calls this context engineering and frames it as the natural successor to prompt engineering for agents.
Here’s the path we’ll take: where this skill sits next to the harness and the loop, why the window is a budget and not a bucket, the failure it creates (“context rot”), and the four moves that fix it — with a worked example at the end. If you already treat the window as a scarce resource you actively manage, skip ahead to The four moves.
Prompt engineering asks: “what do I say to the model?” Context engineering asks: “what should be in the window when the model reads it?” The first is a sentence. The second is a system — retrieval, memory, summarization, and isolation all working to keep the window small, relevant, and on-task.
Where does it sit?
So how is this different from the harness work or the loop work? These three disciplines stack. The harness configures what the model can touch; context engineering decides what it sees; loop engineering decides how the whole thing repeats. Miss the middle layer and the other two can’t save you — a perfectly permissioned agent in a beautifully designed loop still fails if its window is full of noise.
The window is a budget, not a bucket
How much can you actually fit in a context window? More than you’d think — and that’s exactly the trap. Claude models carry around 200K tokens today; a few models advertise a million. It looks infinite, so the instinct is to keep pouring in: the whole doc, the whole schema, every past turn, just in case. But everything competes for the same space, and one line item grows on its own — conversation history expands every single turn until it crowds out the room the model needs to actually think.
Track window utilization like you’d track memory in a hot service. If you don’t know roughly what fraction of the window a typical turn uses — and which line item is growing — you’re flying blind, and you’ll only find out when the agent falls off the cliff.
The failure mode: context rot
Two things go wrong as the window fills. The obvious one is overflow: you blow past the limit and the oldest turns get truncated — often the ones holding the original goal. The subtler one is nastier. Even within the limit, models don’t read every position equally: recall is strong at the very start and the very end of a long context and sags in the middle — the well-documented “lost in the middle” effect (Liu et al., 2023). Bury the one fact that matters halfway through 100K tokens and the model sails right past it, then hallucinates to fill the gap. In my experience the second failure is the one that quietly wrecks long sessions, because nothing errors — the agent just gets subtly, confidently wrong.
When an agent starts strong and degrades over a long session — repeating tool calls, losing the thread, ignoring an instruction it followed earlier — that’s almost never a model problem. It’s context rot. Reach for the four moves below before you reach for a bigger model.
The four moves
Context engineering is mostly the discipline of keeping the window small and relevant as work piles up. Four moves do the heavy lifting. They compose — a serious agent uses all four, and which one matters most is workload-dependent.
1 · Retrieve, don’t stuff
The instinct to dump the whole document, the whole schema, the whole wiki into the prompt “just in case” is the single most common mistake. More context is not more intelligence — past a point it’s more noise, more cost, and more middle for facts to get lost in. Retrieve the smallest sufficient slice, and prefer just-in-time retrieval: let the agent fetch what it needs when it needs it (a search tool, a file read) instead of front-loading everything. This is exactly the retrieval discipline from RAG, applied turn-by-turn inside an agent.
For example: instead of pasting an 8,000-line database schema into the system prompt, expose a describe_table(name) tool and let the agent look up only the two tables the query actually touches.
2 · Compact the history
When the conversation gets long, replace old turns with a summary of what happened and what was decided. A good compaction keeps the durable facts (the goal, key decisions, open questions) and drops the chatter (the ten tool calls it took to find one file). Claude Code does this automatically as the window fills; in your own loops you trigger it on a token threshold. The art is in what you keep — summarize too aggressively and you lose the thread; too little and you never reclaim space.
For example: forty turns of “read file → run test → read next file” collapse into a single line the agent carries forward — explored auth module; entry point is login.ts:42; tests pass.
3 · Offload to external memory
The window is working memory — fast, small, and wiped between sessions. Anything that must persist should live outside it: a scratchpad file, a task list, a notes document, a database. The agent writes state out and reads only the relevant piece back in when needed. A CLAUDE.md holding project conventions, a running PLAN.md, structured notes an agent updates as it works — all of these are context engineering. The window stays lean because the memory isn’t in it.
For example: an agent running a large migration keeps a MIGRATION.md checklist on disk and reads back only the next unchecked item — never the full history of everything it has already changed.
4 · Isolate in subagents
Some sub-tasks are context-hungry — searching a large codebase, reading twenty files to answer one question. Run them in a subagent with its own fresh window. The subagent burns whatever context it needs, then returns just the answer to the parent. The parent’s window never sees the mess. This is why multi-agent systems scale to work a single context could never hold: each agent gets a clean budget.
For example: “find every call site of the deprecated auth() helper” runs in a subagent that reads forty files and returns a twelve-line list — the parent’s window sees the list, never the forty files.
The four moves at a glance
| Move | What it does | Reach for it when… |
|---|---|---|
| Retrieve | Pull the smallest sufficient context, just in time | You’re tempted to paste a whole doc “just in case.” |
| Compact | Summarize old history into a running digest | The conversation is long and the goal is slipping. |
| Offload | Write durable state to files / external memory | Something must survive beyond this window or session. |
| Isolate | Give a context-hungry sub-task its own window | One step would flood the main window with detail. |
Putting it together: a refactor at minute 45
Picture a coding agent migrating an app off a deprecated auth library across a 300-file repo. By minute 45 it has made 60 tool calls. Whether it’s still useful comes down almost entirely to context engineering.
Without context engineering
The window is 80% full of raw file dumps and stale tool output. The agent re-reads auth.ts for the third time, forgets it already migrated the login flow, and re-does it — introducing a conflict. Classic context rot: it started strong and quietly fell apart.
With the four moves
Retrieve: a grep tool finds the 12 call sites instead of reading all 300 files. Compact: old exploration collapses to “migrated: login, signup; remaining: password-reset, oauth.” Offload: the checklist lives in MIGRATION.md. Isolate: “find all usages” ran in a subagent. At minute 45 the window is ~30% full and on-task.
Same model, same task, same 45 minutes. The only difference is what was allowed to occupy the window — and that difference is the whole ballgame.
Why this is the trend that matters
Every capability jump in agents this year — longer autonomous runs, multi-agent orchestration, agents that work for hours — is really a context-engineering story underneath. Bigger windows didn’t remove the problem; they raised the stakes, because now you can fit enough into the window to drown the model in it. The teams shipping reliable agents aren’t the ones with a secret prompt. They’re the ones who treat the window as a scarce, actively managed resource — retrieving, compacting, offloading, and isolating on every turn.
You’ll get more out of the model you already have by managing its context well than by waiting for the next one. The endgame is that good context engineering becomes invisible — the way you don’t think about your OS paging memory to disk, or a database planning a query. We’re not there yet; today it’s hand-tuned, and that’s exactly why it’s where the leverage is. It’s the layer between harness and loop engineering, and it’s worth learning on purpose.
That’s the model that’s worked for me — but the field is moving weekly, and if you’ve found a fifth move or a sharper framing, I’d genuinely like to hear it. Thanks to the practitioners whose write-ups shaped this piece.
Anthropic, “Effective context engineering for AI agents” (2025) — the definitive framing · Liu et al., “Lost in the Middle: How Language Models Use Long Contexts” (2023) — the position-recall finding · our companion posts on harness engineering, loop engineering, and skills vs subagents vs MCP.