Skip to content
@MemoryUniverse

Memory Universe

The persistent session and memory layer for teams of people and their AI agents — across users, devices, agents and vendors. Open engine, governed sharing.
Memory Universe

The persistent session and memory layer for teams of people and their AI agents.

Your agent remembers. Your teammate's agent remembers. Neither remembers the project.

So we write handoff documents for an assistant that already knew everything that happened, then hold a meeting to explain the document. That is not a memory problem. It is a session problem.

Memory Universe makes the session the thing that persists. People and the different agents they choose join it, work in it, branch off it privately, leave, and return — across machines and across vendors — and the project context is still there. Private stays local. Shared is governed.


The system, in one picture

Memory Universe architecture. On your machine, Claude Code and Codex feed the mu-client daemon, which runs the mu-core engine over your own stores; private memory stays there. On the shared plane, mu-server provides the gateway, governed rooms, sync hub and tenancy over a shared partition. The only thing crossing between the planes is the versioned wire contract, which the SDKs also speak. mu-client and mu-server both depend on mu-core, and neither imports the other.

Four repos, and the shape of the relationship between them is the product:

mu-core engine + contracts The complete memory engine — capture, extraction, three tiers, promotion and demotion, conflict resolution, ranking, persona, the model router, the local graph — plus the vocabulary every other repo speaks. Runs with no server and no API key.
mu-client the daemon on your machine Captures your Claude Code and Codex sessions, keeps them on your own device, hands context back without being asked. Start here to use it.
mu-sdk-python · mu-sdk-js wire clients The same verbs from your own code, in two idioms.
mu-server coordination plane Governed rooms, the sync hub, the gateway edge, multi-tenancy, metering. Commercial, and not yet public.

Three rules hold that diagram together, and they are enforced rather than asserted:

  • mu-client and mu-server never import each other. They speak only the versioned wire contracts in mu-core. An import-linter contract fails the build if that stops being true.
  • The private/shared boundary is a physical partition, derived from the namespace — not a WHERE clause. A query-filter bug cannot cross it.
  • No memory content in logs, traces, the event bus, or metering. Events carry ids, hashes and counts; bodies are fetched by id, by whoever is authorized. The meter cannot read your memory.

Containers and how they talk

Memory Universe C4 container diagram. A team member works in their AI coding agent — Claude Code, Codex CLI or an MCP client — which mu-client captures from through the host's own lifecycle hooks and injects context back into. mu-client is a Python asyncio daemon holding a SQLite WAL outbox; it reads and writes your own Valkey, Qdrant, FalkorDB and SQLite stores over TCP on your machine, and runs the mu-core engine in process. mu-client and mu-server exchange sync deltas and room posts over HTTPS REST, WSS and MCP — the only crossing, carrying versioned wire contracts. mu-server is a FastAPI coordination plane that reads and writes shared Postgres, Weaviate, FalkorDB and Valkey stores, dispatches crash-safe sagas to Temporal over gRPC, and runs the same mu-core engine. The mu-sdk library calls mu-server over HTTPS REST. The engine calls external model providers over HTTPS to extract, embed and rerank.

A C4 container view: every box says what it is and what technology it runs on, and every arrow says what flows and over which protocol. Three of those edges carry the whole design.

The capture loop. The agent never spends a turn deciding to remember — mu-client captures through each host's own lifecycle hooks and injects context back the same way.

The one crossing. mu-client and mu-server exchange only versioned wire contracts. They never import each other, and an import-linter contract fails the build if that stops being true.

The same engine, both planes. mu-core runs in process on your laptop and in process on the server. Full-local is not a reduced edition — it is the identical engine with nobody else involved.

Where Temporal sits, and why it isn't on your laptop. The shared plane runs Temporal for crash-safe sagas — DISTILL, PROMOTE, TRANSFER, RevokeCascade — optional at self-host, degrading to a named inline_dispatch fallback. Shipping a Temporal cluster to every laptop was rejected on footprint, so the local plane gets a right-sized equivalent: a SQLite WAL outbox with synchronous=FULL and fsync-before-ack, which is what makes promote-before-delete survive a crash mid-flight. Same guarantee, sized to the plane that needs it.


What teams actually do with it

Recall runs two arms and fuses them once

Recall runs two arms: a private arm authorized by partition on your device, and a shared arm authorized by an explicit set of ids. They are fused and deduplicated once, at the end, and never share a store handle.

Your private memories are authorized by partition — only your data is in there, so no id list is needed. Shared memories are authorized by an explicit set of ids. The two are joined only at the end, and no cross-plane store handle is ever opened. One index with two access rules is a leak waiting for a bad day.

Verbs: recall · ask · inject

Branch private off shared work

A shared room feeds context into a private session. The automatic write-back is blocked; the only crossing is an explicit share verb, which is scoped and revocable.

Take the team's context into your own session and work messily — wrong turns, dead ends, half-formed ideas. Nothing leaks back: the crossing is blocked on post-back, and sharing is a deliberate act with a scope and a revoke receipt. There is no auto-bridge.

Verbs: recall · share · revoke

Pull a colleague into your session

Two people using different agents, Claude Code and Codex, both post to and read from one live session. Every turn stays attributed to its own person and agent.

Sometimes you don't want to hand work off — you want someone in it with you. Share the session itself, and two people with two different agents work the same context, live. Not a screen share, not a pasted summary. Each agent participates under its own identity, owned by its human but not wearing their credential, so which agent decided this has a real answer.

Verbs: join · post · bind

Leave, return, promote

A session timeline: work happens, you leave, the session persists while nobody is present, you return at the stored cursor, and selected context is promoted into the project as a governed, expiring, revocable packet.

The session persists while nobody is in it. You come back at the cursor rather than at the top, and what deserves to outlive the session gets lifted into the project as a governed packet. Most tools give you persistence; the third beat — promoting context out under governance, with expiry and a revoke receipt — is where the control actually lives.

Verbs: leave · join · promote · publish

Continue on another machine

A laptop and a desktop each keep their own sync log and cursor and converge to one private memory. Revoking a device cascades a signal that stops it.

Start on the laptop, continue on the desktop, same project and same private memory — not because your private data was copied to someone else's cloud, but because each of your devices keeps its own log and its own cursor, and they converge. Revoke a device and the signal cascades.

Verbs: capture · recall · revoke

Solo, team and agent swarm are one runtime

Three room configurations — two humans, a human with a shared agent, and five collaborating agents — all resolve to the same runtime, branching only on participant kind and floor policy.

A human is simply a participant whose agent principal equals its own owner. So the system branches on participant kind and floor policy — never on "is this an agent session". Everything true of your team room is already true of your agent swarm: ordering, attribution, private overlays, governance. You do not get a second, weaker product for the agents.

Verbs: open · join · post · close


Four properties, not four features

  • Multi user. Participants are real principals with roles and per-fragment authorization, not seats sharing one context.
  • Multi device. Your private memory converges across your own machines, each keeping its own log and cursor, rather than being copied to a cloud.
  • Multi agent. Your agent participates under its own identity, not your credential, so which agent decided this stays answerable.
  • Multi provider. Claude Code, Codex, others — and a local path that needs no API key at all.

Where the line falls

The open half is the complete engine. With zero API keys it still works, because every model group has a local path. Full local is not the crippled tier.

The commercial half is only what exists because other people are involved: governance, shared rooms, the sync hub, multi-tenancy, metering. A solo local user needs none of it, so keeping it server-side costs them nothing.


Honest status

Built and used daily: the local engine, the capture client, both SDKs, the three memory tiers, promotion and demotion, bi-temporal conflict handling, recall — dogfooded against real Claude Code and Codex sessions.

Designed and in progress: shared rooms, governed transfer between sessions, revocation with receipts, the hosted coordination plane. Several diagrams above describe that half.

Gaps we would rather say out loud: coreference resolution is string canonicalization today, and retrieval quality rests on a small hand-labelled probe rather than a public benchmark.

Nothing here is presented as available that is not.

It started as our bachelor thesis, Multi-User Agentic Memory Framework for LLM-Based Agentic Systems. It is now being built as something people can actually run.


memoryuniverse.github.io/landing · questions and disagreement welcome in issues

Popular repositories Loading

  1. mu-core mu-core Public

    The Memory Universe engine and contracts — memory tiers, recall, lifecycle, conflict handling, persona and graph memory. Apache-2.0.

    Python 3

  2. mu-client mu-client Public

    The Memory Universe local daemon and agent host integrations — capture, context injection and local stores. Apache-2.0.

    Python

  3. mu-sdk-python mu-sdk-python Public

    Python SDK for Memory Universe — a wire client for agent and application workflows. Apache-2.0.

    Python

  4. mu-sdk-js mu-sdk-js Public

    TypeScript/JavaScript SDK for Memory Universe — a wire client for agent and application workflows. Apache-2.0.

    TypeScript

  5. memoryuniverse.github.io memoryuniverse.github.io Public

    Memory Universe — public site. /landing is the landing page; docs and more to follow.

    HTML

  6. .github .github Public

    Organization profile for Memory Universe — the README rendered on github.com/MemoryUniverse.

Repositories

Showing 6 of 6 repositories

People

This organization has no public members. You must be a member to see who’s a part of this organization.

Top languages

Loading…

Most used topics

Loading…