Granted, not inherited

Memory should belong to you — not the apps that use it.

Every tool keeps its own stale copy of you — and none of them can hand it on. memox makes memory a property of the person or company it's about: one time-aware record, permissioned per fact.

Join the waitlist

For people. Your memory, captured and private by default — and yours to grant a slice of, for as long as you choose.

See how it works

For companies. One memory layer for your product and your team. Authorized per fact, bi-temporal by default.

pip install memox  ·  one MCP endpoint  ·  self-host on your own keys

Works with

Every tool keeps its own copy of you. None of them can move.

Your agent remembers one version. Your CRM another. Your notetaker a third. Each partial, each going stale, none knowing what changed or what it's allowed to know.

At company scale it costs money: support hears a customer is unhappy on Tuesday; sales upsells them on Wednesday.

The shift

Borrowed permissions don't travel.

Other memory tools do check permissions. But look at where that permission comes from.

  • Never from you. It comes from an admin's API key, a chat channel you happen to be in, your role in the company directory, or whatever an app was allowed when it was first connected.
  • So the memory only works where that thing works. Leave the channel and it doesn't follow you. It can't reach another company, or your own hands.
  • memox turns it around. The permission comes from you — the person or company the memory is about — so it travels with you.
in scope key channel role source boundary granted · in scope refused · at the boundary one record a person an app granted · the subject decides
One memory, kept honest

How it works

It all grows from one starting point — you. Scroll to watch the record build.

It starts with you.

Memory becomes a property of you — one place that is yours, not scattered across the tools that touched it.

Fed by your sources, kept as sourced facts.

Calls, notes, documents. memox lifts durable facts from the noise, each stamped with when it was true and the exact quote it came from.

What was true then, and what you believed then.

Facts are superseded, never overwritten — and both clocks are kept. Ask what is true now, what was true in March, or what the system believed in March. Only the last explains why an agent acted.

One record, every tool that needs it.

Agent over MCP, app over REST, dashboard, webhook — all read the same living memory. No more ten copies drifting apart.

Nothing leaks past who's allowed.

Every read is authorized per fact, before the query touches the data. Out of scope is refused up front — not filtered out after.

Share a topic, not your whole memory.

A standing grant, time-boxed and revocable — not a one-off approval you re-issue. When it lapses it stops resolving; no revoke step to forget. Others can learn relevant memory exists without seeing a word of it.

Shared memory for a whole team.

Shared topics the team reads by role. One model from just you to a whole org — no second system bolted on.

On the roadmap

Carried onward.

You arrive at a new tool and it does not start from zero. With your consent it asks your memory, and you are already known.

One memory. Yours. Granted — never borrowed — everywhere it's needed.

Not features — consequences

Two things fall out of the shape. Neither is retrofittable.

01 — Permissions

Permissions, resolved before the query.

  • Others have permissions — but the grant is always inherited: a key an admin minted, a channel you're in, a directory role.
  • So their memory can never leave the access list it was born inside.
  • In memox the grant comes from the subject, compiled into the query itself.
  • Borrowed permissions don't travel.
02 — Time

Time, kept as a timeline.

  • Facts are superseded, never overwritten.
  • Every fact carries both clocks — when it was true, and when memox learned it.
  • "True in March" and "believed in March" are different questions. Only the second explains why an agent acted.
VALID TIME — TRUE IN THE WORLD London Berlin 14 Mar TRANSACTION TIME — WHAT MEMOX KNEW London Berlin 02 Apr 19 days true, but not yet known
For builders

Your product's memory layer — that your users can carry onward.

  • A real memory layer on day one — durable facts, bi-temporal, cited, authorized per read.
  • MCP server, REST API, self-hostable engine. Model-agnostic.
  • One call returns what an agent should know now: stable facts, what changed, open commitments.

Pick it for the memory layer alone. That a user can later carry memory onward is upside, not a dependency.

Join the waitlist 
// point any MCP client at your memox server
{
  "mcpServers": {
    "memox": { "url": "https://you.memox.dev/mcp" }
  }
}
// → context_pack, search_memory, get_commitments, answer —
//   each call scoped to what this client is granted.
from memox import Memox
mx = Memox()                         # your key, your tenant
pack = mx.context(subject="user_42") # one call
# → { stable: [...cited facts...],
#     changed: [{ was, now, since }],
#     commitments: [...open...] }
curl https://you.memox.dev/v1/context-pack \
  -H "Authorization: Bearer $KEY"

# → stable facts · what changed · open commitments,
#   each line cited to the memory it came from.
For people

Your second brain — private by default, and portable.

Point memox at your own sources — calls, notes, chats, docs. It keeps one honest, time-aware memory of what's true about you.

  • Private by default.
  • Sourced & time-aware — nothing unsourced, nothing overwritten.
  • Share a slice, revoke anytime.
Join the waitlist
Trust

Memory that never leaks past who's allowed.

  • Every read authorized per fact, with tenant isolation underneath as a hard wall.
  • Grants time-boxed. Discovery never discloses content. Every access audited.
  • Self-host on your own keys — your memory never becomes someone else's dataset.
request REBAC GATE resolved before the read allowed slice ✓ the rest ✗
Per-fact ReBAC Every read is authorized fact by fact, before it resolves.
Tenant isolation Enforced per request at the data layer underneath — a hard wall.
Time-boxed sharing Every grant is revocable and expires on its own.
Discovery, not disclosure Relevant memory can be found; content stays gated until granted.
Fully audited Every access leaves a record.
Encrypted In transit and at rest.
Self-hosted keys Your infrastructure, your keys — never someone else's dataset.
THE DIFFERENCE

They build memory for an agent. We build memory for you.

The good ones ship real access control — we won't pretend otherwise. The difference is what a permission is about. Theirs answers "what may this agent's key touch?" Ours answers "who did this person allow to know it?"

Capability memox mem0 Zep Supermemory
Semantic recall Yes —✓ Yes —✓ Yes —✓ Yes —✓
Bi-temporal — true then vs. believed then Yes —✓ No —✗ Partial —~ Partial —~
Verbatim provenance Yes —✓ Partial —~ Partial —~ Partial —~
Per-fact check before the query runs Yes —✓ No —✗ Partial —~ Partial —~
Standing, time-boxed grant to another person Yes —✓ No —✗ No —✗ Partial —~
Permissions on every tier, not only Enterprise Yes —✓ No —✗ No —✗ Partial —~
MCP-native Yes —✓ Yes —✓ Partial —~ Yes —✓
Self-hostable Yes —✓ Yes —✓ Partial —~ Yes —✓

Publicly documented capabilities, July 2026; names belong to their owners. The partials are real — Zep's access control is scoped to an API key on Enterprise; Supermemory checks a relationship-derived permission before retrieval in its Slack product. Neither lets the subject issue a standing grant.

FIG. 12 — FAQ

Frequently asked questions

Is it open source?
Source-available and fully self-hostable — your own infrastructure, your own keys. Hosted is optional.
How is this different from a vector database?
A vector DB does similarity search. memox stores durable facts with provenance, a timeline of what changed, and a permission check on every read. Vectors are one part of recall, not the product.
How is this different from mem0, Zep or Supermemory?
They are good: Zep has access control and a temporal graph; Supermemory has scoped keys, versioning and a pre-retrieval check. So “nobody has permissions” would be false. What none has is a permission that originates with the subject — theirs is inherited from a key, a channel or a role. That is why we can offer a standing, time-boxed grant across owners and they cannot.
What does "time-aware" mean?
Every fact tracks when it was true and when memox learned it. Nothing is overwritten — ask what is true now, or what was believed at any past point.
Does an app have to give up owning its users' memory?
No. It gets memox as its own memory layer, like any other — and can additionally connect to a person’s memory, with consent. Nothing is surrendered.
Do I share my whole memory?
No — you share one topic with one person, time-boxed and revocable, with discovery-without-disclosure. Never all-or-nothing.
Is my data private?
Self-host with your own keys, or use hosted with encryption, per-request isolation and a full audit log. Never sold, never used to train models.
MCP / frameworks?
MCP-native: point any MCP client at one endpoint. Plus REST and a Python client; model-agnostic.

Give your memory a place to live.

Not open to the public yet. Leave an address and we'll write when there's something real to try.

Join the waitlist Talk to us
MEMOXFIG. 1ISO 30°2026

Join the waitlist

Not open to the public yet. Leave an address and we'll write when there's something real to try.

No spam. One email when it's ready.

You're on the list

We'll write to when there's something real to try. Nothing before then.