Explainer
An AI agent's memory is not one thing but four separate stores, and each survives a different set of events: a model switch, a restart, a new phone, a different channel, and the moment you press delete. Most products that list "memory" mean only the least interesting of the four - the chat scrolls back. So the question worth putting to a vendor is not "does it have memory" but "what survives what". This page answers it for Olano, as a table, with the limits left in.
A language model keeps nothing between calls. Everything an agent appears to remember has been put back in front of the model by the system around it, and there is more than one place it can have come from. Blurring those places is how a features list ends up saying "persistent memory" about a product that will not recognise you on a second device, or that forgets a correction the moment you open a new chat.
Our earlier piece, How AI agents remember, explains the layers conceptually, and the memory and knowledge chapter of the manual covers the controls. This page is narrower and more literal: for each store, which events it survives and which it does not, and what you can do about the ones it does not.
Each answers a different question, and none can stand in for another.
The resumable state of one thread: what the model is handed when that conversation continues. It is persisted on the deployment, so closing the browser and coming back next week changes nothing. Sometimes called a thread checkpoint.
The readable record of the same thread, kept separately: every message and who wrote it, badged with the channel the conversation came from, with its running cost. It is what the chat view renders and what the background learning pass reads. A record, not the thing the model resumes from.
MEMORY.md, a curated file of durable facts, plus a dated daily log. The agent reads MEMORY.md and today's and yesterday's daily logs at the start of every turn, in every conversation, on every channel. Plain markdown you can open and edit.
Documents and web pages you supply, indexed for search. Nothing from it is in the prompt until the agent looks something up, so it can hold a great deal without making every turn slower or costlier.
The context window is what the model can see right now: the instructions, the tools, the memory files, the skills and the messages of this conversation, all sharing one bounded space. Memory is where things are kept between turns so they can be placed into that window again. The two are related and not the same, and the difference shows up in cost as much as behaviour. Whatever sits in the window is paid for on every turn; whatever sits in a store costs nothing until it is fetched.
Olano makes the split visible. A context bar in the chat header shows how full the conversation is, and typing /context opens a breakdown of how much room the system prompt, tools, memory files, skills and messages are each taking. When a thread approaches the model's limit, older turns are compacted in place so it keeps going rather than forking; /compact does that on demand, and /new starts a clean thread, which is the right move whenever the subject changes.
Two notes on the count. The manual describes four layers with skills as one of them and treats a conversation as a single thing. Here skills are left out, because a skill is a procedure rather than a memory (see how an agent learns a new skill), and a conversation is split into the two stores it actually is - the state the model resumes from and the record you read - because they answer different questions the moment you ask what deletion does.
One row per event, one column per store.
| Event | Conversation state | Transcript | Written memory | Knowledge base |
|---|---|---|---|---|
| You switch the model, for one conversation or for the whole agent | Survives. The thread continues on the new model with its history intact. | Unchanged. | Unchanged. It is a file, not part of any model. | Unchanged. |
| The deployment restarts, for an upgrade or after a fault | Survives. Conversation state is persisted on the deployment, not held in a process. The one thing lost is a reply that was in progress at the instant of the restart; the chat says so and offers Retry. | Survives. | Survives. | Survives. |
| You pick up a different device | Same thread. Open a conversation on a laptop and a phone and both follow it live; a device that was asleep catches up on its own when it comes back. | Same record. | Same file. Memory belongs to the agent, not the device. | Same index. |
| You talk on a different channel | A messenger chat is its own thread, and every thread is in the agent's list: a conversation that arrived on WhatsApp or Telegram can be opened and replied to from the dashboard, though a reply typed there is recorded in the thread rather than sent out to the messenger. | Each conversation is badged with the channel it came from; a message that arrived by a different route from its thread is badged on its own, and every message shows who wrote it. | Read on every channel. This is the store that carries what the agent knows about you from WhatsApp to the dashboard and back. | Searchable from every channel. |
| A conversation grows past the model's limit | Older turns are compacted in place so the thread keeps going. Detail from early in a long thread can drop out of the model's view. | Older calls drop out of the per-conversation cost breakdown, so an opened conversation accounts for part of the agent's total rather than all of it. | Unchanged. | Unchanged. |
| An admin deletes the conversation | Purged. | Purged, for everyone who could see it. | Not touched. Anything the background pass already distilled from that chat is in a memory file, which you edit or clear yourself. | Not touched. |
Written memory is the one built to be edited. The Memory tab shows MEMORY.md three ways - an outline of sections and facts, a rendered view, and the raw markdown - and offers two ways to write: a quick-add form that appends a single fact to a section you choose (leave the section blank and it goes into today's daily log instead), and a full editor that replaces the whole file in one save. If the agent changes the file while you have the editor open, a banner says so before you overwrite it. An edit takes effect on the agent's next reply, with no restart. The same files sit in the Files tab and on disk, so a text editor works too.
Because these are files, they have history. Every meaningful change to configuration and markdown files is committed to a revision history and attributed to the agent or person who made it, so you can see what an agent changed in MEMORY.md last Tuesday and what a config looked like before an edit. Two consequences follow. A wrong fact is a one-line fix. And a fact you remove is gone from the agent's next prompt but still visible in the revision history: for conversations, delete removes the state and the transcript; for memory files, it means edited, with a trail. If you have data-deletion obligations, one setting keeps memory files out of that history, because they carry distilled personal data.
The transcript you read rather than edit. It is what the chat view shows when you reopen a conversation, badged with the channel it came from and carrying its running cost. Conversation state you never touch directly; you act on it with /new, /compact, Rename and Delete. The knowledge base is managed from the Knowledge section: add files and URLs, create named stores so different bodies of material stay separate, sync a directory, list what is indexed, remove sources you no longer want.
One variant worth knowing about: where an agent serves many end customers, each customer can be given their own isolated memory rather than one shared file. That is a multi-user setting, covered in multi-user agents.
The knowledge base is the store that grows without touching the prompt.
Manuals, price lists, policies, past proposals, reference PDFs: documents someone might ask about. The agent does not carry them in its head; it searches when a question calls for it and quotes what it finds, so the answer follows your document rather than the model's general knowledge.
Indexing runs in the background and is throttled so it never slows a live conversation; a large upload is searchable shortly after it finishes, not instantly. The index is built inside the deployment by a small embedding model the platform runs itself: no external embedding service, no extra key, no GPU.
Add the new version, or sync the directory it lives in again, and the agent answers from that. Remove a source and it stops being retrievable, so the index does not keep quoting a document you have withdrawn.
Across the knowledge base, the agent's workspace, its memory, or a named store you created. Memory itself can be indexed for meaning-based search, so something the agent learned months ago is findable without having to sit in the prompt.
Four things any memory system has to admit, and how each shows up here.
A thread that outgrows the model's window is compacted rather than cut off, which keeps it usable and costs precision: a detail from early in a very long conversation may no longer be in the model's view. If something must not be lost, put it in memory or a document rather than trusting a long thread to hold it.
Distillation is the model's judgement of what mattered, and it can be mistaken or out of date. That is why it lives in a file you can read and fix rather than in weights you cannot: edit MEMORY.md and the correction applies on the next reply. Keep the file short, too. It is read on every turn, and a filing cabinet in the prompt makes every reply slower and costlier.
The knowledge base is consulted when the agent decides a question calls for a search. A well-indexed document raises the chance of a grounded answer; it does not force one. If a document must shape every reply, a short standing fact in memory does that job and the document backs it up.
Self-learning is a background pass, hourly by default, not something that happens the instant a message lands. Within a thread the agent has the conversation itself; what carries to other threads arrives after the pass has run, and a thread deleted before then contributes nothing.
All four stores live in your own isolated deployment. What an agent learns stays there: there is no pooling across customers, and the model provider sees only what a given turn places in front of it, retrieved passages included, exactly as it sees the conversation itself. Conversation state and the transcript are per agent, and deleting a conversation removes it for everyone who could see it, which is why that action is reserved for admins and the agent's owner. Written memory and the knowledge base belong to the agent and are yours to read, edit and remove. The wider posture - isolation, credentials, audit - is on the security page.
None of this is without limit. The window is bounded, memory should stay short, and the knowledge base is only as good as the search that reads it. What a deployed agent can promise is narrower and more useful than "it remembers everything": each thing you tell it has a place, that place survives the events above, and you can see and change what is in it.
It depends which store the vendor means. In Olano a conversation is a durable thread: reopen it next week, on any device, and the agent continues with its history. What carries between conversations is written memory - MEMORY.md and a dated daily log, distilled from transcripts in the background and read at the start of every turn. Documents you supply are a third store, searched on demand rather than remembered.
The context window is what the model can see on this turn: instructions, tools, memory files, skills and the messages so far, in one bounded space. Memory is where things are kept between turns so they can be put back into that window. Anything in the window is paid for on every turn; anything in a store costs nothing until it is fetched. Olano shows the split with a context bar in the chat header and the /context command.
Yes. Conversation state is persisted on the deployment rather than held in a process, so a thread continues after a restart, and it deliberately survives switching the model mid-conversation. Written memory and the knowledge base are unaffected by either: one is files, the other an index the deployment keeps. The one thing a restart loses is a reply that was in progress at that instant, and the chat offers Retry.
In Olano, deleting a conversation removes both the state the model resumes from and the transcript, for everyone, and only an admin or the agent's owner can do it. What that chat had already contributed to written memory is in MEMORY.md or a daily log, which you edit or clear yourself; those edits are kept in a revision history. Documents leave the knowledge base when you remove the source.
Across devices, yes, and it is the same thread: open a conversation on a laptop and a phone and both follow it live. Across channels, each conversation is its own thread: a WhatsApp chat can be opened and replied to from the dashboard, although a reply typed there is kept in the thread rather than sent out to WhatsApp. Written memory is read on every channel, so what the agent knows about you carries from WhatsApp to the dashboard and back.
The index is built inside the deployment by an embedding model the platform runs itself; no external embedding service, extra key or GPU is involved. When the agent answers, it places the passages it retrieved in front of the model you chose, as it does with the rest of the conversation. The knowledge base is per deployment, and nothing is pooled across customers.
Where to go next.
The controls for every layer on this page, in manual form.
The conceptual piece: memory, knowledge and skills as four layers.
Why what an agent learns lives in files you can read, not in weights you cannot.
Where these stores live, who can reach them, and what is audited.
If an assistant has lost something it should have kept - a customer's preference, a decision, a document - describe the moment. We will say which of the four stores it belonged in, and whether that needs a deployment or just a better filing habit.
