Context engineering
Designing what an AI model actually sees — retrieval, memory, tools, user state — instead of writing ever-longer instructions. The discipline that succeeded prompt engineering.
01What it means
Context engineering is the practice of deciding what a model needs to know — and what it must never see — then assembling it from retrieval, memory, tools, and user state rather than paragraphs of instruction. The question stops being "what should I ask the model?" and becomes "what does the model actually need to know?" As models have gotten notably better at reasoning from context and intent, the leverage moved: prose stopped being the cheapest place to put knowledge.
The tell that context engineering is missing is a system prompt that keeps growing. Every rule in a bloated prompt is one of two things: a genuine preference (tone, format, boundaries — that belongs in the prompt) or a patch for missing information ("the customer's plan is X", "inventory updates arrive hourly") — context masquerading as instruction. Each patch is information the model should know, written down as behavior it is told to perform.
Deciding what the model sees is a design decision with consequences for accuracy, latency, cost, and confidentiality — judgment work that does not compress into a longer prompt no matter how well it is phrased. And when context changes silently — it always does — evaluations are what catch the drift. Context engineering without evals is just hope with extra steps.
02Why it matters for buyers
- —It is the difference between a reliable AI feature and a fragile one: what gets retrieved when, what memory persists, which tools answer which question — the plumbing, not the prose.
- —It has a direct audit question for vendors: "where does the model's context come from?" — a great prompt is a smell; a designed pipeline is an answer.
- —It is a security decision as much as a quality one: what a model must never see is as load-bearing as what it should know.
03Common questions
How is context engineering different from prompt engineering?
Prompt engineering perfects the asking; context engineering engineers the knowing. They coexist — preferences still live in prompts — but the leverage has moved to assembling what surrounds the prompt.
What are the components of context?
Retrieval (the right documents at the right moment), memory (what persists across turns), tools (what the model can ask at runtime), and user or session state — plus the deliberate exclusions.
How do you know context engineering is working?
Evals. Context changes silently as the systems around it change; only systematic evaluation distinguishes drift from improvement. Start with a handful of golden scenarios whose right answers you already know.