When Andrej Karpathy posted about "context engineering" in June 2026, it landed because it named something practitioners had been fumbling toward for years. The terminology had been fuzzy. Now there's a clean line.
This guide draws that line precisely — not to be pedantic, but because knowing which problem you're solving determines which tools you reach for.
The core distinction
Prompt engineering is the discipline of writing better individual messages to get better responses from a language model. It covers techniques like chain-of-thought, few-shot examples, role assignment, and structured output instructions. The unit of work is a single message or message pair.
Context engineering is the discipline of designing the full package of information the model conditions on — everything it sees before generating a response. The unit of work is the entire context window: system prompt, conversation history, retrieved documents, tool definitions, tool outputs, safety constraints, and the logic that assembles them.
Here is the shortest possible summary:
Prompt engineering asks: "How do I word this message?" Context engineering asks: "What does the model need to see, and how should it be arranged?"
A brilliantly worded prompt in a poorly assembled context still produces poor results. Context engineering is the outer layer.
What lives in a context window
Before going further, it's worth being concrete about what "the context package" actually contains:
| Component | What it contains | Who controls it |
|---|---|---|
| System prompt | Role, success criteria, output format, behavioral rules | You |
| User message | Current task or question | User / application |
| Conversation history | Prior turns from this session | Accumulated, then pruned |
| Retrieved documents | RAG outputs, pasted excerpts, file contents | Your retrieval pipeline |
| Tool definitions | Schemas and descriptions of available tools | Your tool configuration |
| Tool outputs | Results from prior tool calls in the session | Injected by agent runtime |
| Safety constraints | Policy instructions, content restrictions | You / provider defaults |
Prompt engineering primarily touches the system prompt and user message components. Context engineering governs decisions about all seven.
The same task, two levels of abstraction
This is the clearest way to see the difference. Here is a research summarization task handled at each level.
Prompt engineering approach
Summarize the attached document in 3 bullet points. Be concise.
The practitioner has improved the message wording — it's specific (3 bullets, concise) and clear. But the context package is uncontrolled: the full document is pasted in, there's no role context for the model, no constraint on bullet length, no signal about who the summary is for.
Context engineering approach
[SYSTEM]
You are a research assistant for a biotech company. Summaries go into
a Slack channel read by non-technical product managers.
Output format: exactly 3 bullets, each under 20 words, no jargon.
Success criteria: a PM who did not read the document can act on
your summary.
Constraint: do not include numerical claims you cannot verify from the excerpt.
[RETRIEVED EXCERPT - Pages 3-5, relevance score: 0.94 - "Clinical Trial Results"]
{relevant_pages_only}
[USER]
Summarize the key findings for this week's product review.
The user message is simple. But the context package now specifies role, audience, format, success criteria, constraints, and only the relevant document pages (not the full 40-page report). That's context engineering.
The difference in output quality isn't in the user message wording — it's in everything around it.
When prompt engineering is enough
For many tasks, prompt engineering is the right and sufficient tool. You don't need context engineering scaffolding when:
The task is self-contained. "Translate this paragraph to French." The model doesn't need retrieved documents, conversation history, or tool outputs — just a clear instruction.
You're prototyping. In early exploration, figuring out the right framing and phrasing matters more than optimizing the full context package.
The context window is mostly empty. If your context is just a system prompt + one user message, there's not much to engineer beyond the prompts themselves.
The failure mode is wording, not assembly. If the model is misunderstanding what you want, the problem is likely in the instructions, not in what documents are included.
Prompt engineering techniques — chain-of-thought, role assignment, few-shot examples, output constraints — still apply in context engineering. They are necessary but not sufficient as systems grow.
When context engineering becomes necessary
As AI systems move from single-turn interactions to multi-step agents, the assembly of the context package becomes the dominant quality lever. Context engineering becomes critical when:
The model needs external information
If the model needs to answer questions about your codebase, documentation, or real-time data, you're making retrieval decisions. Which documents to include, how much of each, how to format them, where to place them in the context window — these are context engineering decisions that dwarf the impact of prompt wording.
The conversation spans multiple turns
In a 20-turn agent session, conversation history accumulates. Do you keep all of it? Summarize old turns? Drop turns below a relevance threshold? The wrong answer wastes tokens and can pollute the model's attention with stale or contradictory context. These are context engineering decisions.
The model has access to tools
Exposing 15 tool definitions to a model that only needs 3 for the current task wastes tokens and increases the chance of incorrect tool selection. Context engineering governs which tools are exposed when, and how their schemas are written to minimize ambiguity.
The system runs autonomously across many steps
In a long-running agent loop, context mistakes compound. A vague system prompt in a single-turn interaction causes one bad response. That same vague system prompt in a 40-step agent task causes dozens of suboptimal decisions, unnecessary tool calls, and accumulated context debt as history grows. The longer the loop, the more context engineering matters relative to prompt wording.
Cost and latency are production constraints
Every token in the context window costs money and adds latency. Context engineering is directly responsible for your cost per task completion. A 200k-token context that could have been 40k tokens — with the right retrieval, history pruning, and tool exposure decisions — is a 5x cost difference.
The four context engineering levers
Once you recognize context engineering as a distinct discipline, you can reason about its levers systematically:
1. Content selection
What do you include? Every component of the context package represents a decision. Retrieved documents: which chunks, how many, how long? Conversation history: all of it, recent turns only, or a summary of old turns? Tools: only the ones needed for this task, or the full tool surface?
The question is always: does this token earn its place?
2. Structure and ordering
How do you arrange what you include? Research on attention mechanisms shows models weight content at the beginning and end of context more heavily than the middle. Your most important instructions — success criteria, hard constraints, output format — belong at the top of the system prompt and may need to be repeated before the user message.
Retrieved documents typically perform better when placed after the system prompt and before the user message. Tool definitions perform better when they're concise and unambiguous — verbose schemas degrade tool selection accuracy.
3. Token budget allocation
How much space does each component get? Start by estimating fixed costs (system prompt, tool definitions) and protecting budget for the content that changes per task (retrieved docs, current user message). The variable components are where context engineering usually finds the most gains.
4. Cache placement
For agentic systems making many API calls, prompt caching (supported by Anthropic, OpenAI, and others) lets you cache stable context prefixes. Context engineering determines the cache boundary: stable content (system prompt, tool schemas) belongs at the front; variable content (retrieved docs, user message) goes after the cache breakpoint. Get this wrong and you pay full inference cost on every call.
A diagnostic: which lever to reach for
Use this decision tree when your AI system is underperforming:
The model misunderstands what you want. → Prompt engineering. Rewrite the system prompt or user message. Add a few-shot example. Be more explicit about success criteria.
The model gives correct answers to the wrong question. → Context engineering. Check what information is in the context. The model may be missing retrieval, or your history may be polluting the current task with stale context.
The model ignores your constraints. → Both. First, move constraints to the start of the system prompt (context engineering). Then, rewrite the constraint to be more explicit (prompt engineering).
The model calls the wrong tools. → Context engineering. Reduce the tool surface to what's needed. Improve schema descriptions. Check whether tool outputs from prior calls are creating confusing signals.
The model performs well in isolation but degrades over long sessions. → Context engineering. Your conversation history is accumulating in ways that pollute the current task. Implement history summarization or selective pruning.
Cost is too high per task. → Context engineering. Audit what's in the context window. Identify large components that can be summarized, excluded, or cached.
Practical starting points
For systems you're building now
Start with the smallest context package that could possibly work. Expand components only when you can trace a quality improvement back to the addition. This forces you to make deliberate decisions rather than defaulting to "include everything."
For existing systems that underperform
Audit the full context window for a representative set of tasks. Log what the model actually sees, not what you think it sees. You will typically find: retrieved documents that are too long or off-topic, tool definitions for tools not needed in the session, conversation history that hasn't been pruned, and constraints that appear in the middle of the system prompt where they get less attention weight.
For agentic systems
Design the context package at each step of the loop, not just at initialization. The system prompt you set at the beginning will look very different from the context the model sees at step 15 — by then, it's buried under tool outputs and conversation turns. Plan for how context evolves across the loop, not just how it starts.
The bottom line
Prompt engineering and context engineering are not competing frameworks — they operate at different levels. Prompt engineering is a prerequisite that every AI practitioner needs. Context engineering is the discipline you need when your systems grow beyond simple single-turn interactions.
The practical question to ask of any AI system that isn't performing well: "Is this a wording problem or an assembly problem?" If the model is misunderstanding your intent, it's usually a wording problem — prompt engineer your way there. If the model has the right instructions but is missing information, acting on stale context, or wasting tokens on irrelevant content, it's an assembly problem — context engineer your way there.
Most production systems have both. Fix them in order: get your prompt right first, then design the full context package around it.