The conversation around large language models has shifted, and for good reason. Thomas Betts and Adi Polak articulate a distinction that matters more than most practitioners realize: prompt engineering is a stateless exercise, while context engineering is inherently stateful. We agree, and we think this is the difference between treating AI as a parlor trick and treating it as a genuine partner in complex work.
Here is what that means for you, practically. When you rely on prompts alone, you are essentially asking a model to solve a problem with no memory of how it got there. Each interaction is a fresh start, which forces you to cram all the relevant background, constraints, and history into a single request. That approach works for simple queries, but it collapses under the weight of real-world tasks. Context engineering, by contrast, builds a persistent frame around the model's interactions. It lets the system carry forward the relevant state, so the model is not just answering a question but reasoning within an evolving situation. This is not a minor technical nuance; it is the difference between a tool that answers and a system that understands.
The practical takeaway for teams building with LLMs is that your design effort should move upstream. Instead of obsessing over the perfect prompt, focus on how you structure, retrieve, and maintain context across a session. This means thinking about memory, about how prior decisions inform current queries, and about how to give the model a coherent narrative of the work at hand. Polak's point is that the intelligence is not just in the model's weights; it is in the context you provide. The more deliberate you are about that context, the more reliable and useful your AI systems become. This is a call to change your architecture, not just your wording.
We should stop treating prompt engineering as the ceiling of our ambition. It is a starting point, a way to get a model to respond, but not a way to get it to perform. Context engineering is what allows AI to move from isolated answers to sustained, multi-step problem solving. If you are building agentic systems, this is the difference between a demo and a deployment. The next time you sit down to design an interaction, ask yourself not "What should I say?" but "What does the model need to know, and how do I keep that knowledge alive?" That question will lead you to smarter systems, and it is the one worth asking now.