Long-Term Memory: What Should Survive Between Agent Sessions

Long-term memory is the set of facts, preferences, and durable state you deliberately keep after a session ends so later sessions can start smarter.

Everything else - raw chat turns, one-off tool dumps, temporary plans - should reset or compress so cost, privacy, and correctness stay under control.

Summary

Persist only durable, re-usable knowledge that will still be true and useful in a future run; reset ephemeral working context each session.
Insight: Saving too much bloats retrieval, leaks sensitive data, and freezes stale conclusions. Saving too little forces users to re-teach the agent every visit.
Key Concepts: session boundary, durable facts, ephemeral context, write policy, TTL / freshness, user vs system vs org scope.
When to Use: Multi-session products (support, personal assistants, coding agents, ops copilots) where the same principal returns and expects continuity.
Limitations/Trade-offs: Persistence adds storage, retrieval design, conflict handling, and compliance burden. Many internal tools only need short-term session state.
Related Topics: short-term memory, extraction, retrieval, conflicts, tiered architecture.

Foundations

An agent session is one bounded run of the perceive-decide-act loop: a chat thread, a ticket handling job, or a CI agent invocation.

Short-term memory lives inside that run (or a short TTL keyed by session_id): recent messages, the current plan, tool observations still relevant to the open goal.

Long-term memory outlives the run and is keyed by a stable principal - usually user_id, tenant_id, project_id, or a combination.

The decision "should this survive?" is a product and safety policy, not an automatic side effect of chatting.

Three filters help:

Durability: Will this still be true tomorrow without re-checking a system of record?
Re-use: Will a future session need this without the user repeating it?
Risk: If wrong or leaked, how bad is the failure?

Examples that usually should survive:

Stable preferences: language, timezone, verbosity, formatting conventions.
Explicit user facts they asked you to remember (team name, preferred stack, dietary restriction).
Durable workflow bindings: default repo, primary CRM account id, approved escalation channel.
Verified outcomes with provenance: "user completed onboarding 2026-03-01" with source and timestamp.

Examples that usually should not survive as raw long-term memory:

Full multi-turn transcripts (store for audit separately if required, not as always-on agent memory).
One-session hypotheses, half-finished plans, and speculative tool results.
Secrets, one-time codes, payment card data, raw auth tokens.
Facts that already live in a system of record you can query (order status, inventory, live ticket state).

Prefer pointers over copies when the truth lives elsewhere: store order_id and a retrieval recipe, not a frozen snapshot of the order.

Mechanics & Interactions

At write time, something must promote content from the session into durable storage.

Common promotion paths:

Explicit save: the user says "remember that..." or clicks "save preference."
Structured capture: a form or tool writes a typed field (preferred_language=pt-BR).
Extraction job: after a session (or mid-session), a model proposes candidate memories; policy accepts, rejects, or queues for review.
System events: webhooks and workflows write facts ("subscription upgraded") without LLM involvement.

At read time, a later session loads a small, relevant slice of long-term memory into context or tools.

You almost never dump the entire memory store into the prompt.

Session start typically looks like:

Authenticate the principal and resolve memory scope.
Load a tiny profile block (always-on, size-capped preferences).
Retrieve top-k episodic or semantic memories for the new goal.
Run the agent with short-term history starting empty (or from a new thread).
On important turns or session end, run write policy: extract, validate, upsert, or expire.

Scope matters as much as content.

Scope	Survives for	Example
User	That person across products	"Prefer concise answers"
Project / workspace	Everyone on the project	"Default deploy env is staging"
Org / tenant	Company-wide defaults	"PII redaction rules"
Session only	One run	Current tool traces

Crossing scopes by accident is a privacy bug: never promote user A facts into a shared org profile without a deliberate product decision.

# Conceptual gate: only durable, non-sensitive, re-usable claims become LTM
def should_persist(claim: dict) -> bool:
    if claim.get("contains_secret"):
        return False
    if claim.get("source") == "speculation":
        return False
    if claim.get("ttl_hours", 0) == 0 and not claim.get("user_confirmed"):
        return False
    return claim.get("durable", False) and claim.get("reuse_likely", False)

This gate is illustrative.

Production policies add schema validation, PII detectors, and human review for high-risk categories.

Advanced Considerations & Applications

Freshness vs fidelity. Some memories need TTLs (temporary travel dates). Others need versioning (address changes). Stale durable facts are worse than missing ones when the agent acts confidently.

System of record vs agent memory. If CRM already stores the customer tier, teach the agent a tool to read CRM. Use long-term memory for preferences and interaction learnings CRM does not hold.

Compliance. Retention limits, right-to-erasure, and regional storage apply to agent memory like any other personal data store. Design delete-by-user-id from day one.

Multi-agent systems. Specialists should not each keep private contradictory long-term stores for the same principal without a shared write policy. Prefer one memory service with role-scoped read/write.

Eval. Measure not only task success but memory quality: precision of stored facts, retrieval usefulness, and rate of user corrections after "remembered" behavior.

Approach	Strength	Weakness	Best Fit
Persist nothing	Simple, private	No continuity	One-shot tools, stateless APIs
Always-on profile fields	Cheap, predictable	Limited expressiveness	Preferences and defaults
Full transcript store as "memory"	Easy to implement	Noisy, costly, stale	Audit logs only, not agent context
Extracted fact store + retrieval	Scalable continuity	Extraction and conflict cost	Multi-session assistants
System-of-record tools only	Always fresh	No soft preference learning	Ops agents over live systems

Common Misconceptions

"Long-term memory means keep the whole chat history forever." History is a log. Memory is a curated, queryable knowledge layer.
"If the model saw it once, it will remember next week." Without an external store and load path, nothing survives process death or a new thread.
"More memories always improve the agent." Irrelevant or wrong memories actively degrade decisions.
"Vector search replaces write policy." Retrieval finds candidates; policy still decides what was allowed to be stored.
"Preferences and live business state are the same." Preferences are soft durable claims; order status belongs in a database tool.

FAQs

What is the shortest definition of agent long-term memory?

Durable state stored outside a single run, loaded later to personalize or ground future decisions for the same principal.

How is this different from RAG over company docs?

Document RAG retrieves shared knowledge bases. Long-term memory is usually per-user or per-tenant interaction state plus preferences, though both may use similar vector stores.

Should I store tool outputs long-term?

Store summaries or identifiers when re-use is likely. Do not store large raw payloads that will be stale or blow retrieval budgets.

When should a session deliberately forget?

On logout for shared devices, after sensitive workflows, when the user says "forget that," and when TTLs expire.

Do coding agents need long-term memory?

Yes for user and team conventions (style, deploy norms). Prefer repo files and issue trackers as systems of record for project truth.

Is a cookie or browser localStorage enough?

Fine for demos and single-device preferences. Multi-device, multi-agent, and compliance-sensitive products need a server-side store keyed by authenticated identity.

How large should the always-on profile be?

Small enough to include every turn without retrieval: often a few hundred tokens of structured fields, not free-form essays.

Who is allowed to write long-term memory?

Prefer trusted server paths: validated tools, extraction jobs, and admin APIs. Do not let untrusted tool output silently become permanent fact.

What belongs in short-term memory instead?

The active goal, recent turns, scratchpad plans, and tool observations for the current task. See short-term memory coverage in the sibling section.

How do I handle "remember this for two weeks"?

Store with an explicit expiry timestamp and filter expired rows at retrieval. Do not rely on the model to remember the TTL.

Can multi-tenant agents share one table?

Yes if every row is scoped by tenant_id (and usually user_id) and every query enforces that predicate. Missing the predicate is a severe isolation bug.

Should legal hold freeze memory deletion?

Possibly for audit copies. Separate compliance archives from online agent memory so product delete and legal retention do not fight the same row without process.

What metric tells me my persist policy is wrong?

High user correction rate ("I never said that"), rising token cost from memory, or frequent retrieval of unused facts.

Long-Term Memory Basics - first save-and-recall pattern
File-Based and Database-Backed Long-Term Memory Stores - persistence recipes
Memory Extraction: Deciding What's Worth Remembering - write-side selection
Memory Retrieval: Surfacing the Right Fact at the Right Time - read-side selection
Architecture Guide: A Tiered Memory System for Production Agents - short-term + LTM + retrieval
Short-Term Memory: What an Agent Actually Needs Within One Run - in-session counterpart

Stack versions: Pins from the category manifest (verify at build): OpenRouter (~315+ models, July 2026 pricing/fees); LangGraph 1.0+; CrewAI 1.14+; Microsoft Agent Framework 1.0; Vercel AI SDK 6; Pydantic AI (latest); LlamaIndex (latest); OpenAI Agents SDK (latest + MCP); MCP (Linux Foundation governance); A2A (HTTP+SSE+JSON-RPC 2.0); Solana @solana/web3.js + @solana/spl-token.

Everything else - raw chat turns, one-off tool dumps, temporary plans - should reset or compress so cost, privacy, and correctness stay under control.

Summary

Persist only durable, re-usable knowledge that will still be true and useful in a future run; reset ephemeral working context each session.
Insight: Saving too much bloats retrieval, leaks sensitive data, and freezes stale conclusions. Saving too little forces users to re-teach the agent every visit.
Key Concepts: session boundary, durable facts, ephemeral context, write policy, TTL / freshness, user vs system vs org scope.
When to Use: Multi-session products (support, personal assistants, coding agents, ops copilots) where the same principal returns and expects continuity.
Limitations/Trade-offs: Persistence adds storage, retrieval design, conflict handling, and compliance burden. Many internal tools only need short-term session state.
Related Topics: short-term memory, extraction, retrieval, conflicts, tiered architecture.

Foundations

An agent session is one bounded run of the perceive-decide-act loop: a chat thread, a ticket handling job, or a CI agent invocation.

Short-term memory lives inside that run (or a short TTL keyed by session_id): recent messages, the current plan, tool observations still relevant to the open goal.

Long-term memory outlives the run and is keyed by a stable principal - usually user_id, tenant_id, project_id, or a combination.

The decision "should this survive?" is a product and safety policy, not an automatic side effect of chatting.

Three filters help:

Durability: Will this still be true tomorrow without re-checking a system of record?
Re-use: Will a future session need this without the user repeating it?
Risk: If wrong or leaked, how bad is the failure?

Examples that usually should survive:

Stable preferences: language, timezone, verbosity, formatting conventions.
Explicit user facts they asked you to remember (team name, preferred stack, dietary restriction).
Durable workflow bindings: default repo, primary CRM account id, approved escalation channel.
Verified outcomes with provenance: "user completed onboarding 2026-03-01" with source and timestamp.

Examples that usually should not survive as raw long-term memory:

Full multi-turn transcripts (store for audit separately if required, not as always-on agent memory).
One-session hypotheses, half-finished plans, and speculative tool results.
Secrets, one-time codes, payment card data, raw auth tokens.
Facts that already live in a system of record you can query (order status, inventory, live ticket state).

Prefer pointers over copies when the truth lives elsewhere: store order_id and a retrieval recipe, not a frozen snapshot of the order.

Mechanics & Interactions

At write time, something must promote content from the session into durable storage.

Common promotion paths:

Explicit save: the user says "remember that..." or clicks "save preference."
Structured capture: a form or tool writes a typed field (preferred_language=pt-BR).
Extraction job: after a session (or mid-session), a model proposes candidate memories; policy accepts, rejects, or queues for review.
System events: webhooks and workflows write facts ("subscription upgraded") without LLM involvement.

At read time, a later session loads a small, relevant slice of long-term memory into context or tools.

You almost never dump the entire memory store into the prompt.

Session start typically looks like:

Authenticate the principal and resolve memory scope.
Load a tiny profile block (always-on, size-capped preferences).
Retrieve top-k episodic or semantic memories for the new goal.
Run the agent with short-term history starting empty (or from a new thread).
On important turns or session end, run write policy: extract, validate, upsert, or expire.

Scope matters as much as content.

Scope	Survives for	Example
User	That person across products	"Prefer concise answers"
Project / workspace	Everyone on the project	"Default deploy env is staging"
Org / tenant	Company-wide defaults	"PII redaction rules"
Session only	One run	Current tool traces

Crossing scopes by accident is a privacy bug: never promote user A facts into a shared org profile without a deliberate product decision.

# Conceptual gate: only durable, non-sensitive, re-usable claims become LTM
def should_persist(claim: dict) -> bool:
    if claim.get("contains_secret"):
        return False
    if claim.get("source") == "speculation":
        return False
    if claim.get("ttl_hours", 0) == 0 and not claim.get("user_confirmed"):
        return False
    return claim.get("durable", False) and claim.get("reuse_likely", False)

This gate is illustrative.

Production policies add schema validation, PII detectors, and human review for high-risk categories.

Advanced Considerations & Applications

Freshness vs fidelity. Some memories need TTLs (temporary travel dates). Others need versioning (address changes). Stale durable facts are worse than missing ones when the agent acts confidently.

System of record vs agent memory. If CRM already stores the customer tier, teach the agent a tool to read CRM. Use long-term memory for preferences and interaction learnings CRM does not hold.

Compliance. Retention limits, right-to-erasure, and regional storage apply to agent memory like any other personal data store. Design delete-by-user-id from day one.

Eval. Measure not only task success but memory quality: precision of stored facts, retrieval usefulness, and rate of user corrections after "remembered" behavior.

Approach	Strength	Weakness	Best Fit
Persist nothing	Simple, private	No continuity	One-shot tools, stateless APIs
Always-on profile fields	Cheap, predictable	Limited expressiveness	Preferences and defaults
Full transcript store as "memory"	Easy to implement	Noisy, costly, stale	Audit logs only, not agent context
Extracted fact store + retrieval	Scalable continuity	Extraction and conflict cost	Multi-session assistants
System-of-record tools only	Always fresh	No soft preference learning	Ops agents over live systems

Common Misconceptions

"Long-term memory means keep the whole chat history forever." History is a log. Memory is a curated, queryable knowledge layer.
"If the model saw it once, it will remember next week." Without an external store and load path, nothing survives process death or a new thread.
"More memories always improve the agent." Irrelevant or wrong memories actively degrade decisions.
"Vector search replaces write policy." Retrieval finds candidates; policy still decides what was allowed to be stored.
"Preferences and live business state are the same." Preferences are soft durable claims; order status belongs in a database tool.

FAQs

What is the shortest definition of agent long-term memory?

Durable state stored outside a single run, loaded later to personalize or ground future decisions for the same principal.

How is this different from RAG over company docs?

Document RAG retrieves shared knowledge bases. Long-term memory is usually per-user or per-tenant interaction state plus preferences, though both may use similar vector stores.

Should I store tool outputs long-term?

Store summaries or identifiers when re-use is likely. Do not store large raw payloads that will be stale or blow retrieval budgets.

When should a session deliberately forget?

On logout for shared devices, after sensitive workflows, when the user says "forget that," and when TTLs expire.

Do coding agents need long-term memory?

Yes for user and team conventions (style, deploy norms). Prefer repo files and issue trackers as systems of record for project truth.

Is a cookie or browser localStorage enough?

Fine for demos and single-device preferences. Multi-device, multi-agent, and compliance-sensitive products need a server-side store keyed by authenticated identity.

How large should the always-on profile be?

Small enough to include every turn without retrieval: often a few hundred tokens of structured fields, not free-form essays.

Who is allowed to write long-term memory?

Prefer trusted server paths: validated tools, extraction jobs, and admin APIs. Do not let untrusted tool output silently become permanent fact.

What belongs in short-term memory instead?

The active goal, recent turns, scratchpad plans, and tool observations for the current task. See short-term memory coverage in the sibling section.

How do I handle "remember this for two weeks"?

Store with an explicit expiry timestamp and filter expired rows at retrieval. Do not rely on the model to remember the TTL.

Can multi-tenant agents share one table?

Yes if every row is scoped by tenant_id (and usually user_id) and every query enforces that predicate. Missing the predicate is a severe isolation bug.

Should legal hold freeze memory deletion?

Possibly for audit copies. Separate compliance archives from online agent memory so product delete and legal retention do not fight the same row without process.

What metric tells me my persist policy is wrong?

High user correction rate ("I never said that"), rising token cost from memory, or frequent retrieval of unused facts.

Long-Term Memory Basics - first save-and-recall pattern
File-Based and Database-Backed Long-Term Memory Stores - persistence recipes
Memory Extraction: Deciding What's Worth Remembering - write-side selection
Memory Retrieval: Surfacing the Right Fact at the Right Time - read-side selection
Architecture Guide: A Tiered Memory System for Production Agents - short-term + LTM + retrieval
Short-Term Memory: What an Agent Actually Needs Within One Run - in-session counterpart

Stack versions: Pins from the category manifest (verify at build): OpenRouter (~315+ models, July 2026 pricing/fees); LangGraph 1.0+; CrewAI 1.14+; Microsoft Agent Framework 1.0; Vercel AI SDK 6; Pydantic AI (latest); LlamaIndex (latest); OpenAI Agents SDK (latest + MCP); MCP (Linux Foundation governance); A2A (HTTP+SSE+JSON-RPC 2.0); Solana @solana/web3.js + @solana/spl-token.

Long-Term Memory: What Should Survive Between Agent Sessions

Search Documentation

Long-Term Memory: What Should Survive Between Agent Sessions