Memory Universe is a memory and context layer for a whole team. Every session your people and their agents work in keeps its own memory, and the parts worth keeping move between sessions as your team decides. Keep the agents you already use. The next person picks the work up without a handoff document, a recap meeting, or a repeat of a mistake the team already made.
Free beta test.
Many projects · peer sessions · people and agents with their own identities · private work · governed contributions
Each person has a useful conversation with an agent, but the next person's agent cannot see what that work established. So the team writes the handoff document, holds the recap meeting, and repeats the project decision in a new session.
Written after the fact, out of date by the time it is read, and missing the reason behind the choice.
Six people in a room so that one of them can be told something the other five already know.
The same decision explained again in a new session. Or decided differently, because nobody knew it had been settled.
The hour it costs is the smaller problem. The larger one is two people acting on different versions of the same decision, or someone hitting an edge case the team already found.
A workspace holds many projects and many peer sessions: research, architecture, implementation, product, review, and the work that has not been named yet. Each session has people and their agents in it. Memory Universe connects what those sessions decide and discover, without pretending they all belong in one thread.
Sessions are peers. A research session can contribute to implementation, and implementation can return evidence to review. Neither sits above the other. One workspace holds many projects, one project moves through many sessions, and no session has to become the whole universe.
People bring their agents. A developer may work with Codex while a researcher uses Claude Code. Each agent participates under its own identity. The workspace keeps the path: decisions stay connected to their sources, contributors, evidence and later outcomes.
You do the work in your own session with your own agent. When a result is ready you choose what to contribute: a decision, a constraint, a finding, a fix, an open question. Nobody relocates to the room to chat. The room holds what that piece of work knows. Agents are in it under their own identities, and can address one another.
Three of the four things in that session never left it. The one that did carries her name, and she can take it back.
Precision falls apart past 40k tokens on the mixed corpus — 0.71 down to 0.34.
contributed from her own session · the corpus stayed there
Indexed both runs. The drop is 0.71 → 0.34, and it only appears on the pooled path.
Then budgeting per section is a constraint, not a preference. Here it is as a failing test, so nobody has to remember why.
contributed from architecture · two rejected designs stayed there
contributed from architecture · two rejected designs stayed there
Which of the two runs used the mixed corpus, and does the 40k figure hold for the pooled path specifically?
Both did. And yes — pooled only. On the per-section path precision holds to 0.68 at 64k.
Accepted. Deniz owns the assembler, Elif picks up the callers once his tests pass.
this is now what the project knows
“Open a session for the assembler work and bring in what this room already knows.”
Opened #dev/assembler-budget and carried in the constraint, the decision and the finding.
Nobody drafts in the room. You and your agent close something out in your own session, then contribute the outcome. What lands is a decision, a constraint or a finding. The transcript of getting there stays with you.
The two highlighted turns are one agent asking another and getting an answer, in the room, in front of everybody. No one copied a paragraph between two windows, and both turns are attributable.
Each agent joins under its own identity, bound to the person who brought it. It never borrows their credential. You can always see which agent contributed something and who it is acting for.
A room is live, but nothing in it is disposable. Those four contributions are still there when the next person opens the room.
A CTO asks for something in the engineering room. It ends up back in that room as a decision the whole team holds — by way of one developer's session, and a second pair of eyes. Watch who does what, and notice that no one opens a memory tool or selects anything by hand.
Five moves, five sentences. The one deliberate act is the last one: deciding that something useful should leave the session, and saying where it goes.
A teammate may need to know that architecture work is underway, who owns it, and whether it is active. That does not give them its contents. Session presence and private content are separate facts, and a contribution crosses the boundary only through an explicit, governed path.
Their agents use all of it, every time they work. Yours never sees any of it. Only a deliberate contribution moves between the two.
Where private memory lives depends on the topology you choose. Full-local keeps the authoritative private store on-device. Thin and hybrid modes can use server-readable hosted private storage or a hosted mirror. We do not currently claim an end-to-end-encrypted hosted tier.
A lead writes a rule at workspace visibility. Each authorised member's agent retrieves it through the same shared path it uses for any other workspace context, with the source shown as from workspace. Nobody has to paste the rule into a new chat, and no agent has to guess.
Neither of them pasted it in. The source tag is the point: this is workspace context, not something the model produced inside the current conversation.
One developer's agent formatting code one way while another uses a different standard. A new session crossing an agreed architecture boundary because nobody pasted the decision in. A teammate putting a secret into a prompt because the rule lived in a document their agent never saw.
Not once per person, and not once per agent vendor. The rule is workspace context, and every member's agent reads it the same way it reads anything else.
A workspace-visible rule is readable shared context, not an infallible policy engine. We can show that agents retrieve it. We cannot promise every model obeys every instruction, and we would rather write that down.
The shared session grows cycle after cycle. One person contributes the decision that closed a round; the others add the next useful pieces from their own sessions. When new work arrives it lands in that same session, so the next person continues from the state the team has already built, instead of from a one-off handoff that has gone stale.
Nobody wrote a handoff document this week, and nobody sat in a recap meeting. The four struck-out lines never left the machine they were written on.
And if you share something you shouldn't have, you take it back. The people it went to stop being able to use it, and so do their agents.
Memory should belong to the workspace, not to the vendor that happened to create it. Shared contracts and per-agent identities let context cross agent boundaries without collapsing every agent into one credential.
In the earlier working build, Codex wrote a shared record and Claude Code recalled that same record by ID from a separate session. The architecture begins with Claude Code and Codex, and is designed to support further hosts through the SDK and MCP surfaces. The governed multi-user room experience is being developed for private beta.
A CEO, a CTO, a developer and a research scientist ask the workspace the same thing and get four different answers — shaped for the job each of them has to do. The facts underneath do not change, and neither do the records cited. Only the lens does.
“Give me the launch status: version, window, owner, and rollout plan.”
We ship 4.2.0 in the 14 August window, and Priya owns the retro.
The one thing I would not say out loud yet is the rollout plan — there isn't one in the record. Before you commit to a date externally, get that written down or accept that nobody has decided it.
Version 4.2.0, launching in the 14 August 2026 window. Priya owns the launch retro.
Confidence is high on both — they are asserted directly in the workspace record, not inferred. The rollout plan is the gap: nothing is stored. I cannot tell you from memory whether a staged rollout was agreed and never written down, or never decided at all. That distinction is worth ten minutes.
4.2.0 ships in the 14 August window, Priya owns the retro, and there's nothing in memory about a rollout plan.
Three records support this. Version and window are asserted directly. Ownership is asserted for the retro specifically — not for the launch programme, so I would not read it as programme ownership without checking.
On the rollout plan: absence of a record is absence of evidence, not evidence of absence. The correct statement is that the workspace holds nothing on it, which is a different claim from “there is no plan”.
mem_349f6826…mem_3ef811a3…mem_4d97630e…Your persona lives on your private plane, per person. It shapes how an answer is written and what gets foregrounded. It never enters the shared partition, and no teammate's agent reads it.
All four answers cite the same three records. Nobody is given a softer version of the truth because of their role — the scientist and the developer are told the same thing, at different lengths, with different things pulled to the front.
Every answer names the same gap: there is no rollout plan in the record. A lens that hid that from the CEO because it was inconvenient would be a worse product, not a more polished one.
The next person gets the chosen answer, the constraint that shaped it, the evidence behind it, and the approach that failed on the way. That is what keeps the next agent from confidently repeating a mistake the team has already paid to discover.
Nobody typed a briefing, and nobody called a tool to fetch one. It is there when the session opens, because that is when it is useful.
The approach that failed travelled too. It is usually the most valuable thing in a session for the person who comes next, and it is the first thing a handoff document leaves out.
Nobody learns a memory database, writes a query, or moves their conversations into a new chat product. Ordinary turns become your own private memory. One moment stays deliberate, and it is the right one: deciding that something useful ought to leave your session, and choosing where it goes.
You work in Codex, Claude Code or another connected agent, in your own session. There is no save button and no separate note-taking step. Once configured, each turn is recorded to your own private short-term memory.
When the work reaches a decision or turns up an edge case, you tell the same agent. It distils the recent turns into one coherent piece of context rather than copying the transcript, and promotes it. It stays private unless you ask to share it.
Two shapes. Something the whole workspace should see, or a specific piece sent to a specific session through a proposal, approval, delivery and acceptance path. Private content is refused by the shared server at the boundary. It is not stored there and filtered afterwards.
A lead sets a rule once at workspace visibility, and it appears inside each member's agent carrying its source. Nobody pastes it into a new chat, and the tag shows it came from the workspace rather than from the model.
When Bo continues Dee's work she asks the question her job requires, in plain language, and the answer comes back from the context she is actually authorised to see.
The team's habits do not change. The memory accumulates around them.
The MVP proves these paths separately and in working demos. The private beta is the work of making them one dependable team flow, with real authentication and a finished governance experience. It is a working MVP, not a finished product.
Memory Universe separates the private memory plane from the shared coordination plane. The private side captures and recalls your work. The shared side exists for governed contributions, rooms, cross-user control, device coordination and hosted operations. The boundary is carried in architecture and contracts, not left to a prompt.
the daemon
your devices, and your team
Capture rides the host's own lifecycle hooks, and context comes back as additionalContext at session start, read by the model with no tool call and no turn spent. The cleanest of the three.
Capture hooks into the session rollout and the turn-complete event. Context is handed back between runs through the context file the agent already reads, so again the agent does not spend a turn fetching it.
Both planes are exposed as MCP servers, so any MCP client can read and write memory as a standard tool. This is the path for hosts that do not expose hooks: Claude Desktop today, and anything else that speaks MCP.
For developers who want full control rather than an integration: call the engine and the coordination plane directly, over the same versioned contracts everything else uses. No hidden second engine inside the client.
Why the hooks matter. Riding the host's own lifecycle means nobody has to remember to call a memory tool, and no turn is spent on one. The work is captured because the work happened, not because somebody remembered to ask.
More hosts are on the way, and if your team already has a platform you want this to sit under, we would rather build that integration with you than guess at it. That is part of what the beta is for.
The authoritative private store stays on-device; selected synchronisation supports continuity across your devices.
Local private memory stays primary, with a hosted mirror so the rest of your fleet stays current when the primary is closed.
Install the SDK or agent integration; private memory is held in an isolated, server-readable partition.
Run the commercial coordination server in your own environment, using the same contracts and topology rules.
Hosted private data is isolated and server-readable. Full-local is the stronger location-based option. A hosted end-to-end-encrypted tier is reserved for future work and is not being offered today.
The complete memory engine and the contracts: capture vocabulary, three memory tiers, recall, salience, lifecycle, conflict handling, persona, model routing and graph memory. Full-local is meant to be a good system, not a reduced edition.
The local daemon and host integrations: captures activity, injects relevant context, runs your local stores, and bridges your agent.
Python and TypeScript clients for embedding Memory Universe in agent and application workflows. The SDK is a wire client; it does not hide a second engine.
The machinery required because other users, devices, tenants, governance rules and bills are involved: rooms, governed transfer, the gateway, sync hub, tenancy and metering.
mu-client and mu-server do not import one another. They meet through versioned wire contracts in mu-core. That is why the open half is a whole system on its own.
The local engine, capture client and Python/TypeScript SDKs are built and dogfooded. The commercial coordination plane and the full shared experience described on this page are in development for private beta. github.com/MemoryUniverse ↗
Short answers, including the ones where the honest answer is “not yet”.
Memory Universe is a shared memory and context layer for teams of people and the AI agents they use. Each session — a person working with their agent, or several people and several agents together — keeps its own memory, and the parts worth keeping move between sessions deliberately. The result is that the next person, or the next agent, starts from what the project already knows instead of an empty prompt.
Built-in agent memory usually ends at one user, one agent, or one vendor. It remembers your conversation for you. It cannot show a teammate what you decided, and it does not travel when that teammate works in a different agent.
Memory Universe is memory for the workspace rather than for one chat: many people, many agents, many sessions, with attribution on every shared item and a boundary around what stays private.
Claude Code and Codex CLI are the first integrations, and they use each host's own lifecycle hooks — so capture and context injection happen without the agent spending a turn calling a memory tool. Claude Desktop and any other MCP client can connect through the MCP surface. More hosts are planned, and the SDKs are there for anything else.
Yes. Both planes are exposed as MCP servers, so any MCP client can read and write memory as a standard tool. MCP is also the integration path for hosts that do not expose hooks.
That is a choice, and the honest answer depends on which mode you run. In full-local the authoritative private store stays on your own machine and the coordination server holds no connection string to it. In hybrid your machine stays primary with a hosted mirror so your other devices stay current. In the thin client mode private memory sits in an isolated, server-readable partition.
We do not currently offer an end-to-end-encrypted hosted tier, and we would rather say so than imply a guarantee the architecture does not make.
It is useful alone. The moment you own a second device, your laptop and your phone should not become two conflicting versions of your own memory — that is the same coordination problem a team has, at a smaller scale. The team features sit on top of the same machinery.
The engine is. mu-core (the complete memory engine and the contracts), mu-client (the local daemon and host integrations) and the Python and TypeScript SDKs are Apache-2.0 and public on GitHub. The coordination server — rooms, governed transfer, sync across devices, multi-tenancy and metering — is the commercial part. Full-local is meant to be a good system on its own, not a reduced edition.
You say it. When work reaches something worth keeping, you tell the agent you are already talking to — “make context of this and promote it” — and it distils the recent turns and promotes them. There is no list to browse and nothing to tick. Sharing to the team is a separate, deliberate step, and it can be taken back.
Yes. Each person has a private persona — a voice and relevance lens — so a CEO, a CTO, a developer and a researcher asking the same question get answers shaped for the job each of them has. The facts and the cited records are identical; only the shape changes. A lens never hides an inconvenient gap from one role.
Not yet. The local memory engine, the capture client and the Python and TypeScript SDKs are built and in daily use with Claude Code and Codex. Shared rooms, governed transfer, revocation, multi-device sync and the hosted coordination plane are designed and are what the private beta is for. It is a working MVP, not a finished product.
We are looking for small AI-native teams, and for individuals already working across multiple agents or devices, to shape the private beta with us.
The best design partners have real work split across sessions, care about what becomes shared, and will tell us when recall is wrong, sync is unclear, or a privacy claim needs to be narrower.