Agent Memory
Read what agents have recorded: their conversations, what they still carry, and the facts they keep about people.
/platform/memory reads what agents have recorded: the conversations they have had, what they are still carrying from them, and the facts they chose to keep about the people in them.
It sits beside the Object Store rather than under Admin because nothing on this page configures anything: this is data that belongs to integrations, read like logs, traces and stored objects. What an agent declares before any of it is recorded (agentId, memoryThreadId, userId, userMemory) is covered in Agent Memory.
Pick an integration, then an agent in the row above the tabs. The agent list is what has stored something, not what a definition declares.
| Tab | Answers |
|---|---|
| Conversations | What was said, and what the agent still carries from it |
| Facts | What this agent has kept about one person |
| Search | Where is that thing I remember |
The transcript and the live context
Open a conversation and its two forms sit behind tabs of their own.
Transcript is the durable record: what was asked and what was answered, in order, and never compacted. Once a turn is written it is not touched again. A question the agent never got back to is badged rather than hidden.
Working memory is what the agent still carries into its next turn: the same conversation after pruning or summarizing to fit the model's context window. It reports how many tokens it holds, how large it is, which iteration it was checkpointed at, and its version. It also holds what the transcript never does: the tool calls and their results, named on the messages that carry them.
Reading them side by side answers "why doesn't it remember what I told it?": a transcript of forty turns beside a working memory of six means the model no longer knows how the conversation started.
The working-memory payload is the runtime's serialized form, stored by the orchestrator without parsing so the engine can change the format without a schema migration. The viewer decodes it best-effort: the shape it recognizes renders as messages, anything else falls back to raw text with the counts still shown. A conversation that ended cleanly often has no working memory at all, and the panel says so.
What you can and cannot do
Facts are addressed by person rather than by conversation. The people offered are those on the conversations currently loaded, a page of them rather than everyone the agent has ever spoken to.
You can read, search, erase a conversation, and forget one remembered fact. You cannot edit a remembered fact, since rewriting what an agent believes about a person with no audit trail is a capability to ask for explicitly. Erasing reaches the transcript, the working memory, and the conversation itself.
Searching
Search covers an agent's recorded turns and the facts it keeps. Opening a hit takes you back to the conversation it came from. It ranks by meaning when the embedding server is deployed and by words when it is not; the line under the search box says which. It also reports how much is still waiting for a vector, because turning embeddings on starts a backfill, and a search run during it is matched by text.
Where it is stored
Agent memory has real tables (agent_threads, agent_working_memory, agent_turns, agent_user_memories) rather than rows in site_settings, because it has to be queried, paged and searched. Standalone keeps the same data as files under $OCTO_STORAGE_DIR; see Where it is stored.
The tables are keyed on the integration rather than the deployment, so a conversation survives a redeploy. A conversation is attributed to the person it was with, recorded on the first write that names one and never reassigned; that attribution is what lets the chat panel list your own conversations and nobody else's.