Explainer
What Is AI Agent Memory? Short-Term, Long-Term, and Project Context
AI agent memory is the information a system can carry forward so an agent can continue useful work instead of treating every request as a blank start. The important distinction is scope: short-term memory supports the current thread, long-term memory carries durable facts across sessions, and project context keeps the files, decisions, constraints, and deliverables for one body of work connected.
Memory is not the same as a longer prompt. A useful memory system decides what to retain, where it belongs, when to retrieve it, how to correct it, and when to forget it.
Research and disclosure: We reviewed the OpenAI Agents SDK memory guide, OpenAI Sessions guide, OpenAI context guide, and LangGraph memory documentation on August 27, 2026. These sources describe implementation patterns, not a benchmark of Ottermind. Product statements below are repository-scoped disclosures.
The three memory scopes
| Scope | What it holds | Lifetime | Best for |
|---|---|---|---|
| Short-term memory | Recent messages, tool results, and working state | One thread or run | Continuing a conversation and recovering an interrupted task |
| Long-term memory | Durable user, team, or application facts | Across sessions and threads | Preferences, recurring constraints, and lessons worth reusing |
| Project context | Sources, decisions, instructions, artifacts, and open questions | The life of a project | Carrying one approved body of work into related deliverables |
These scopes overlap but should not be collapsed. A message from this morning may matter only to the current thread. A preferred tone may be useful across future work. A launch claim belongs to its project and should not silently become a universal user fact.
Short-term memory: the working thread
Short-term memory is the agent's active workspace for a conversation or task. It can include the recent message history, intermediate calculations, tool responses, current plan, and pending questions. In agent frameworks, this state is often persisted with a session or checkpoint so a thread can resume after a pause.
It is useful when the user says “revise the second option,” when a tool returns new evidence, or when an agent needs to recover from an interrupted run. It is not a good place for every fact the agent may ever need. Long threads become expensive and noisy, and stale instructions can remain influential long after they stopped being true.
Manage short-term memory deliberately:
- Keep the latest decisions and unresolved questions easy to retrieve.
- Summarize or trim repetitive messages when the thread grows.
- Preserve tool results that affect the current deliverable, not every transient log line.
- Mark failed attempts so the agent does not repeat them blindly.
- Treat a resumed thread as state to inspect, not proof that every old assumption is still valid.
Long-term memory: durable facts across sessions
Long-term memory stores information that remains useful after a thread ends. It might contain a user's preferred format, a team's naming convention, a recurring business rule, or a lesson from a completed task. OpenAI's sandbox memory guide distinguishes generated memory artifacts from conversational session history; LangGraph similarly describes long-term memory as user- or application-level data shared across threads.
Long-term memory needs stronger governance than a transcript. For every candidate memory, ask:
- Is it stable enough to reuse?
- Is the scope correct: user, team, project, or agent?
- Does the person or owner expect it to be retained?
- Can it be corrected, deleted, or superseded?
- Would retrieving it create a privacy, safety, or fairness problem?
Do not turn a one-off request into a permanent preference without evidence. Do not store secrets, sensitive personal data, or speculative model conclusions merely because they appeared in a conversation. Memory should be treated as retained data with an explicit retention policy.
Project context: memory with boundaries
Project context is the shared working set around an outcome. It can include source files, links, approved facts, decisions, constraints, feedback, intermediate artifacts, owners, deadlines, and the definition of done. Unlike a generic personal memory, project context is intentionally bounded by the work.
That boundary prevents two common failures. First, the agent does not need the user to repeat the same brief every time a report becomes a presentation. Second, a project-specific decision does not leak into unrelated work. A launch's approved claim, for example, should remain attached to that launch until its owner updates or retires it.
Project context should show provenance. Keep the source, date, owner, confidence or status, dependent artifacts, and unresolved questions visible. When a source changes, mark downstream work as stale instead of silently blending old and new facts.
Memory is not retrieval
Storing information and using it are separate operations. Retrieval decides which memories enter the current context. A system can have a large memory store and still behave poorly if it retrieves irrelevant, stale, duplicated, or overly sensitive material.
Use a simple retrieval contract:
| Step | Question |
|---|---|
| Scope | Is this memory allowed in the current user, project, and tool context? |
| Relevance | Does it help answer or execute the present task? |
| Freshness | Is the fact current, or should it be checked against a source? |
| Authority | Who created or approved it? |
| Conflict | What happens if it disagrees with a newer instruction or source? |
Current user instructions and approved project sources should normally outrank an old inferred preference. The agent should expose uncertainty and ask when the conflict changes the result.
A practical memory architecture
For a knowledge-work agent, a useful architecture has five layers:
- Thread state: current messages, plan, tool results, and pending actions.
- Working summary: a compact, editable account of decisions and open questions.
- Durable memories: scoped facts with an owner, timestamp, and correction path.
- Project record: sources, artifacts, decisions, and dependencies for one outcome.
- Audit and retention: access, retrieval, edits, deletion, expiry, and incident records.
The layers can use different storage and permissions. A session store is not automatically a long-term memory store, and a project folder is not automatically a safe personal profile. Keep the boundaries explicit in both the data model and the user interface.
Common memory failures
Everything is remembered
Unfiltered transcripts increase cost, privacy exposure, and retrieval noise. Retain useful signals, not every utterance.
The wrong scope is remembered
A project-specific instruction becomes a global preference, or one user's detail appears in a team context. Attach every memory to an owner and namespace.
Stale facts win
An old preference or source silently overrides a current instruction. Store timestamps and precedence rules, and re-check consequential facts.
Memory is impossible to inspect
People cannot correct what they cannot see. Show the relevant source, why a memory was retrieved, and how to edit or remove it.
The agent confuses memory with truth
Remembered information is evidence, not a guarantee. Treat it as a hypothesis until the current source or owner confirms it when accuracy matters.
How to choose what an agent should remember
Start with a recurring task and classify candidate information:
- Ephemeral: useful only for the current turn; discard after completion.
- Thread-level: needed to resume this conversation; retain with the thread.
- Project-level: needed by related deliverables; retain with the project and its access rules.
- Durable preference: repeatedly confirmed and useful across projects; retain only with an owner and correction path.
- Sensitive or uncertain: do not retain by default; ask or keep it local to the current task.
Test the design with a correction: change one project fact, start a related deliverable, and verify that the agent uses the new fact while leaving unrelated projects unchanged.
How Ottermind fits
Ottermind is an AI agent workspace for work that moves from goals and source material into connected deliverables. Its project context keeps files, links, decisions, intermediate work, and follow-up tasks near the outcome they belong to. That is different from claiming that every conversation becomes permanent personal memory.
Use a bounded project, name the source of truth, and review the context before asking for a consequential output. Correct or remove stale information, and keep sensitive material governed by the people and policies responsible for it.
Frequently asked questions
Is chat history the same as AI agent memory?
No. Chat history is one possible source of short-term context. Agent memory also includes durable facts, summaries, checkpoints, and project records, each with different scope and retention rules.
What is the difference between long-term memory and project context?
Long-term memory is durable information reused across sessions, often scoped to a user or application. Project context is bounded around one outcome and includes sources, decisions, artifacts, and dependencies that belong together.
Should an agent remember every user preference?
No. Retain preferences that are stable, useful, expected, and allowed to be stored. Give people a way to inspect, correct, delete, and override them.
How can I prevent stale memory from causing errors?
Store provenance and dates, define precedence for current instructions, re-check high-impact facts, and mark dependent work stale when an upstream source changes.
Does more memory make an agent smarter?
Not automatically. More retained data can add cost and irrelevant retrieval. Better memory is scoped, fresh, traceable, editable, and relevant to the task.
Bottom line
AI agent memory works best when its boundaries are visible. Short-term memory keeps a task moving, long-term memory carries carefully selected durable facts, and project context keeps one body of work coherent. Decide what belongs in each scope, show where it came from, and make correction and forgetting part of the design.
