Context Engineering vs Prompt Engineering
Prompt engineering was about crafting the right question for a single turn. Context engineering is about assembling the right information environment for complex multi-turn systems. The shift reflects how LLM applications matured from chatbots to agents.
Why This Matters
Prompt engineering optimizes the question. Context engineering optimizes the information environment the question lives in. If your team’s approach to a degrading multi-turn agent is “write a better system prompt,” you’re solving the wrong problem, and the gap between the two disciplines is why.
Prompt Engineering: The Single-Turn Era
When the dominant interaction pattern was single-turn, phrasing was the entire game. You crafted the question, added few-shot examples to guide formatting, included constraints, and sent it. Each interaction was independent; there was no state to manage.
Translate the following to French. Maintain tone and style.
Text: "The quick brown fox jumps over the lazy dog."
The entire task fits in the prompt. No context assembly, no state management, no lifecycle to worry about.
Context Engineering: The Multi-Turn Era
Modern LLM applications span multiple turns, call tools, maintain state, and pull in external information. The prompt is now a small fraction of what the model sees.
The context engineer’s job is fundamentally different: deciding what information enters the context window, how it’s structured, when to evict stale content, and how to balance completeness against the reality that every token you add degrades attention on every other token.
{
"system": "You are a coding assistant. Current project: FastAPI.",
"files": {
"main.py": "[file contents]",
"models.py": "[file contents]"
},
"user_editing": "auth.py",
"message": "Add JWT authentication to the login endpoint"
}
The phrasing of the user message matters less than the information environment created around it.
A Concrete Example
The difference becomes clear when you see the same task handled both ways.
Prompt engineering thinking:
Write a function to validate user input that checks email format and password strength.
Context engineering thinking:
Current codebase patterns:
- Validation uses pydantic schemas in models.py
- Password validation requires 8+ chars, one number, one special
- Email validation uses the email-validator library
- Error handling returns HTTP 422 with detail dict
Task: Write a validate_user_input function for auth.py that follows these patterns.
The first produces generic code that might work. The second produces code that fits your codebase.
Key Differences
| Aspect | Prompt Engineering | Context Engineering |
|---|---|---|
| Focus | Phrasing and format | Information selection |
| Scope | Single turn | Multi-turn conversations |
| State | None | Persistent across turns |
| Tools | None | External tools and data |
| Complexity | Low | High |
| Skills | Writing, formatting | Architecture, curation |
The Evolution
As LLM applications moved from single-turn chatbots to multi-turn assistants to long-running agents with tool use and external knowledge, phrasing became less important and information assembly became more important. The application complexity outgrew what prompt engineering could address.
Andrej Karpathy captured the endpoint: “Context engineering is the delicate art and science of filling the context window with just the right information for the next step.” The phrase “for the next step” is doing real work there. It implies a multi-step process where context isn’t static; it evolves, accumulates, and eventually needs to be managed or it degrades.
Why the Distinction Matters
The skill sets don’t overlap as much as people think. The person who writes great single-turn prompts and the person who designs context management for a 50-step agent workflow are not doing the same job. If your listing says “prompt engineer” but the role involves building multi-turn agent systems, you’ll hire someone optimized for the wrong problem.
Architecturally, they also live in different places. Prompt engineering concerns are at the model interface: formatting, tone, output structure. Context engineering concerns are at the system level: what data flows into the window, when to compress or evict, how to structure information across agent boundaries. When something breaks in a context-engineered system, the failure mode is usually “wrong information in the window” or “right information, wrong position,” not “the phrasing was off.” Different tools, different metrics, different fixes.
Teaching the difference matters too. Prompt engineering is teaching someone to write better questions. Context engineering is teaching system design. The second is harder, takes longer, and for production applications, matters more.
Practical Implications
The system prompt matters, but after a few turns it’s 5% of what the model sees. The other 95% is accumulated conversation history, tool outputs, and retrieved context that nobody is actively managing. That’s where quality degrades, and that’s where context engineering lives.
The patterns on this site (Select, Pyramid, Compress, Isolate) address the 95%. Start there.