Unison vs Zep - Team Brain vs Temporal Knowledge Graph
Zep builds a temporal knowledge graph per user; Unison builds one per project, shared by every agent and human on the team. Where each fits.
Zep and Unison agree on more than most pairs in this category: both reject vector-soup memory, both model knowledge as a temporal graph where facts change over time. The difference is what the graph is about.
Zep's graph is about a user. Sessions, messages, and entities accumulate per user; the canonical question is "what does this user's history imply right now?"
Unison's graph is about a project. Many agents and humans write into one workspace; teams and private lanes coexist; the canonical question is "what does the team know - and which of it does this session need?"
| Zep | Unison | |
|---|---|---|
| Graph scope | per user | per workspace, with /workspace/teams/ and /private/ lanes |
| Temporal model | fact validity intervals | bitemporal facts + supersession + asOf reads |
| Multi-agent writes | n/a (single-user design center) | conflict review queue, actor delegation |
| Recall surface | search + memory APIs | one-call contextMd with abstention flag |
| Document tier | n/a | scope-by-path markdown filesystem (+ unison-fs mount) |
| Agent messaging | n/a | backchannel |
If your product is "an assistant that remembers its user," Zep is a reasonable choice. If your problem is "five sessions across three harnesses and two people keep re-learning and contradicting each other," that's the problem Unison is shaped for.
Migrating from Mem0 to Unison - Team Memory vs Personal Memory
Mem0 remembers the user. Unison remembers the project. The operation-by-operation mapping and what changes when memory becomes shared.
Why a Bigger Context Window Doesn't Fix Agent Memory
Even at 1M tokens, a context window resets every session - and context rot degrades quality long before the window is full.