Context engineering
A context window is not a brain. It is a delivery mechanism for the right knowledge at the right moment. This page treats context as something you design for — not something you hope the model will make sense of.
What is context engineering?
Context engineering is the discipline of designing what an agent sees, in what shape, at what moment — so that the agent can act on the right knowledge without being buried in the wrong knowledge. It is the applied form of the knowledge-layer argument. The context window is not a storage surface; it is a delivery surface, and it should be engineered like one.
From prompt to context
The old framing was "prompt engineering" — write the right words and the model will do the right thing. The new framing is "context engineering" — design the knowledge the agent sees, because the agent's behavior is mostly determined by the knowledge it has in front of it, not by the words you use to ask it to do something.
This is not a change in vocabulary for its own sake. It is a change in where the leverage is. The leverage is no longer in the prompt. It is in the knowledge that the prompt is acting on. A perfect prompt on top of the wrong knowledge is still wrong. A mediocre prompt on top of the right knowledge, in the right shape, at the right moment, is often enough.
Context engineering is the discipline that turns "the model is smart" into "the model has the right knowledge in front of it."
What a context window actually is
A context window is a limited, ordered, retrievable surface. It is not a working memory in the human sense. It is not a place where the model thinks. It is the knowledge the model has in front of it at the moment it acts.
That is a delivery problem, not a storage problem. The question is not "how much can we fit" but "what does the agent need at this moment, in what shape, and how do we get it there without also sending the wrong knowledge."
This sounds obvious. It is still the most common mistake. The instinct is to pack the context with everything the agent might need and let the model sort it out. The model can sort. It cannot be charged for sorting the wrong thing, and it cannot be trusted to find the current authoritative version of something buried in a bucket of other things.
The patterns
Context engineering is a set of patterns for packing the right knowledge at the right moment. These are not tricks. They are the applied form of the knowledge-layer disciplines.
Send less of the right knowledge
The cheapest context is the one that does not carry knowledge the agent will not use.
- Problem
- The bucket instinct — dump everything in and let the model sort it out — is the cheapest way to make an agent both more expensive and less dependable.
- Pattern
- For each action the agent might take, decide what knowledge it actually needs, in what shape, and pack only that. Not the whole document. The procedure, the current value, the permission. The rest can wait until it is needed, or it can stay out of the context entirely.
- Trade-off
- More design work up front. Less cost and less confused behavior at runtime. The trade-off is usually worth it the moment the agent is doing something expensive or sensitive.
Make currentness explicit
The agent must be able to tell what is current — not by guessing, not by assuming the latest document is the latest truth.
- Problem
- A context packed from documents does not carry currentness with it. The agent reads the procedure and has no way to tell whether it is the current one, the retired one, or the draft.
- Pattern
- Carry currentness as a property of the knowledge in the context — the version, the date, the owner who says this is the one, the explicit statement that this supersedes the previous version. Make the agent able to check, not assume.
- Trade-off
- A little more structure in the knowledge layer. A lot more credibility in the agent's actions. This is the discipline that turns "the agent read the document" into "the agent read the current document."
Separate what the agent can see from what it can act on
The boundary between visibility and action must be explicit — especially in enterprise and personal settings.
- Problem
- An agent that can see a piece of knowledge is not the same as an agent that can act on it. The knowledge may be real, may be current, may be in the context — and still not be something the agent is allowed to act on.
- Pattern
- Carry permission and scope as a property of the knowledge in the context. The agent should be able to see the knowledge it needs to reason about, and should be blocked from acting on the knowledge it is not allowed to act on. The two are not the same, and the context should not blur them.
- Trade-off
- More discipline in the knowledge layer, and more explicitness about the boundary. The payoff is an agent that can reason over what it sees without being trusted to act on what it should not.
Make the basis retrievable
When the agent acts, it should be able to show what knowledge it used — and whether it was current and permitted.
- Problem
- An agent that acts on a context it cannot reconstruct later is not auditable. The company cannot tell what knowledge the agent used, whether it was current, or whether it was permitted. This is the failure mode that hurts trust at the moment it matters most.
- Pattern
- Carry the basis with the action — what knowledge was used, from where, in what shape, at what version, with what permission. Not as a separate forensic step. As part of the action itself. The same discipline that makes the agent auditable also makes it cheaper, because it stops the agent from re-reading the same knowledge again and again.
- Trade-off
- A little more structure in the action. A lot more trust. Grounding and token savings are the same discipline seen from two sides.
Stage the context for the action
Context is not one thing. It is a sequence of surfaces, each tuned for the action the agent is about to take.
- Problem
- A single context for the whole conversation is the bucket instinct again — everything in one place, nothing tuned for the action. The agent pays for the whole conversation every time it acts, and it acts on whatever is in front of it at the moment.
- Pattern
- Stage the context for the action. The agent's first look is a small, current, permitted surface — enough to decide what to do next. The deeper knowledge is brought in only when the agent is about to act on it, and only the knowledge it needs for that action. The rest of the conversation is still there, but it is not in the way.
- Trade-off
- More design work, more explicitness about what the agent needs at each stage. The payoff is an agent that is cheaper to run and less likely to act on the wrong thing.
What context engineering is not
- It is not prompt engineering. Prompts still matter, but the leverage is in the knowledge, not the words.
- It is not stuffing the context with more of everything. That is the bucket instinct, and it is the cheapest way to make the agent worse.
- It is not a model trick. It is a knowledge discipline, applied to the surface the model sees.
- It is not a separate layer from the rest of the knowledge work. It is the point where the knowledge layer meets the agent — where representation, currentness, ownership, deprecation, permission, and grounding all come together in the shape the agent actually reads.
Where to start
If you are building an agent and you are wondering how to engineer its context, the usual sequence is:
- Pick one action the agent will take — not the whole conversation. One action.
- List the knowledge that action actually needs — not everything it might need, the knowledge it needs for that action.
- Put currentness, ownership, and permission on that knowledge before it goes into the context. Not after. Before.
- Pack only that knowledge, in the shape the agent can use, with the basis attached.
- Make the rest of the conversation available but not in the way — staged, not dumped.
The goal is not a perfect context. The goal is a context that delivers the right knowledge at the right moment, in a shape the agent can use, without the wrong knowledge in the way. The patterns above are the starting points. The rest is the specific knowledge your agent is acting on.
FAQ
RAG is one way to get knowledge into a context. It is not the whole of context engineering. Context engineering is the discipline of what the agent sees, in what shape, at what moment — retrieval is one part of that, and a part that is often done badly when the only question is "what does the agent need to read." The knowledge layer is what makes retrieval dependable: current, owned, grounded, permitted. Retrieval without that layer is just search with an agent attached.
Longer contexts make the bucket instinct cheaper, not better. The more context you have, the more important it is to know what is current, what is owned, what is permitted, and what the agent actually needs at this moment. A long context full of the wrong knowledge is a more expensive version of the same problem. The discipline does not go away when the context gets longer; it gets more important.
The discipline is clearest for agents, because agents act and the cost of wrong knowledge is an action, not a sentence. But the same discipline applies wherever a model is given a context and asked to do something with it. The context window is always a knowledge-delivery surface. Designing it as one is the point.