Give your agent long-term memory

The problem shows up the second time someone talks to your agent. They told it something yesterday, they come back today, and it has no idea. It asks questions it already asked. It suggests things they already rejected. It treats every session as the first one, and users notice immediately, because a person who forgets everything you told them last week is not someone you trust with anything important.

This page is for teams who have shipped an agent that works and are now hitting this. The prototype was fine. Real usage, where the same person returns day after day, is where statelessness stops being a technical detail and starts being the reason people churn.

What you have probably already tried

Most teams work through the same sequence before concluding the problem is architectural.

Appending conversation history is the first move and it works, briefly. Then threads lengthen, the context fills with greetings and rephrasings, and you hit the context window ceiling. Now you are choosing what to drop, usually by truncating oldest-first, which throws away exactly the durable facts you wanted to keep.

Putting conversations in a vector database is the usual second move. It holds up until the history accumulates and retrieval starts returning noise beside signal. The deeper issue is that a vector store finds passages that resemble the query, with no notion of one fact superseding another. A user who was on the free plan three months ago and upgraded last week now has two conflicting facts in the index, and a chunk retriever may surface both, leaving the model to guess which is current. Sometimes it guesses wrong, confidently. This is why a vector database is not a memory system.

Summarising older turns compresses the history but decides what matters before knowing what will be asked, and that decision cannot be undone. Summaries also lose the specificity that made the memory worth having: the exact date, the exact preference, the exact constraint.

Your framework's built-in memory is usually a short conversation buffer, which is fine for a demo and runs out when sessions span weeks. When to outgrow your framework's built-in memory covers where that line sits.

The common thread is that all four store or compress conversation, when what the agent needs is a maintained picture of the user. Those are different things, and the second one is what a memory layer is.

How Exabase handles this

Exabase Memory runs on M-1, a memory engine rather than a storage layer. You send conversations or raw text, and it extracts the facts, preferences, and events worth keeping. That much is table stakes. What matters is what happens next.

It maintains rather than accumulates. Relationships between concepts are tracked, contradictions are resolved as facts change, and knowledge consolidates over time. When a user moves from Toronto to Berlin, the picture updates instead of holding both. Old facts stop polluting new context, which is the entity resolution and memory drift problem solved at write time rather than left for the model to sort out at read time.

Retrieval is hybrid semantic and keyword with recency weighting, so recent facts surface above stale ones without you building that logic. Queries can expand into multiple passes and candidates are reranked, so one call returns what is relevant for the task, ranked and ready to drop into your prompt. Simple retrieval runs around 200ms, fast enough to sit inside a live loop.

For multi-user products, Bases scope memory per user, per project, or per agent, each one a fully isolated container with no cross-contamination between tenants. If that is the pressing problem, shipping multi-tenant covers it directly.

You can also choose how memories are written. Send raw conversations and let Exabase infer the structure, or set specific memories directly through the API when you need exact control. Retrieval behaves the same either way.

Why this holds up

Memory systems are easy to demo and hard to get right at scale, so it is worth looking at measured results rather than claims.

M-1 holds state of the art on both major memory benchmarks at every evaluated scale, which no other system currently does. On LongMemEval it scores 96.4 percent against a previous best of 94.8. On BEAM, which was built specifically to defeat context-stuffing shortcuts, it scores 76.9 percent at 100K tokens, 75.0 at 1M, and 68.0 at 10M, leading the previous best at each tier.

Two details matter more than the headline numbers. It achieves this on Gemini 3 Flash while competing systems reported on Gemini 3 Pro, a model 4 to 6 times more expensive, and it consumes roughly 20 percent fewer tokens per query than the next best system. The lead also widens at 10M tokens, the scale where context windows are irrelevant and retrieval architecture is the only thing left. That pattern, better results from less context on a cheaper model, is what a real memory layer looks like from the outside.

The practical consequence is an agent that gets more accurate the longer someone uses it rather than noisier, because the picture is being maintained rather than piled up.

Get started

The Memory page has the API detail and code. For the concepts underneath, what is agent memory and what is a memory layer are the primers, and long-term memory for any agent walks through the integration pattern end to end. If you are comparing options, the agent memory platform comparison and the head-to-heads with Mem0 and Supermemory lay out the differences. There is a free tier to build against.

FAQs

Why does my agent forget between sessions?

Because nothing is persisting what it learned. The model itself is stateless, so unless facts are extracted and stored somewhere retrievable, each session starts from nothing. Appending history postpones the problem rather than solving it, since history eventually exceeds what fits in context.

Can't I just store conversations in a vector database?

You can, and it works until conflicting facts accumulate. A vector store retrieves passages that resemble your query but has no concept of one fact replacing another, so a superseded plan tier or an old address can surface alongside the current one. See why a vector database is not a memory system.

How does it handle facts that change?

Contradictions are resolved when memories are written. A newer fact supersedes the older one rather than sitting beside it, so retrieval returns the current state. That is what prevents memory drift, where an agent slowly becomes confidently wrong about a user.

Do I have to decide what the agent should remember?

No. Send raw conversation text and Exabase extracts the facts, preferences, and events worth keeping. If you want precise control you can write specific memories directly through the API, and retrieval works the same either way.

How do I keep one user's memory from leaking into another's?

Scope each user to their own Base, which is a fully isolated container for memory, files, and search. No filtering logic to get right. Shipping multi-tenant covers the pattern in full.

Is retrieval fast enough for a live agent?

Simple retrieval runs around 200ms, which sits comfortably inside a conversational loop without a noticeable pause.

How good is the recall compared to alternatives?

M-1 is the only memory system holding state of the art on both LongMemEval and BEAM at every evaluated scale, scoring 96.4 percent on LongMemEval and leading BEAM at 100K, 1M, and 10M tokens. It does this on a model 4 to 6 times cheaper than competing systems used, with around 20 percent fewer tokens per query. Details are in the BEAM and LongMemEval write-ups.

Does adding memory increase my token spend?

It usually reduces it substantially, because you stop injecting full conversation history and retrieve a few hundred tokens of relevant facts instead. Reducing your agent's token spend covers the arithmetic.