Question-led guide · comparison
Context, memory, and state: what is the difference?
A production design boundary for deciding what the model sees now, what the system may remember later, and what remains authoritative workflow truth.
Direct answer
Context is the bounded information available to the model for the current generation. Memory is governed information retained for possible use in later work. State is the authoritative record of where the application or workflow is and what has happened. A conversation transcript can contribute to all three, but it should not define them. Keep state outside the model, admit memory through policy, and compile context from current state and evidence.
Scope
Use this distinction for multi-turn, tool-using, or long-running applications. A one-shot generation may need only context. The moment information survives a run, affects another user, controls a retry, or represents a durable effect, memory and state need explicit designs.
Why it happens
Frameworks often use the same word for several layers. “Memory” may mean a transcript, vector retrieval, a profile, or a database. “Context” may mean dependencies passed to tool code or the tokens visible to the model. “State” may mean a mutable object in process or the authoritative workflow record. The ambiguity remains hidden in a demo and appears later as stale facts, privacy leaks, and repeated effects.
Diagnosis
For every datum, ask:
- Who writes it, and under which identity?
- Who can read it, including the model and tools?
- Is it authoritative, advisory, derived, or untrusted?
- How long does it live, and how is it corrected or deleted?
- Which version and time does it describe?
- Can a retry or concurrent worker update it safely?
- What happens if it is missing, stale, or contradictory?
If a field cannot answer those questions, it should not silently cross from context into memory or state.
Solution
Keep three contracts:
- Context compiler: selects current state, instructions, evidence, allowed tools, and budget into a model-visible view. It records provenance and omissions.
- Memory lifecycle: admits candidate memories, labels source and confidence, scopes readers, sets expiry, supports correction, and prevents raw untrusted instructions from persisting by default.
- State machine: owns workflow status, approvals, operation keys, effect receipts, cancellation, and recovery. Transitions are typed and concurrency-aware.
The model can propose changes to memory or state. Trusted application code validates and commits them. On resume, rebuild context from current state and approved memory instead of treating the last transcript as current truth.
Artifact
| Property | Context | Memory | State |
|---|---|---|---|
| Primary purpose | Inform the current generation | Inform possible future work | Represent authoritative workflow truth |
| Typical lifetime | One model call or run step | Across runs, subject to lifecycle | Until superseded by a valid transition |
| Model visibility | Yes, after compilation | Only when selected | Only the necessary projection |
| Write authority | Context compiler | Governed admission path | Trusted state-transition code |
| Failure mode | Omission, overload, misleading framing | Poisoning, leakage, staleness | Lost update, duplicate effect, invalid transition |
| Required evidence | Manifest of selected sources | Provenance, writer, confidence, expiry | Version, transition, actor, operation/effect receipt |
Common mistakes
- Persisting the entire transcript and calling it long-term memory.
- Allowing retrieved text to update a user profile without admission policy.
- Reconstructing completed tool effects from assistant messages.
- Copying all state into every prompt instead of projecting task-relevant fields.
- Treating vector similarity as authority, freshness, or permission.
Evidence
Model-visible context and application-local context are distinct system concerns.
The OpenAI Agents SDK documentation explicitly distinguishes context available to local code from context visible to the language model.
Primary source · official-doc · checked Aug 25, 2026
Limit: This is one SDK's terminology and does not define a universal architecture for every agent system.
A session abstraction can retain conversation history without making that history authoritative workflow state.
The Session protocol is documented as storing conversation history for a session so agents can maintain context.
Primary source · official-doc · checked Aug 25, 2026
Limit: The documentation does not claim that session history is a system of record for business effects or workflow transitions.
Production designs should assign context, memory, and state different ownership, retention, and trust contracts.
The three-contract model prevents summaries and conversational history from silently becoming durable facts or completed effects.
Signal Studio author framework · reviewed Aug 25, 2026
Limit: The exact storage and lifecycle design depends on local workflow, privacy, and reliability requirements.
Limitations
These are engineering definitions for production agent systems, not claims that every framework uses the same vocabulary. Some platforms call conversation history “memory” or “state.” Map product terms to the underlying ownership, visibility, durability, and authority contracts before comparing implementations.
FAQ
- Is the context window the same as memory?
- No. The context window is a model input boundary for one generation. Memory is information retained and governed for possible future use; selected memories may later be compiled into context.
- Can a transcript be the workflow state?
- It may describe state, but it is a poor authority for completed effects, approvals, retries, and concurrent transitions. Keep those as typed records in a system of record.
Related guides
Continue within Context, memory, and state, or use one of these adjacent diagnostics:
English editorial review: Codex native-English editorial review, .