Context engineering chooses the information an agent sees right now. Memory chooses what information survives after the current run. If an agent forgets between sessions, stuffing better context into one prompt is not enough; it needs a write path, scoped storage, retrieval, and inspection.
Last updated: June 20, 2026.
What is context engineering?
Context engineering is the discipline of assembling the current working set: user request, system instructions, tool outputs, retrieved evidence, prior turns, and constraints. Anthropic’s context engineering guide frames it as the work of giving agents the right information to complete tasks.
That work is immediate. It answers, “What should the model see for this step?” It includes truncation, summarization, tool result selection, retrieval, examples, and guardrails.
Context engineering is not durable storage. A beautiful prompt still disappears when a new session starts unless the relevant facts were written somewhere outside the model call.
What is agent memory?
Agent memory is the durable layer that stores scoped, source-linked facts and retrieves them later. LangChain’s memory docs separate short-term thread state from long-term memory across interactions. That split is the practical boundary: short-term state feeds current context, while long-term memory survives beyond it.
Memory should store more than text. It should store where the fact came from, who can access it, whether it is current, and how to delete or supersede it. That is why Inspectable Agent Memory, Supersession-Aware Memory, and Provable Forgetting exist as separate topics.
How do context engineering and memory relate?
Memory is an input to context engineering. The agent asks the memory system for relevant evidence, and the context layer decides how much of that evidence should enter the prompt. Retrieval can return twenty candidates; context engineering may include five.
| Step | Context engineering role | Memory role |
|---|---|---|
| User asks a question | Interpret task and constraints | None yet |
| Agent retrieves context | Choose query and inclusion budget | Return scoped source-linked candidates |
| Model answers | Assemble prompt and citations | Provide evidence and lifecycle state |
| User gives a correction | Decide whether correction matters now | Write durable correction if policy allows |
| Fact changes later | Include current source | Mark old memory superseded |
The Model Context Protocol architecture helps operationalize this boundary. MCP servers expose tools and resources. A memory server can provide candidates; the host and agent still decide how those candidates are used in the current context.
Why does context rot happen below the token limit?
More context can make a model worse when the useful signal is surrounded by distracting or conflicting text. The issue is not only capacity; it is coherence and selection. See Context Rot for the full troubleshooting guide.
Memory helps by keeping the durable fact outside the prompt until it is relevant. Context engineering helps by selecting the smallest useful evidence set. Together they avoid the false choice between “paste everything” and “remember nothing.”
How do you debug the boundary?
Use a four-question trace:
- Was the fact ever written to memory?
- Was it written with source, scope, and lifecycle metadata?
- Did retrieval return it for the new task?
- Did context engineering include it in the model input?
If the answer to question one is no, the bug is a write-path bug. If the answer to question three is no, it is a retrieval or permission-scope bug. If the answer to question four is no, it is context assembly. If all four are yes and the model still ignored the evidence, then prompt instruction, citation enforcement, or model behavior is the next layer.
What should a production agent store?
Do not store every turn. Store durable facts with a reason to exist:
- Decisions that should survive a new session.
- Project rules that should apply across tools.
- User preferences that are stable and scoped.
- Source artifacts that can support future answers.
- Corrections that supersede old facts.
- Deletion events that prevent stale recall.
The OpenAI conversation state guide describes state as application-managed. That is the correct default for memory: the application should decide what persists rather than hoping the model keeps track of it.
What should stay in context only?
Keep transient task details in context. Examples include the current command output, a one-off scratch calculation, a draft phrase the user is actively editing, or a tool result that has no future value. Writing these as durable memory creates bloat and retrieval noise.
The write path should be conservative. A good rule is: if a future agent would need the fact and a human could explain why it was stored, it may belong in memory. If not, leave it in the current context.
What should you read next?
Read Memory needs a write path for storage design, Context Rot for prompt degradation, and Why AI Agents Forget for the failure pattern this boundary fixes.