Personal AI assistants that actually know you
Give your assistant persistent memory that accumulates over time, so it knows the user's preferences, projects, and relationships instead of starting every conversation from zero.

The promise of a personal assistant is that it knows you. It knows you're vegetarian, that your sister's name is Priya, that you're trying to learn Portuguese, that you prefer terse answers in the morning and don't want to be asked how your day was. The reality, for most assistants, is that they know none of this past the current conversation. You tell them, they help, and then they forget, so tomorrow you tell them again.
The model is capable of being a genuinely good assistant. The gap is that it has nowhere to accumulate what it learns about a person, so it can't get to know them across conversations. This page is about closing that gap: giving an assistant persistent memory that builds up over weeks and months into something that actually resembles knowing someone.
The problem
A stateless assistant treats every conversation as the first one. Whatever the user shared yesterday, last week, last month, is gone. The usual patch is to carry recent history forward in the prompt, which works for a single sitting and falls apart over any real span of time. A relationship with an assistant measured in months produces far more context than any context window can hold, so something has to be dropped, and a naive approach drops it blindly.
Storing the conversation logs somewhere doesn't solve it either. A database of past chats gives you persistence without understanding. The assistant can't tell that "I've gone vegan" from March supersedes "I'm vegetarian" from January; it just has two statements sitting in a table with no notion that one replaced the other. Personalisation that runs on stale or contradictory facts is worse than none, because it's confidently wrong about the person it's meant to serve. Keeping a person's model of themselves current is exactly the entity resolution and memory drift problem, and it's why a vector database alone doesn't add up to memory.
There's a quieter point underneath all this, which is that statelessness is a design choice rather than a law of nature. An assistant forgets by default because nobody gave it a place to remember, not because forgetting is somehow correct.
What Exabase unlocks
Give the assistant a memory that accumulates, and it stops being a clever tool you re-brief each time and starts being something that compounds into usefulness.
Over a few weeks it learns the texture of the user's life: the people they mention often, the projects they're juggling, the way they like things phrased, the goals they've set. When the user says "remind me to send that thing to my sister," the assistant knows who the sister is and what "that thing" probably refers to, because it remembers the earlier conversation where it came up. The friction of constant re-explanation just goes away.
It keeps up as things change. The user mentions they've moved cities, switched jobs, taken up a new hobby, dropped an old one. A good memory layer updates the picture rather than stacking new facts on top of contradictory old ones, so the assistant reflects who the user is now, not an average of who they've been.
And it can reach back. The user asks about a restaurant they liked months ago, or a note they made about a book, or the gist of a long conversation they half-remember having. The assistant searches everything the user has saved and surfaces the actual thing, instead of shrugging because it falls outside recent history.
How it works
Three primitives carry a personal assistant. You don't need the whole platform to build one.
Memory
Exabase Memory is the heart of it: the accumulating store of who the user is. Preferences, relationships, projects, goals, recurring topics. You send conversations in and Exabase extracts what matters, so the user doesn't have to explicitly "save" facts and you don't have to define ahead of time what counts as worth remembering.
The behaviour that makes this feel like knowing someone is contradiction resolution. When the user changes, goes vegan, moves house, ends a relationship, the new fact supersedes the old one rather than coexisting with it. The assistant's model of the person stays current. This self-organising quality is what separates a real memory layer from a transcript archive, and it's the thing that lets the assistant get more accurate the longer it's used.
Resources
Resources hold the stuff the user accumulates that isn't conversation: notes, saved articles, documents, links, bookmarks, voice notes. Stored as Resources, this material becomes part of what the assistant can draw on, the user's own library rather than just the record of what they've said to the assistant.
Deep Search
Deep Search is how the assistant finds something specific across everything the user has saved. It searches at the paragraph level, by meaning rather than keyword, so "what was that book about habits I saved?" surfaces the right note even when the user's phrasing matches none of the actual words. It works across all the saved material at once, turning a pile of disconnected notes and articles into something the user can actually ask questions of.
Example architecture
The wiring fits in a few lines, which is rather the point of using infrastructure.
Scope to the user. Most single-user assistants keep everything in one workspace per user. If you're building an assistant product for many users, give each their own Base so one person's memory and material never touch another's; the multi-tenant SaaS use case covers that isolation pattern.
As the user interacts, send conversations to Memory for fact extraction, and store the things they save, notes, articles, voice notes, as Resources. Anything that arrives as audio or a document can go through Extract first to become searchable text.
On each turn, the assistant retrieves memory for relevant context about the user, and runs a Deep Search when the user is asking about something specific they've saved. Both feed the prompt.
Memory and saved material flow in as the user lives with the assistant, and get read back on every turn. The picture of the user fills in on its own.
What compounds over time
This is the use case where the compounding is the entire point, because an assistant that knows you is worth more every week precisely because it's been accumulating.
A new assistant is a blank slate and a slightly tedious one, since you have to tell it everything. The same assistant after three months of use knows your preferences, your people, and your projects well enough that interactions get shorter and more useful at the same time. Because the memory self-organises, that accumulation sharpens the picture rather than burying it, and reliable memory has been shown to cut hallucinations by around 28%, an effect that grows as the memory fills out.
The practical consequence is retention. An assistant the user has invested months of context into is one they're reluctant to abandon, because leaving means starting over somewhere else. The memory is the moat, and it's a moat that gets deeper the longer someone uses the product, with no extra work on your part.
Who's building this
Anyone building a personal assistant, a companion app, a journaling or productivity tool, or any consumer product where the assistant talks to the same person over and over and ought to remember them.
The memory-powered personal assistant example is the most direct starting point, since it builds this exact add-and-retrieve loop end to end. It's worth reading before designing your own.
Get started
Start with the getting started guide, then the memory-powered personal assistant example for the full build. Creating memories and retrieving memories cover the core loop, and there's a free tier to build against.
FAQs
Does the user have to tell the assistant what to remember?
No. Send the conversation and Exabase extracts the facts, preferences, and events worth keeping. The user just talks normally. If you want to let them save specific things deliberately, you can write memories directly as well.
How does it keep up when the user's life changes?
Through contradiction resolution. When the user shares something that conflicts with what the assistant knew, "I've gone vegan" against an earlier "I'm vegetarian," the new fact supersedes the old one rather than sitting beside it, handled by entity resolution. The assistant reflects the current person.
Can it search things the user saved, not just things they said?
Yes. Store notes, articles, bookmarks, and voice notes as Resources and they're indexed for Deep Search. The user can ask about a saved article or note months later and get the actual thing back.
If I'm building this for many users, how do I keep them separate?
Give each user their own Base, which fully isolates one person's memory and material from another's. The multi-tenant SaaS use case walks through the pattern.
How is this different from just saving chat history?
Saved chat history is a record without understanding. It can't tell that one fact replaced another, can't resolve contradictions, and grows into noise rather than insight. A memory layer maintains a current, organised model of the user instead of an ever-growing log. The difference is laid out in why a vector database is not a memory system.
Is retrieval fast enough for a responsive assistant?
Simple memory retrieval runs around 200ms, quick enough to sit in a live conversational loop without a noticeable pause.







