Skip to main content
Memory is a governed knowledge layer that gives your models memory and your own documents in one place. It learns durable facts about each of your end-users from every conversation, lets you ground answers in documents you add, and keeps both in a single knowledge graph so a request can recall the relevant facts and passages together, automatically. You do not resend context on every call and you do not wire up a separate retrieval step: send a user id, add your documents once, and Memory does the rest. You will find Memory under Services > Memory.

​
Turning Memory on

Use the Enabled switch in the top right of the page. It takes effect the moment you flip it, so there is no separate save step. While it is off, nothing is stored and nothing is recalled, even if a request carries a user field or names a collection. The page has four tabs: Memory (facts and the knowledge graph, per end-user), Documents (your collections), Settings (retrieval configuration), and Activity (the audit log). When you disable Memory and there is stored data (facts or collections), you are asked whether to keep or delete everything. Keeping it leaves all data in place so retrieval works again the moment you re-enable the service; deleting clears every fact and document, and cannot be undone.

​
Identifying the end-user

Long-term memory is scoped to your end-users, not to your workspace as a whole. To associate a request with a specific end-user, include "user": "<your-end-user-id>" in the chat-completions body, the same field OpenAI uses:
Without a user, the platform has no identity to attach facts to: nothing is learned or recalled for that end-user, though a request can still be grounded in your workspace’s documents (see below).

​
How retrieval works

By default, Memory runs one blended search across the caller’s personal memory (when a user is supplied), the workspace’s shared knowledge, and every collection in it, and injects the most relevant facts and passages as context before the model runs. Nothing needs naming: the blend covers all of it in a single pass. This suits an internal assistant, where a question may span HR and Legal and the person asking should not have to know which collection holds the answer. Retrieval runs whenever there is something to consult: a user was supplied, or the workspace holds at least one ready document. A request with neither triggers no retrieval and is not augmented.

​
Narrowing to one collection

Name a collection and the request reads only that one, plus the caller’s own personal memory. The workspace’s shared knowledge is not included: “only this collection” means only this collection. Use it when a workspace holds knowledge that must not mix. A customer-facing bot built on a workspace that also holds internal documents should read only the public collection; an agency running a collection per end client should read only that client’s. The field is collection everywhere: on chat completions, on the Memory search endpoints, and as the argument to the MCP knowledge-search tool. It accepts a single slug or a list of them:
Chat completions previously called this field rag. It was accepted but never applied: a request naming a collection was answered from the whole workspace. It is now rejected with a 422 telling you to use collection, rather than ignored, so a caller that still sends it finds out instead of quietly getting a wider answer than it asked for. A slug your workspace does not have is rejected with a 422, naming the slug. It is never ignored and never quietly widened back to the blend, so a typo surfaces as an error rather than as an answer drawn from more than you asked for. Every response carries an additive sources array (empty when nothing was retrieved) naming what was recalled, grouped and ordered by relevance: one entry per source document or collection, plus one grouped entry for memory facts. Use it to show your users what grounded an answer. If a request opts into retrieval (by supplying a user, or by the workspace having ready documents) and the knowledge graph is unavailable, the platform returns an error rather than quietly answering without the context you expected.

​
How facts are learned

After each exchange, an EU-sovereign model extracts facts from the end-user’s message in the background. Two kinds are kept. What is true about them, meaning still true a year from now: who somebody is, what they prefer, what they are responsible for, who and what they work with, and the standing instructions they give about how to be answered. What happened to them: a trip they took, a thing they bought, a place they went, an amount they spent, a length of time something took. These are kept because “how many times did I go to the gym last month” is a question about the person, and it cannot be answered from what is true today. Each carries the day it happened. What they want in the moment or are in the middle of is not remembered, and neither are the names inside one of those. Somebody asking you to open a page is not somebody who wants that page. New facts are reconciled against what is already known for that end-user: changed ones update, contradicted ones are retired. This runs after the response is returned, so it adds no latency to the call your user is waiting on.

​
Retired is not the same as forgotten

A retired fact stops being retrieved and is not deleted. It keeps the day it stopped being true, so an export and the graph can still show that it held and when. A fact retires either because a later one contradicted it or because a day it named has passed. Something that happened does not retire, because it does not stop having happened. A trip taken in March is still a trip taken in March next year. These are held until the end-user’s memory is deleted, and they are covered by the same export and deletion paths as everything else. A forgotten fact is gone. Removing one from the Memory page, calling the forget tool, and erasing an end-user all delete the fact outright rather than dating it, and nothing brings it back: it is absent from retrieval, from the graph, and from every export, including a subject access request. That is the difference to reach for when somebody asks you to remove something about them. A conversation’s messages are extracted together, a few minutes after the first of them, rather than one at a time. Extraction over several turns resolves references a single message cannot (“book the same seat as last time”), and it is billed once per batch instead of once per message. The practical consequence: something an end-user says becomes memoryable in another conversation a few minutes later, not instantly. Within the same conversation nothing waits, because its messages are already in every request you send. Extraction runs on one EU-sovereign model at one rate, with nothing to configure. There were briefly two tiers to choose between; they differed by a rounding error in price, and the cheaper one was worse at recognising that two mentions were the same thing, so the choice cost more than it saved.

​
Facts that start or stop on a day

A fact can carry a span when the message states one. “I am resigning on 1 October, until then reach me at jelle@example.com” gives the address an end date: it is retrieved until that day and not after it, without anybody having to say so again. “From 1 November I am in the Berlin office” is the same in reverse, and is not retrieved before that day arrives. A date is only ever read from something that resolves to a calendar day, including “tomorrow” and “next Monday”, against the day the message was written. Anything vaguer is left alone. “At some point”, “soon” and “once the merger closes” are not days, so those facts simply hold until something contradicts them, which is what every fact does by default. A date the model is unsure of would take a true fact out of memory on a day nobody chose, so it does not guess. Ending works the same way. “I left Northwind on 1 August” retires the job on 1 August rather than on the day it was mentioned.

​
Shared conversations

A conversation in Akumi Chat can be shared with named colleagues. A shared conversation carries no personal memory: nothing a person has taught Akumi about themselves is blended into it, and nothing said in it becomes a stored fact. Blending one member’s personal facts into a prompt whose answer everyone else in the conversation reads would disclose them to the room. The workspace’s own knowledge still reaches a shared conversation as normal; it is the personal scope, and only the personal scope, that is withdrawn. A conversation’s payload carries member_count: how many colleagues it is shared with, excluding its owner. A private conversation reads 0, and shared is any count above 0. Clients say this in these words:
Shared threads carry no personal memory. What you have taught Akumi about yourself stays out of conversations other people can read.
That sentence is the canonical wording, used verbatim wherever the disclosure appears, so one governance decision is never described two ways.

​
Managing facts

The Memory tab lists every stored fact, with a graph view (the entities and relationships a selected end-user’s facts form) and a list view (search by end-user or text, sortable and filterable). Each row shows the fact’s content, the end-user it belongs to, and when it was added. Use Delete on any row to remove a fact immediately. Each fact also has a Promote to collection action. Promoting moves the fact into one or more of your document collections: the fact’s text is ingested as a document in each collection you pick, and the fact is then removed from personal memory. Once promoted, the content is retrieved as part of the workspace’s shared knowledge for any request, regardless of which end-user sent it. Use this when a fact should be available to everyone rather than scoped to a single end-user. The action is disabled until you have at least one collection.

​
Grouping a conversation

thread in the chat-completions body names the conversation a call belongs to. It groups your calls on the Observability page, where one conversation reads as one thing rather than as scattered rows. It works without Memory and costs nothing. It stores nothing. The platform keeps no transcript under a thread and replays nothing into the next call, so send the messages the model needs on every request, as you would to any OpenAI-compatible API. With Memory on, a conversation’s turns are extracted together under their thread (see How facts are learned above).

​
Collections and documents

Your workspace keeps documents in one or more named collections: separate, walled-off knowledge bases. You add documents to a collection; the platform reads them into the same knowledge graph as memory facts. A document belongs to exactly one collection. Every collection is included in the blended retrieval by default, and a request can name one to read it alone. You will find collections under the Documents tab.
  • Create a collection with New collection and give it a name. The platform derives a URL-safe slug from the name (“Support docs” becomes support-docs). Your plan sets how many collections you can have: Pay as you go includes one, and Team, Business and Enterprise are unlimited. At the limit, New collection is disabled with an upgrade prompt.
  • Rename a collection from its row. Only the display name changes: the slug is fixed when the collection is created, because it is the value your requests send to read that collection, and moving it would break them.
  • Delete a collection from its row; its documents and their chunks are removed with it.
  • Open a collection to manage the documents inside it.
Open a collection to add documents. Paste text (with a title), upload files, or both in one go.
  • Upload files. Drop or choose one or more PDF, text (.txt), or markdown (.md) files, up to 20 MB each. Each file becomes its own document, so this doubles as a bulk import. PDFs are read for their embedded text (a scanned, image-only PDF has no text to extract and is marked failed).
  • Paste text. Give a title, an optional source label, and the body text.
Processing happens in the background: a document appears as Processing, then becomes Ready once it has been parsed, chunked, and written into the graph, or Failed with the reason if its text could not be read. Rename and Delete are available on each document’s row. A document cannot be moved between collections. Its content is stored under the collection it was added to, so moving the row alone would leave the content behind and the document would stop being retrievable. To reclassify a document, delete it and add it to the collection you want. Documents are scoped to your workspace and to the collection they belong to. Retrieval only ever draws from your own workspace’s documents, never another workspace’s or another tenant’s.

​
Erasing an end-user’s memory (GDPR)

To remove all long-term facts for a specific end-user, for example when they delete their account in your app, call:
This removes every stored fact for that end-user, scoped to your workspace. The deletion is permanent and runs synchronously. Wire it into your user-deletion flow so Memory does not outlive the account it belongs to.

​
Exporting an end-user’s data (GDPR)

To hand an end-user a copy of everything Memory holds about them (GDPR Article 15), call:
The response returns the end-user’s facts, cursor-paginated with next_cursor so you can page through everything. Documents are your workspace’s shared knowledge base rather than that end-user’s personal data, so they are not included in the export.

​
Exporting everything your organization holds

The per-end-user export above answers “tell me everything you hold about this person”. To take out everything your organization holds, across every workspace, use Settings > Data export in the dashboard. That is a dashboard action rather than an API endpoint, because exporting an organization is an administrative act by a person rather than something your application does. See Data export for what the file contains, what it deliberately leaves out, and how long it lasts.

​
Metering and records

Memory meters each part of the lifecycle separately:
  • Extraction is metered once per learned turn, at a single rate.
  • Ingest is metered once per document, scaled to how much of it there was to read into the graph.
  • Retrieval is metered once per request that triggers a blended search, whether or not it found anything relevant.
  • Storage is a recurring meter on the tokens your collections hold, measured per month. Your plan includes a free allowance; usage beyond it is metered on top.
Every extraction, ingestion, retrieval, promotion, configuration change, and deletion also writes an entry to the audit log, visible on the Activity tab and under Platform > Audit logs. Those entries record counts and item ids only, never the content of your facts, documents, or prompts.

​
Good to know

Personal memory needs a user; document retrieval does not. A request without a user is never augmented from personal memory and never triggers extraction, but it can still be grounded in your workspace’s documents if any are ready. Extraction and embedding stay in the EU. The models that read conversations, derive facts, and embed documents run on EU-sovereign endpoints, and the graph lives in an EU-resident store. Facts are per end-user, not per workspace. Each end-user’s memory is isolated from every other user’s, within your workspace and across tenants. Promoting a fact to a collection is the one deliberate way to make its content workspace-wide.