Everyone learned to write prompts. The skill that now matters is managing what the model sees.

1. Why now: prompt engineering is retiring

The advertised skill of the early AI era was phrasing: say it the right way and the model performs. For anything that runs longer than a single exchange, that skill has hit its limit. An agent taking fifty steps, calling tools and piling up information cannot be steered by one perfect sentence. The steering now happens in the context.

It helps to be precise about what "context" means here, because the word gets used loosely. The context window is the working memory of a model: the full block of text it can look at while it produces its next response. Everything the model knows in the moment, the instructions, the question, any documents, the conversation so far, has to physically fit inside that window. The model cannot see your database, your wiki or last week's conversation unless something puts the relevant piece into the window first. It reasons only over what is in front of it, and nothing else.

That single fact is the whole reason context engineering exists. If the model can only use what is in the window, then the quality of its answer is capped by the quality of what you put there. Prompt engineering was the craft of writing one good block of text into that window by hand. Context engineering is the craft of deciding, automatically and at every step, which pieces of a much larger world get loaded into the window right now and which stay out. The reframe has real authority behind it: Karpathy named it, Tobi Lütke championed it, and Anthropic wrote the guide. This dossier walks through the craft, with worked examples, and lands on why, for a business, context is the part of the AI stack that is inherently yours.

2. Prompt engineering versus context engineering

The cleanest way to see the shift is to put the two side by side.

Prompt engineering treats one input as the unit of work. You assemble a role, some context, instructions, examples and a format into a single message. When the answer disappoints, the skill is spotting which ingredient let you down and rewriting it. That is enough for a one-shot question you ask once and read once.

Context engineering treats the window as the unit of work, across many steps. The information available keeps growing, a tool returns a result, the user says something new, a document is retrieved, while the window stays a fixed size. So something has to decide, at every step, what goes in and what stays out. That something is what this dossier is about. To make it concrete, walk one step of the refund agent from the introduction:

That decision, repeated at every step, is the whole game. Prompt engineering asks "how do I word this?" Context engineering asks "what does the model need to see right now, and what should I keep out?" The second question is the one that scales to real work.

3. The curator: select, compress, drop

The mental model that makes this concrete is a curator. Between everything available to the agent, the user's query, the system prompt, retrieved documents, tool outputs, memory, and every prior turn, and the finite window sits a curator that decides what the model actually gets to see this step.

The curator does three things: select, compress, drop. Each is worth seeing with an example.

Select: choose what belongs

Selection is deciding which of the many things you could show the model this step actually earn their place. For the refund agent, selecting means pulling this customer's account and the refund policy, and not the whole knowledge base. Selection is often the difference between a system that feels sharp and one that feels vague: a legal agent reviewing a contract should be handed the three clauses relevant to the question, not all ninety pages, because ninety pages of mostly-irrelevant text is how you get a confident answer about the wrong clause.

Compress: shrink what is bulky but useful

Compression is taking something you do need but which is too big, and reducing it to the part that matters. A support agent does not need the full transcript of a customer's forty previous tickets; it needs a three-line summary: "long-time customer, had a billing dispute in March that was resolved, prefers email." That summary might be two hundred tokens standing in for twenty thousand. Done well, compression keeps the signal and throws away the bulk.

Drop: throw away what has gone stale

Dropping is removing what no longer earns its place. Ten steps into a task, the raw output of a search the agent ran at step two is usually just clutter, the useful conclusion has already been extracted, and the model no longer needs the forty raw results. Leaving them in does not help; it fills the window and buries what matters.

The counterintuitive part, and the thing that separates good context work from bad, is that it is mostly about what you throw away. Packing more in feels safe and is usually wrong. A curator's real skill is subtraction: knowing what the model does not need to see, so that what it does need stands out.

4. What actually sits in the window

To make all of this tangible, it helps to look at what a context window actually contains during one step of real work, and how big each piece is. Sizes are measured in tokens, roughly three-quarters of a word each; a typical modern window holds around two hundred thousand tokens. Here is a healthy budget for the refund agent answering one question:

Small, focused, and the model has all the room it needs to think. Now here is the same task built the naive way, by someone who reasons "more context can only help":

The second window technically contains the right answer, the refund policy is in there somewhere, but it performs worse, and often much worse. The policy is buried among a hundred and ninety thousand tokens of noise, the model has almost no room left to reason, and it costs thirty times as much per call. This is the single most common mistake in real deployments, and it is why context engineering matters: the second builder did more work and got a worse system. The next section explains exactly why more context hurts.

5. The window is finite, and more is not better

Why does the bloated window perform worse when it literally contains more information? Because a context window is a fixed budget, and three forces turn a full one against you.

The budget is finite. Every token you spend on background is a token the model cannot spend on reasoning. Fill the window with a manual and there is no room left to think through the actual question.

Models get lost in the middle. This is a real, measured effect: a model pays most attention to the start and the end of its context and least to the middle. A crucial fact buried halfway down a long document is often simply missed, the same way you skim the middle of a long email and catch only the top and the sign-off. Researchers documented this and named it "lost in the middle." It means that where a fact sits in the window matters, not just whether it is present. The refund policy on line fifty thousand of a bloated window is technically there and practically invisible.

Context rots. As an agent runs, stale tool outputs, abandoned attempts and old turns pile up. Each one dilutes the model's attention on what actually matters now. More broadly, quality can slip simply as the window grows longer, even before it is full, which is why the term describes length as much as staleness. A window that started clean degrades over a long task unless something actively prunes it, the way a desk buried under every document you touched this week becomes useless even though the one you need is on it somewhere.

Put together, these mean a window stuffed with noise performs worse than a short window holding exactly the right facts. This is why the context-window gauge, a meter showing something like sixty-four thousand of two hundred thousand tokens used, has become a number that practitioners watch as closely as latency or cost. When it creeps toward full, quality falls, and the fix is almost never a bigger window; it is better curation.

6. Correct or rewind: what you remove matters

One technique makes the discipline tangible: how you handle a wrong turn. When an agent goes down a bad path, there are two ways to recover, and they leave the window in very different states.

Picture a coding agent asked to fix a bug. It reads three files, writes a fix, runs the tests, and two of them fail. It tries a second fix, and one still fails. Then it finds the real cause and fixes it properly. There are now two ways to carry on.

Correcting leaves the whole history in the window: the three file reads, the first broken fix, the failing tests, the second broken fix, the still-failing test, and finally the working fix. It works, and the window now carries a long record of the mess, and every later step has to reason around two dead ends that no longer matter. Worse, the failed attempts sit in the context as examples of what the code looked like, and the model can get confused about which version is current.

Rewinding throws away the failed branch entirely. Once the real fix is found, the system keeps only the clean path, the file reads and the working result, and deletes the two dead ends from the window as if they never happened. The window stays lean, and the model reasons over the answer rather than the detour. Rewinding is more work to build, and it is almost always the better strategy. It is the clearest example of the rule that what you remove is as important as what you keep. A human takes notes and throws away the scratch paper; a well-built agent should do the same with its own context.

7. Memory: context that persists

Everything so far happens inside one task. But context also has a time dimension, and its name is memory. A raw model starts every conversation from zero: close the window and it forgets everything. A useful agent does not, and memory is the mechanism that carries the relevant context across steps and across sessions, so the agent knows what it did yesterday, what your preferences are, and what it has already tried.

It helps to split memory into two kinds. Short-term memory is what the agent carries within a single task, the working notes it keeps as it goes. Long-term memory is what survives after the task ends and is available next time: a customer's preferences, a decision the team made three months ago, the fact that a particular fix did not work last time. Long-term memory usually lives in storage outside the model, a file, a database, a notes system, and the crucial move is that only the relevant slice gets pulled back into the window when it is needed.

The trap is treating memory as a dumping ground, tipping a customer's entire history into the prompt. That is just the bloated window again, wearing a different hat. Good memory is itself a curation problem, subject to the same select, compress, drop discipline, only now across time: keep the durable facts, summarise the episodes, and pull only what this moment calls for. Done well, memory makes an agent feel like it is accumulating competence. Done badly, it is noise with a longer reach.

8. Retrieval: pulling the right context in

Memory answers "what do we already know about this situation?" Retrieval answers "what do we know that is relevant, out of everything the organisation has ever written down?" It is the mechanism that fetches the right documents, records or facts from outside the model and places them in the window. This is the idea behind retrieval-augmented generation, usually shortened to RAG, and it remains the workhorse of most real deployments, because it grounds the model in your data rather than its training.

Here is how it works, plainly. Your documents, product manuals, policies, past tickets, are broken into small chunks and stored in a way that lets the system search them by meaning, not just by keyword. When a question comes in, the system searches for the chunks most relevant to that specific question and drops a handful of them into the window. So a question about refunds pulls the refund chunks, and a question about setup pulls the setup chunks, and the model answers each grounded in the right source material.

Context engineering reframes retrieval, though, and the reframing matters. The goal is precise retrieval rather than maximal: fetch exactly what the step needs and no more. Compare two builds of the same support agent:

Retrieval is a supplier to the curator, not a replacement for it. Fetching is only the first move; selecting, compressing and placing what was fetched is the rest. The quality of an agent's answers tracks, almost one to one, the quality of what its retrieval puts in front of it, which is why "just add RAG" so often disappoints and why doing retrieval carefully so often works.

9. Skills: teaching an agent a procedure, on demand

So far the context has been facts: accounts, policies, documents, memories. But a model also needs to know how to do things, the procedures and conventions specific to your business, and that is what a skill is.

A skill is a self-contained package of instructions for one kind of task, that the agent loads only when that task comes up. Think of it as a short playbook the agent can pull off a shelf. In its simplest form it is a small text file with three parts: a name, a one-line description of when to use it, and the actual instructions. Here is a real-shaped example:

Two things about this are worth dwelling on, because they are the whole point.

The description is the trick. The agent does not carry the full instructions of every skill at all times. It carries only the one-line descriptions, a tiny cost, and reads the full body of a skill only when the description matches what is happening. This is called progressive disclosure, or just-in-time loading: the refund instructions enter the window the moment a refund question appears, and stay out of it the rest of the time. It is the select-and-drop logic from the curator, applied to the agent's own instructions.

It solves the giant-system-prompt problem. The tempting alternative is to write one enormous set of instructions, every rule for every situation, and hand it to the model on every single call. That fails for exactly the reasons in section five: it fills the budget, buries the rule that matters under fifty that do not, and dilutes the model's attention. Skills keep the working window small and load the right procedure at the right moment. A company might have fifty skills, one for refunds, one for onboarding, one for handling a security report, one for the brand's tone of voice, and the agent only ever holds the two or three relevant to the task in front of it.

Skills can hold more than a checklist: a worked example, a template to follow, even a small script the agent runs. But the essence is simple. A skill is how you teach an agent a specific way of doing something once, in plain language, and have it apply that knowledge only when it is relevant, without paying for it the rest of the time.

10. Shared context across an organisation

Everything so far has been about one agent. The bigger prize, and the harder problem, is context at the scale of a whole organisation. What does it look like when a company gets this right?

Start with what getting it wrong looks like, because it is everywhere. The sales team has pasted its own version of the pricing rules into its own chatbot. The support team has a different version in theirs. Someone in onboarding wrote a third. The refund policy changed in March, and two of the three still quote the old one. A customer asks the same question in two places and gets two different answers. Every team is doing context engineering, badly and in isolation, and the results drift apart.

A company that gets this right builds a single shared context layer that every agent, and often every employee, draws from. It has three layers underneath it:

• Durable facts: the things that are true until someone changes them, product specs, policies, brand voice, the org chart. Written once, in one place.
• Memory: what has happened and been decided, customer histories, past projects, the reasons behind past choices, accumulating over time.
• Live data: what is true right now, pulled on demand from the systems of record, the CRM, the ticket queue, inventory, billing.

On top of those sits the curation, the same select, compress, drop, deciding which slice each agent gets for each task. The refund skill, the pricing facts and the brand voice live in the shared layer, and the sales agent, the support agent and the onboarding agent all read from them. Change the refund policy once, in one place, and every agent's answer changes with it, at the same moment. That consistency is the payoff.

This is the organisational version of the finite window. A company has a vast amount it could tell its AI, and, exactly like a single window, dumping all of it into every agent makes them worse, not better. The work is deciding what each agent should see, keeping it current, and maintaining it in one place. It is unglamorous, it is mostly governance and plumbing, and it is where the real, durable value of enterprise AI is decided.

11. Context is the product now

Put these together and a strategic point emerges. If the model is a commodity and the harness is the machine, context is the fuel, and increasingly it is the product. Two companies using the identical model and a similar harness will get very different results based on one thing: the quality of the context each can assemble, its data, its memory, its retrieval, its skills, its curation.

That is good news for most businesses, because context is the one part of the stack that is inherently yours. Your documents, your records, your institutional memory, the specific facts of how your business runs, none of it is in the model, and none of it is available to a competitor. A rival can buy the same model tomorrow. It cannot buy your twenty years of customer history, your hard-won policies, or the shared context layer you spent a year getting clean. The company that can get the right slice of its own context in front of a model at the right moment has an advantage that no model upgrade hands to everyone at once. Context is where a generic model becomes your model.

12. The honest counter-case

Three qualifications keep this honest. First, longer context windows are real and they help; the window keeps growing, and some problems that needed careful curation in 2024 fit comfortably today. A bigger budget does not repeal the lost-in-the-middle effect or the cost of noise, though; it raises the ceiling without removing the discipline, and a bigger window filled carelessly still performs worse than a small one filled well.

Second, context engineering can itself be over-engineered: elaborate retrieval and compression pipelines that cost more than they return, and add moving parts that break. Sometimes the right answer is a bigger window and a simpler pipeline, and part of the skill is knowing when your curation is earning its keep and when it has become its own kind of bloat.

Third, the frontier moves. As models get better at managing their own context, deciding for themselves what to keep and what to forget, some of this work will move inside the model, and the line between context engineering and the harness will keep shifting. None of that changes the core claim, though. For any agent doing multi-step work today, the single largest lever on quality, once you have a capable model and a working harness, is the context you put in the window. Get that right and mediocre prompts still work. Get it wrong and the best prompt in the world is reasoning over garbage.

13. What a business does with this

For a leader, context engineering reframes where the value of your data actually lives. The instinct is to think the model needs to be trained on your data, an expensive and slow proposition. Usually it does not. It needs the right slice of your data placed in the window at the moment it is working, which is cheaper, faster, more controllable, and where most enterprise AI value is actually realised.

Concretely, that points at a short list of investments, and none of them is a new model. Get your data clean and findable, because retrieval can only surface what is well organised. Build the shared context layer described in section ten, with owners and freshness dates, so every agent draws from one current source. Write your key procedures as skills, in plain language, so the how-to of your business is captured once and loaded on demand. And measure what your agents are actually being shown, because a context problem hides as a model problem until you look in the window.

This is the See, Understand, Adopt method applied to information. See that the model's answer is only as good as what you put in front of it. Understand the three moves of the curator, select, compress, drop, and where your process floods the window instead of curating it. Then adopt by investing in the unglamorous plumbing, clean data, good retrieval, real memory, written skills, a shared context layer, that decides what the model sees. It is less exciting than a new model, and it matters more.

14. Verification and sources

This dossier draws on live web research and a personal archive of more than 15,000 sources. Load-bearing claims were cross-checked where possible. The worked examples are illustrative, built to explain the mechanics rather than to describe a specific named company. The notes below flag confidence and the main caveats, in the spirit of showing our work.

The framed figure in this dossier is taken from publicly posted material, credited to the original source in its caption. Charts labelled "BFF" are our own, drawn from the sources named beneath them. Example files and budgets are illustrative, written to teach the idea.