Context engineering selects what the model sees for one request. Memory decides what the application stores and may retrieve later. Durable state records commitments and facts that the system must not reconstruct from a conversation.
These are three different responsibilities.
- Candidate inputs
Instructions, the user goal, task state, retrieved evidence, tool results, and conversation history are candidates, not an automatic entitlement to context.
- Selection tray
Rank, trim, and label sources. Relevance, freshness, and authorization still need deliberate checks.
- Working context
The selected material is the model input for this turn. A larger window does not select useful evidence for you.
- Durable memory
Persist governed, versioned state separately. It can outlive the current request without becoming an instruction.
Working context is temporary. Durable memory has its own storage, provenance, and governance.
How to read this model
An archive cabinet beside a selection tray and a reading carriage. The object is a teaching analogy. Inspecting a part highlights its role; it does not execute or simulate the software. Cabinet trays are records, workpieces are data, and latches are checks. Unless an explanation states a quantity, compartments and sample workpieces do not denote data counts. Part dimensions are not a quantitative scale.
Build context in a deliberate order
A model request may contain:
- Governing instructions
- The current user goal
- Allowed tool definitions
- Structured task state
- Selected conversation history
- Retrieved evidence
- Recent tool observations
The order and representation affect model behavior. Conflicting or irrelevant content makes the next decision harder.
Working memory supports the current task
Working memory is the small set of facts and intermediate results needed now. It might include completed steps, unresolved questions, selected evidence, and remaining budget.
Store it as structured state where practical. A list of completed operation identifiers is safer than a summary that says “all changes applied.”
Long-term memory needs a lifecycle
Common categories include:
- Episodic memory, which records prior interactions or events
- Semantic memory, which records generalized facts or preferences
- Procedural memory, which records reusable methods or instructions
The names are less important than the policy. Each stored item needs provenance, ownership, access scope, retention, correction, and deletion behavior.
Do not store everything
Conversation history can contain secrets, personal data, stale assumptions, prompt injections, and mistakes. Before storing a memory, decide whether it is useful, permitted, attributable, and safe to retrieve later.
Do not save credentials, authentication tokens, transient approvals, or unverified claims as reusable memory.
Retrieval can poison future decisions
A malicious email or document may cause the system to save an instruction as a preference. Later tasks can then receive the injected content without the original source being visible.
Preserve provenance and trust level. Separate user-confirmed preferences from model-inferred notes. Require stronger checks before untrusted content becomes durable memory.
Resolve conflict against the source of truth
When memory conflicts with current system state, authoritative state wins. A stored preference may influence presentation. It must not override the user's current instruction or a domain rule.
Use timestamps and source versions to identify stale memories. Let users inspect and correct personal memory where the product calls for it.
Summarize for continuity, not correctness
Summaries help fit long interactions into context. Keep exact identifiers, approvals, and commitments in structured state. A summary is a lossy view, not a ledger.