Short answer
Context engineering is the work of deciding everything a language model sees before it answers, including instructions, retrieved documents, tool definitions, memory and conversation history, and assembling it fresh for each request. Prompt engineering, the craft of wording the request itself, is one part of that larger job.
Follow-up question What goes into an agent's context besides the prompt?
Over the past few weeks, "context engineering" has spread quickly among people who build with AI. Shopify's CEO, Tobi Lutke, said he preferred it to "prompt engineering" because it better describes the real skill: giving the model all the context it needs to have a fair chance at the task. Andrej Karpathy, a well-known AI researcher, agreed, and blog posts from LangChain's Harrison Chase and others have since tried to pin the idea down.
The shift in words reflects a shift in what people build. A prompt is the text you send to a model. A context window is everything the model can read in one go, measured in tokens (pieces of words). When you chat with ChatGPT, your prompt is most of what you control. When you build an agent, a program that lets a model use tools and take several steps, the prompt is a small slice of a context that your code puts together automatically, differently every time.
The difference in one table
| Prompt engineering | Context engineering | |
|---|---|---|
| Main question | How should I word this request? | What does the model need to see to do this task? |
| Unit of work | One piece of text | A system that gathers and arranges many pieces |
| When it happens | When you write the prompt | Every time the program calls the model |
| Typical fix | Clearer instructions, an example, a format | Add the missing data or tool, remove noise, summarize history |
Harrison Chase describes prompt engineering as a subset of the bigger job. Clear instructions still matter, but the other pieces matter just as much. His practical test is worth keeping: when an agent gets something wrong, ask whether it had the right information and tools. If not, the fix is in the context, not the wording. If it had everything and still erred, then the model or the instructions are the problem.
Simon Willison, a developer who writes widely about language models, makes a point about the words themselves. Many people hear "prompt engineering" as a grand name for typing into a chatbot, so it never conveyed the effort involved. "Context engineering" is harder to misread.
A worked example: one request, many parts
Take a small business assistant built on a model with tool access. A customer writes: "Can I move my Thursday appointment to next week?" Here is what a well-built system might place in the context before the model sees the message. The token counts are illustrative.
| Part | What it contains in this example | Approx. tokens |
|---|---|---|
| System prompt | Role, tone, business rules ("never book outside opening hours") | 400 |
| Tool definitions | find_booking, list_free_slots, move_booking, each with its inputs | 600 |
| Long-term memory | This customer prefers mornings and uses first names | 50 |
| Retrieved documents | The rescheduling policy: 24 hours' notice, no fee | 150 |
| Conversation history | The last three messages, or a short summary of older ones | 200 |
| User prompt | The customer's question | 20 |
| Output format | Reply text plus a structured action, if any | 80 |
The customer's own words are about 20 tokens out of roughly 1,500. The rest decides whether the reply is useful. Without the policy, the model may invent a fee. Without the memory, it may offer afternoon slots. Without the list_free_slots tool, it can only guess what is available.
Philipp Schmid, an AI engineer who writes about agents, gives a similar example in his overview: an assistant answering a quick meeting request does far better when it can also see your calendar, past emails with that person and a tool to send an invite.
Try it: Pick a task you hand to ChatGPT often. Before you write the prompt, list in a table what a helpful colleague would need to know: facts, documents, preferences, earlier decisions. Paste the relevant ones into the chat with your request, then compare the answer with what you get from the bare request.
Principles that carry over to everyday use
Even without writing code, the habits transfer. Give the model the facts it cannot know; it cannot read your mind or your files. Prefer a short, relevant summary to a long dump, since clutter competes with what matters. Format matters too: a tidy list of opening hours is easier for a model to use than a pasted web page. And when a conversation has wandered, a fresh chat that starts with a clean summary often works better than a long, tangled history.
What goes into an agent's context besides the prompt?
Most descriptions list the same building blocks. The system prompt holds standing instructions: role, rules, tone and sometimes examples. Tool definitions describe each function the agent may call, with its name, purpose and inputs, so the model knows what it can do and how to ask for it. Retrieved information, often called RAG (retrieval-augmented generation), is text fetched from documents, databases or the web for this request.
Then there is memory. Short-term memory is the conversation so far, including the results of earlier tool calls, often compressed into a summary when it grows long. Long-term memory is what the system stores across sessions, such as a user's preferences. Finally, an output definition tells the model what shape its answer must take, for example a JSON object that the program can read.
The engineering lies in choosing among these for each step. Everything included costs tokens and attention, and anything missing becomes a guess. A good agent loads what the next step needs, leaves out what it does not, and keeps the instructions clear enough that the model knows what to do with the rest.
Sources
- The rise of "context engineering" — LangChain Blog (Harrison Chase), June 23, 2025
- The New Skill in AI is Not Prompting, It's Context Engineering — Philipp Schmid, June 30, 2025
- Context engineering — Simon Willison's Weblog, June 27, 2025