Prompt engineering improves the instructions given to a model. Context engineering designs the full information environment in which the model performs the task. That environment includes the prompt, retrieved sources, tools, memory, permissions, intermediate results, and rules for deciding what should enter the context.
The two practices overlap, but they solve different failure modes. Better wording cannot recover a customer interview that was never retrieved. Better retrieval cannot fix an instruction that asks for the wrong outcome.
What prompt engineering controls
Prompt engineering focuses on the current request. It clarifies the role, objective, constraints, output format, examples, and evaluation criteria.
A well-designed prompt might say:
Compare the three proposed onboarding messages. Return a table with audience, promise, evidence, and risk. Do not invent supporting data.
This is valuable because the task is explicit. The model knows what to produce and what to avoid.
Prompt engineering is usually enough when the task is self-contained, all required information already fits in the conversation, and no external actions are needed.
What context engineering controls
Context engineering asks a broader question: what information and capabilities should be available at each step?
For the same onboarding task, a context-engineered system might:
- Search the customer research project for onboarding objections.
- Retrieve the exact interview passages.
- Open the current positioning brief.
- Exclude research older than the latest product change.
- Give the model a comparison instruction.
- Require citations for every customer claim.
- Save the approved conclusion back to the project decision log.
The prompt is one component. Retrieval, filtering, tool permissions, and output handling are equally important.
Why long prompts are not context engineering
Copying a large research dump into a prompt increases context, but it does not create a reliable context system. The model still has to identify relevance, handle duplicates, and distinguish current evidence from outdated notes.
Long prompts also lack a durable update path. When a source changes, every copied brief can become stale.
Context engineering keeps durable knowledge in a retrievable store and loads only what the current task needs. The active context becomes a selected working set, not an archive.
| Question | Prompt engineering | Context engineering |
|---|---|---|
| What is designed? | The instruction and response format | The information and capability flow |
| Typical scope | One task or conversation | A repeated workflow or agent system |
| Main tools | Instructions, examples, constraints | Retrieval, memory, tools, permissions, prompts |
| Common failure | Ambiguous request | Missing, stale, excessive, or unsafe context |
| Success test | The response follows the requested format | The system uses the right evidence and actions |
Retrieval is a context decision
Retrieval-augmented generation, often called RAG, is one mechanism for supplying external information. The system searches a collection and adds matching material to the model's context.
Good context engineering decides more than the search algorithm. It defines the collection, metadata filters, number of results, passage size, reranking, source display, and what happens when confidence is low.
For project research, provenance is essential. A result should include the original source and enough surrounding content to verify how the passage was used.
Tools and permissions are context too
An agent's available tools shape its behavior. A read-only search tool creates a different workflow from a tool that can modify a project or publish an external message.
MCP formalizes how compatible applications connect to external resources and tools. The MCP architecture emphasizes capability negotiation and separation between the host and focused servers.
Context engineering therefore includes permission design. The agent should receive the smallest capability set needed for the task, and users should be able to review consequential actions.
When to use each practice
Use prompt engineering when you need a better instruction for a bounded task. Use context engineering when the same work repeats, depends on changing sources, spans multiple tools, or requires reliable retrieval and actions.
For most useful agentic systems, the sequence is:
- Define the outcome and evaluation criteria.
- Identify the knowledge and tools required.
- Decide how the system retrieves and limits context.
- Write the prompt for the model's part of the workflow.
- Test the complete system against realistic failures.
The shift is from writing the perfect question to designing a dependable working environment.