Context Engineering

01

Why this, why now

For two years the advertised skill of the AI era was prompt engineering: phrase the request just right and the model delivers. For agents that skill is quietly being retired, because a single clever prompt is not enough for a system that runs for fifty steps, calls tools and accumulates information as it goes. What replaced it is context engineering: deciding what the model sees at each step.

Here is the shift in one concrete example. A customer writes in: "Can I get a refund on the annual plan I bought three weeks ago?" The old way is a single prompt, where you paste the question and the refund policy and maybe the account details, and hope the model has what it needs in that one message. The context-engineered way is a system that assembles the right facts for this exact case: it looks up this customer's real account and purchase date, pulls the current refund policy, loads the specific rule for annual plans, checks whether a manager-approval threshold applies, and only then answers, escalating to a human if the rules say so. The difference is not a cleverer sentence. It is a system that gathers the right information, and only the right information, before the model speaks.

Andrej Karpathy, who did as much as anyone to popularise the term, defines context engineering as "the delicate art and science of filling the context window with just the right information for the next step." Shopify's Tobi Lütke pushed the same reframe, and Anthropic made it official with a guide titled "Effective context engineering for AI agents". This is part three of a five-part manual. Part one was the loop and part two the harness; context engineering is the craft living inside the loop's first phase, Gather, and it is where a large share of an agent's reliability is won or lost.

02

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 running longer than a single exchange, that skill has hit its limit, because an agent taking fifty steps and 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 producing its next response. Everything the model knows in the moment, the instructions and the question and any documents and the conversation so far, has to physically fit inside that window. The model cannot see your database or your wiki or last week's conversation unless something puts the relevant piece into the window first. It reasons 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, 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 in right now and which stay out.

03

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, and 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, as a tool returns a result and the user says something new and 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. To make it concrete, walk one step of the refund agent from the introduction:

One step, seen from the inside The customer asks about a refund. Before the model writes a word, the system decides what this step needs: the customer's account record (so it knows the plan and purchase date), the refund policy (so it knows the rules), and the last couple of messages (so it stays in the conversation). It deliberately leaves out the four-hundred-page product manual, the customer's unrelated support history from two years ago, and the company's internal pricing spreadsheet. None of that helps answer a refund question, and every piece of it would crowd the window and pull the model's attention off the point. The model then answers using exactly what it was handed.

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

04

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 and the system prompt and retrieved documents and tool outputs and memory and every prior turn, and the finite window, sits a curator deciding 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 rather than 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 rather than 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 clutter, because the useful conclusion has already been extracted and the model no longer needs the forty raw results. Leaving them in fills the window and buries what matters.

The counterintuitive part, and the thing separating 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.

05

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, and a typical modern window holds around two hundred thousand. The figures below are round numbers chosen to teach the mechanics rather than measurements of a specific system. Here is a healthy budget for the refund agent answering one question:

A healthy context window · refund agent, one stepCONTEXT WINDOW · 200,000 tokens total ────────────────────────────────────────────── system prompt + active skill (refund rules) ~2,000 customer account record + purchase date ~1,000 refund policy, the relevant section only ~1,500 last 4 messages of this conversation ~2,000 ────────────────────────────────────────────── used ~6,500 free room for the model to reason and answer ~193,500

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 reasoning that more context can only help:

A bloated context window · the naive buildCONTEXT WINDOW · 200,000 tokens total ────────────────────────────────────────────── entire product manual (dumped in "just in case") ~160,000 full 2-year support history for this customer ~28,000 company pricing spreadsheet, all plans ~9,000 the refund policy, buried on line 50,000 ~1,500 ────────────────────────────────────────────── used ~198,500 free room left for the model ~1,500

The second window technically contains the right answer, since the refund policy is in there somewhere, and it performs worse, 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 we see in real deployments, and it is why context engineering matters: the second builder did more work and got a worse system.

06

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, so 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, so 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 where a fact sits in the window matters, not just whether it is present, and 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 and abandoned attempts and old turns pile up, each one diluting the model's attention on what matters now. 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. Worth noting that "context rot" is practitioner terminology rather than a formal research finding, unlike lost-in-the-middle.

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 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.

07

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, so 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 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 in our experience 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, and a well-built agent should do the same with its own context.

08

7. Memory: context that persists

Everything so far happens inside one task. Context also has a time dimension, and its name is memory. A raw model starts every conversation from zero, so close the window and it forgets everything. A useful agent does not, and memory is the mechanism carrying relevant context across steps and across sessions, so the agent knows what it did yesterday and 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, whether a file or a database or a notes system, and the crucial move is that only the relevant slice gets pulled back into the window when it is needed.

Memory in practice A returning customer writes to the support agent. Long-term memory holds a short profile built from past interactions: "Enterprise customer since 2023. Had a data-migration issue in April, resolved by the integrations team. Prefers concise replies. Do not offer phone support, they have declined it twice." When this customer writes in, the agent pulls that profile into the window and greets them as the returning enterprise customer they are, instead of asking questions it should already know the answers to. The customer feels known. Nothing magic happened; the right memory was curated into the window at the right moment.

The trap is treating memory as a dumping ground and tipping a customer's entire history into the prompt, which is 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.

09

8. Retrieval: pulling the right context in

Memory answers what we already know about this situation. Retrieval answers what we know that is relevant, out of everything the organisation has ever written down. It is the mechanism that fetches the right documents or 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, meaning product manuals and policies and past tickets, are broken into small chunks and stored in a way that lets the system search them by meaning rather than only by keyword. When a question comes in, the system searches for the chunks most relevant to that specific question and drops a handful into the window. A question about refunds pulls the refund chunks, 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:

Two ways to retrieve The lazy build retrieves the twenty chunks most loosely related to the question and dumps them all in. Half are only vaguely relevant, the window fills, and the model, lost in the middle, sometimes answers from the wrong chunk. The careful build retrieves the three most relevant chunks, checks they actually address the question, compresses each to its key lines, and places them where the model will attend. Same underlying documents, same model. The second answers correctly far more often, costs less, and is easier to trust.

Retrieval is a supplier to the curator rather than a replacement for it. Fetching is only the first move, and selecting and compressing and placing what was fetched is the rest. The quality of an agent's answers tracks, close to 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.

10

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

So far the context has been facts: accounts, policies, documents, memories. 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:

A skill file · how to handle refunds--- name: refund-policy description: How to handle refund and cancellation requests. Use when a customer asks about refunds, cancellations, or getting their money back. --- # Handling a refund request 1. Check the purchase date on the account. 2. Within 14 days: approve a full refund. 3. Days 15-30: offer a pro-rated refund. Over EUR 500, get manager approval first. 4. After 30 days: no cash refund. Offer account credit instead. 5. Never promise the money back in under 5 business days. 6. If the customer is angry or mentions a chargeback, hand off to a human immediately.

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 and one for onboarding and one for handling a security report and one for the brand's tone of voice, with the agent only ever holding 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. The essence is simple though. 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.

11

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.

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 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, meaning product specs, policies, brand voice, the org chart. Written once, in one place.
• Memory: what has happened and been decided, meaning customer histories and past projects and the reasons behind past choices, accumulating over time.
• Live data: what is true right now, pulled on demand from the systems of record, whether the CRM or the ticket queue or inventory or 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 and the pricing facts and the brand voice live in the shared layer, and the sales agent and 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.

What "good" looks like A mid-sized company keeps its shared context in one governed place. Each fact has an owner and a "last reviewed" date, so nobody trusts a policy that has gone stale. Access is scoped: the support agent can read customer histories, the public website agent cannot. When the pricing team changes a plan, they update one record; by that afternoon the sales agent, the support agent and the internal help desk are all quoting the new price. A new agent built next quarter plugs into the same layer on day one instead of starting from an empty prompt. The context is treated as a product the company maintains, not as text pasted into a dozen tools.

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. 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 we think it is where the real durable value of enterprise AI gets decided.

12

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 an 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 and memory and retrieval and skills and 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. Context is where a generic model becomes your model.

13

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, with 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. 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.

14

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, which is expensive and slow. 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 and faster and more controllable, and it is where most enterprise AI value actually gets 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 See, Understand, Adopt 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 and compress and drop, and where your process floods the window instead of curating it. Then adopt by investing in the unglamorous plumbing, meaning clean data and good retrieval and real memory and written skills and a shared context layer, that decides what the model sees. It is less exciting than a new model and it matters more.

The move: stop perfecting the prompt and start engineering the context. Give the model the right slice of your data, curated and compressed, at the right step; capture your procedures as skills; build one shared, governed context layer every agent draws from; and cut everything that does not earn its place in the window.

15

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.

Back From the Future · BFF Insights · Working with AI · Part 3 of 5 · July 2026