Context Engineering: The Skill That Ate Prompt Engineering
As models got better at following instructions, the hard part moved from wording the prompt to assembling the right context. What context engineering is, its building blocks, and why minimal beats maximal.
Guillaume Rufenacht
AI Product Manager · Lisbon
Ask an AI travel agent to book a hotel in Paris and it might cheerfully book you one in Paris, Kentucky. That’s not a prompt problem, it’s a context problem. As models got better at following instructions, the hard part of building with them shifted from wording the prompt to assembling the right context around it. That discipline is context engineering, and it’s where most production AI work actually lives now.
Here’s what it is, what goes into it, and the counterintuitive rule that keeps it from backfiring, drawn from how I build the LLM pipelines behind Geonimo.
Key takeaways
- Prompt engineering is wording the instruction. Context engineering is assembling everything the model sees: prompt, retrieved docs, memory, and tools.
- The building blocks are memory, state, retrieval (RAG), and tool interfaces, with the prompt populated dynamically at runtime.
- In production, the final prompt is often mostly dynamic context and only a little static instruction.
- More context isn't better. Assemble the minimum sufficient context and let the model retrieve the rest.
Prompt engineering vs context engineering
Prompt engineering is the craft of wording the instruction itself, role assignment, a few examples, chain-of-thought, explicit constraints. It gives you better questions. Context engineering is the system-level discipline of programmatically assembling everything the model sees during inference so it can plausibly accomplish the task. It gives you better systems. The Paris example is the whole point: a smarter context, a calendar lookup, the company travel policy as a file, would have prevented both the wrong city and the $900 room, no cleverer wording required.
The building blocks
Context engineering orchestrates the whole environment around the model. The core components:
- Memory. Short-term (summarizing long conversations to stay in the window) and long-term (a vector store of preferences, history, learned patterns).
- State. Where you are in a multi-step process, did the flight booking succeed, what’s the arrival time, so the agent doesn’t lose the thread mid-task.
- Retrieval (RAG). Pulling only the relevant sections of a knowledge source, not the whole document, via hybrid semantic and keyword search.
- Tools. The interfaces that let the model actually do things, with descriptions that specify what each does, when to use it, and its constraints.
Prompt engineering is itself part of context engineering: you write a base instruction, then inject live context at runtime so the final prompt might be 80% dynamic content and 20% static instruction. The art is wording; the system is everything around it.
The counterintuitive part
Why this is the real work now
As models improve, raw prompting matters less and the system around the model matters more. Most “the model hallucinated” bugs are really “we surrounded it with the wrong context” bugs, the wrong documents, a stale memory, a missing tool. Getting memory, state, retrieval, and tools right is what separates a demo from something dependable, and it pairs directly with prompting as an engineering discipline, which I cover in the Claude Code prompting playbook and the simplicity principles in building effective agents.
The takeaway
Designing context for production LLM systems is the core of what I do at Geonimo. See how I build or get in touch.
Frequently asked questions
What's the difference between prompt engineering and context engineering?
Prompt engineering is wording the instruction. Context engineering is the system-level discipline of assembling everything the model sees, prompt, retrieved documents, memory, and tools, so it can plausibly do the task.
What goes into context engineering?
Memory (short and long term), state across multi-step tasks, retrieval (RAG returning only the relevant sections), and tool interfaces with clear descriptions, plus the prompt itself, populated dynamically at runtime.
Should I give the model more context or less?
Enough, and no more. Assemble the minimum sufficient context and let the model retrieve the rest. Over-stuffing context micromanages the model and dilutes its attention.
Work with me
Want a system like this built for your pipeline?
I help teams take AI from a clever prototype to dependable production, outbound engines, lead intelligence, and the LLM pipelines underneath. See what I have shipped or get in touch.