The Three Memory Realms

A user's memory in this platform is not one store. It is three — three folds of memory, each a different aspect. They are formed differently (how each one is created), they mean different things (what each one represents), and they are designed for different purposes. Apart, each does one job. Together, they give an agent a versatile, wide solution for recall — the ability to bring back anything: what is true, what happened, and what is kept at hand.

Most "agent memory" designs reach for a single vector store: embed everything the user ever said, everything the agent decided, everything they bookmarked, and search it all at once. That flattens three irreconcilable aspects of memory into one undifferentiated pile. This platform refuses the collapse, and gives each fold its own realm:

mem — the distilled-knowledge aspect. A small, stable, always-available set of what is true about the user — the curated durable entities that make future conversations behave correctly. (It is co-managed because it must stay curated.)
conv — the temporal/episodic aspect. What actually happened, anchored in time and in the context it was produced in. (It is automatic and uncurated because it has to capture everything as it happens.)
cnv — the thematic working-context aspect. The things gathered at hand, by theme, across worlds — proxies to objects from many realms on one board. (It is deliberately set aside because a person chose and arranged it.)

Three folds, three realms. Which aspect each captures is the headline; who keeps it and what is done with it follow from that. The rest of the article takes each in turn, then shows why the folds cannot share one store — and why, together, they recall more than any single store could.

The full picture of recall: three folds, each answering a different question — together they cover the whole space of bringing something back.

Why flattening fails

The three aspects demand contradictory storage shapes, so no one store can serve them. Distilled knowledge must be small, stable, always-on — a handful of curated entities, loaded every turn. The episodic record must be the opposite: complete, literal, time-anchored — every prompt, file, and error string kept untouched, because that is what a user re-quotes and what re-opens an old artifact. Working context must be neither — a set of cross-world pointers a person gathered by reference, each still owned by the realm it came from.

Small-and-always-on, complete-and-literal, and gathered-by-reference cannot be the same store. Force them together and each degrades: the fact drowns in transcript, the literal trail gets distilled away, the gathered set scatters. So the platform keeps three. The sections below take each in turn.

`mem` — curated durable entities

mem captures the distilled-knowledge aspect: a small, stable set of what is true about the user. It holds the entities themselves — discrete, persistent, curated knowledge entities (facts, preferences, durable decisions, reusable anchors, specs, milestones) that survive across conversations so future ones behave correctly. It is explicitly "user-visible, editable, cross-conversation."

Because these are durable entities that must stay clean, the realm is co-managed — both parties curate it:

The user manages it directly. A memory widget lets the signed-in user search, add, edit, pin, and remove their own memories; only user-visible memories are exposed to the user-facing UI.
The agent proposes, a reconciler refines. Writes are explicit-only — memory.propose, the reconciler, or the widget — never a silent capture from chat. The reconciler can later merge, weaken, or retire records as evidence accumulates.

That co-management is the defining trait. Nothing lands in mem by accident; something becomes a durable memory only when the user does it, or asks for it, or a policy explicitly allows the agent to propose it.

A memory record separates two fields, and is tiered so the important ones stay hot while the rest stay searchable:

memory   the compact, canonical note — a trigger plus a rule
context  why it exists — provenance, examples, rationale

Records carry a kind (an open vocabulary: fact, preference, decision, constraint, spec, milestone, …), scores for confidence/importance/freshness/salience, and a tier. The canonical reference is mem:record:<id>. The hotset — a bounded, high-salience slice (default eight) — is the one piece of memory pushed into the agent's turn preparation without being asked for; everything else is searched on demand. (Pinning a memory "to the hot set" is a distinct gesture from pinning a card to a cnv board; keep the two senses of "pin" apart.)

The agent reads and writes mem through named-service operations (search_objects, object_schema, upsert_object, object_action for confirm/retire) and the exact-read path react.pull(["mem:record:<id>"]).

`conv` — the temporal record of what happened

conv captures the temporal/episodic aspect: what actually happened, anchored in time and in the context it was produced in. To keep that aspect intact it has no curator — the runtime persists every turn block as a side effect of operating, and it is explicitly "not user-visible, not curated." It is not managed; it is recalled from. And because it records the interaction as it happens, it captures, for free, the two things the other realms drop: when each thing happened, and the context it was produced in.

That is conv's distinguishing purpose. Contrast the trio: mem deliberately strips context away, distilling a moment down to a standalone fact; cnv only points at an object, a proxy card with no surrounding history; conv preserves the full provenance — the time-ordered position of an item and the turn and conversation it arose in. So conv is not "a chat log." It is a temporal timeline of memories of very different kinds, where every item keeps its place in time and its source.

The conv timeline: mixed memories on one time axis, each anchored to its turn — and the working summary threads the produced & attached URIs back to their bytes.

It holds the temporal aspect. The timeline is, first, an ordered record: user prompts, the agent's working contributions, tool calls and results, working summaries, and assistant completions, each a first-class block in sequence. The "when" is not incidental — every block carries its own turn_id and ts, and pruned turns even render with their start timestamp, so the time-ordering survives compaction. Working summaries are emitted by the agent on its summary channel and land on the same turn in order, not as later post-processing.

What the realm holds is a precise set. Searchable in conv is exactly: what the user said — prompts and follow-ups; what the assistant said — replies and working summaries; the user's attachments — their indexed summaries; and the working summaries themselves. Each item carries a logical path that names where it came from — which turn, and (across conversations) which conversation:

ar:<turn_id>.user.prompt                 what the user said, in that turn
ar:<turn_id>.assistant.completion        what the assistant replied, in that turn
ws:<turn_id>.conv.working.summary        the turn's own working summary
fi:<turn_id>.outputs/<relpath>           a file produced in that turn
fi:<turn_id>.user.attachments/<name>     a file the user attached, in that turn
so:sources_pool[...]                     a fetched source, in its turn's context

The working summary is the thread that ties the record to its artifacts. A working summary does not just paraphrase the turn — it also records the URIs of what was produced and what was attached (its Refs: section lists the turn's ar:/fi:/tc: handles). That is how a produced file or an attachment stays re-findable later, anchored to its turn: search the summaries, and the summary hands back the URIs of the actual bytes.

These are stable handles, not throwaway labels. So retrieving a conv item recovers more than its content: a produced file comes back anchored to when it was made and in which turn's conversational context it arose. Artifact discovery is this recovery: artifacts are reconstructed from timeline blocks by matching logical paths, then loaded by path or materialized as owner objects.

That provenance reaches across conversations, too. The realm is durable and indexed beyond the visible window — the timeline, sources pool, and turn log are persisted as conversation artifacts, with files and attachments hosted separately and referenced from block metadata. A path beginning fi:conv_<conversation_id>.turn_<id>... carries its own conversation scope, so even a file from another conversation arrives still knowing the conversation and turn it was produced in. That is what "the automatic record" buys: the full temporal and contextual provenance of what happened, kept without anyone curating it.

The realm is searchable and readable by the ReAct agent's tools: the agent searches it with react.memsearch — by topic, time window, turn ordinal, or scope=conversation|user — and reads the referenced artifacts with react.read. It is also exposed as the conv named service: a read-only provider over the same conversation index, sharing the exact run_conversation_search backend that powers react.memsearch.

`cnv` — a focus board of cross-world references

cnv is the canvas: a focus board — a workspace pulled up while working. Think of the marginal notes scribbled beside a page to keep something at hand, except the notes are not text but objects and URIs. While working, the user (or the agent) sets a memory, a task, a file, or a whole conversation aside on a board to bring back later. That is the aspect the other two folds don't cover: the working-focus aspect — what is kept at hand right now.

The crucial distinction: the board holds nothing of its own. Like a marginal note pointing back at the real page, each pin is a reference — cnv gathers proxies to objects that live in other realms, arranged by theme. Where mem holds curated entities and conv records the episodic stream, cnv points. A research board, an incident board, a board for one project: each is a context assembled by reference from many worlds.

A cnv focus board: four pins, four worlds. Each pin is a reference that resolves home — the board holds the cards, the realms keep the objects.

That is also the precise mechanic: a pin is a proxy to any object from any published namespace — so a single themed board spans worlds. Side by side on one board:

mem:record:<id>               a memory, from the memory realm
task:issue:<id>               a task, from a task-tracker app
task:attachment:<id>          a file attached to that task
fi:<turn>.outputs/…           a file the agent produced
fi:<turn>.user.attachments/…  a file the user attached (in chat or on the board)
conv / chat ref               an entire conversation, pinned to reopen later

The card holds only a canonical handle, its provenance, layout, and any annotations; the object itself stays with the world that owns it, and resolves back there. That is precisely why cnv is a context, not an entity store: it spans namespaces by reference. It is co-curated — the user drags, arranges, and signals; the agent suggests and pins — and it is the connective tissue of a user's memory, because one board can carry a mem entity, a conv conversation, and a third-party task together, each still owned elsewhere.

How those proxies are ingested, displayed, materialized for an agent, and routed back to their owning apps is the subject of its own piece — "The Pinboard Of Proxies" — which we do not re-derive here. For this article the point is cnv's role as the third realm: the thematic, cross-world working context, distinct from the curated entities of mem and the temporal record of conv.

Why three and not one

The three capture three different aspects of memory; who manages each follows from the aspect it captures:

Three folds, three memory contracts — distinguished by the aspect each captures.
Axis	`mem`	`conv`	`cnv`
Aspect captured	distilled knowledge	temporal / episodic	thematic working context
Why it's needed	what is true about the user	what actually happened, when & where	objects gathered at hand, by theme
Holds or gathers	holds curated durable entities	records the stream + provenance	gathers proxies across worlds
Who manages it	agent and user, together	nobody — runtime records it	user arranges; agent suggests
Curation	curated, explicit-write-only	uncurated, automatic	deliberately set aside
User-visible & editable	yes (widget)	no	yes (board)
Always-loaded	yes — bounded hotset	no — recalled on demand	no — attached on demand
Lifecycle	scored, reconciled, retired	indexed, TTL, never edited	revisioned board, soft bin
Canonical ref	`mem:record:<id>`	turn URIs (`ar:`/`fi:`/`ws:`/`so:`)	`cnv:<name>` (or proxied ref)

One store cannot be small-stable-always-on distilled entities and a complete time-anchored record and a hand-arranged set of cross-world pointers at the same time — the three folds have mutually exclusive shapes. Formed differently, meaning different things, designed for different purposes: that separation is exactly what makes recall wider. Between them, the three folds cover the whole space of bringing something back.

From the agent's seat, the three answer three different questions:

"What is true about this user?"        -> mem   (the curated entity, always loaded)
"What happened, and in what context?"  -> conv  (the turn, its time, its artifacts)
"What did we set aside for this?"       -> cnv   (the board, its cross-world pins)

Each question has exactly one fold that answers it well, and no fold answers another's. A preference is in mem, not buried in last week's transcript. The exact file produced three turns ago — and when and in which turn — is in conv, not flattened into a fact. The handful of things gathered for this project is on a cnv board, not scattered across either. Together they let an agent recall almost anything; and cnv keeps them connected — a pin can proxy a mem entity or a conv conversation and still resolve home.

A brief note on the plumbing: all three realms are reachable as named services, which is what lets one agent recall across them in a single namespace language and lets a realm be offered to any connected agent. For how a named service introduces itself — intro versus provider.about versus object_schema — see the companion Short How a named service introduces itself. The same mechanism is how apps publish realms that are not part of the platform: a task-tracker app publishes a task namespace exactly the way the memory app publishes mem — which is also why a cnv pin can proxy a task:issue: in the first place.

Where this is going: portable memory

Because each realm sits behind a provider, it can be offered beyond the chat app's own agent — to a user's assistant elsewhere.

The path is the Connection Hub plus MCP. The co-managed realm already demonstrates it: the memories app exposes an MCP endpoint with memory_search and memory_get, guarded by Connection Hub delegated credentials, each tool declaring the grant it needs. A user's own Claude could search their durable memories through it.

That is the direction: portable memory. The automatic record (conv) and the set-aside boards (cnv) are not on MCP yet — but they already sit behind the same provider shape, so exposing them is a publishing step, not new retrieval work. The memory a user keeps with one agent becomes memory they can bring to the agents they choose.

Three folds — formed differently, meaning different things, designed for different purposes — kept apart so each stays true to its aspect, and reachable together so an agent can recall what is true, what happened, and what is at hand. That is the wide, versatile recall a single store can never be.

Documentation on GitHub

The live docs behind this entry: