Context engineering: the discipline that decides whether your agent works

A new term has taken hold, and unlike most industry vocabulary it names something real: context engineering. The idea, articulated well by Philipp Schmid among others, is that the useful unit of work has moved from the prompt to the context. Context engineering is the discipline of building dynamic systems that supply a model with the right information and tools, in the right format, at the right time, so it can actually accomplish the task. It sounds abstract; it's the most practical lens I know for why LLM systems succeed or fail.

Prompt engineering was too small a frame

Prompt engineering treats the problem as writing one perfect instruction string. That's a real skill, but it describes a static artifact. Context engineering describes a system: the thing that runs before the model call and decides, for this specific request, what the model gets to see. The prompt is now just one input among several, and the interesting work is the assembly around it.

What 'context' actually is

Context isn't just the prompt — it's everything in the window when the model runs. It's worth naming the parts, because each is a lever you engineer:

• Instructions / system prompt — the model's role, rules, and behavioural examples.
• User prompt — the immediate task or question.
• State / history — the conversation so far and prior turns.
• Long-term memory — durable facts that persist across conversations (preferences, entities, past decisions).
• Retrieved information (RAG) — external, current data pulled from documents, databases, or APIs.
• Available tools — the function definitions the model can call to act.
• Output schema — the structure you require the response to take, when code will consume it.

Why it decides success

Here's the reframe that makes context engineering click. As Philipp Schmid puts it, "most agent failures are not model failures anymore, they are context failures." The model is usually capable; it just wasn't given what it needed. Take a scheduling assistant: hand it only the raw request — 'can you find time with Priya next week?' — and it can produce a plausible but useless reply. Hand it the same request plus your calendar, the recent email thread, Priya's contact details, and a tool to send an invite, and the same model produces something that feels magical. Nothing changed but the context.

The four properties of good context

• Systematic — context is the output of a system you built, not a static template you typed once.
• Dynamic — it's assembled on the fly, tailored to the specific request rather than one-size-fits-all.
• Selective — it supplies the right information and tools at the right moment, not everything all the time.
• Format-conscious — how you present the context (structure, ordering, a clean schema) matters as much as what you include.

It's the umbrella over every LLM skill

Context engineering isn't a new technique so much as the frame that connects the ones you already know. The context window is the budget you're spending. Retrieval (RAG) is how you select external information. Memory — a sliding window, a rolling summary, retrieved long-term facts — is how you carry state without blowing that budget. Tools and structured outputs are context too. Even good prompting is one input to the assembly. Each of those has its own post here; context engineering is the discipline of composing them deliberately for a given task.

How to get better at it

• Treat context as a system to design, not a prompt to tweak — the leverage is in what you assemble, not in one clever sentence.
• Retrieve and select, don't dump — more tokens isn't more context; relevant tokens are.
• Format for the model — front-load the stable stuff, structure the rest, and make schemas explicit.
• Curate against the budget — the window is finite, so decide what earns its place (what you leave out matters as much as what you include).
• Measure what's actually in the window — when an answer is wrong, inspect the assembled context before you blame the model.

This is also why building serious LLM products feels less like 'prompting' and more like engineering: the hard, valuable work is the pipeline that gathers, filters, and formats context for each call. Credit where due — Philipp Schmid's write-up on context engineering is a clear articulation of this shift, and worth reading alongside this.

The model rarely fails you. The context you handed it does. Engineer that, and most of the 'magic' takes care of itself.