UnisonWhy 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.
Even at 1M tokens, a context window resets every session - and as it fills, context rot degrades model quality before it ever gets full.
Three reasons the window can't be the memory
- It resets. The window is working memory, not storage. Every new session starts at zero; nothing learned yesterday exists today unless something external re-supplies it.
- It rots. Attention quality degrades as unfiltered context accumulates. Long sessions contradict their own earlier decisions - more tokens, worse answers, higher bills.
- It's yours alone. A window is private to one session. Your teammate's agent, your CI agent, and tomorrow's session can't read it. Team knowledge can't live somewhere only one process can see.
What the window is actually for
Holding the relevant slice, freshly selected. That's the division of labor: Unison stores everything durably (documents, entities, bitemporal facts), and context recall injects only what this task needs - with weakEvidence honesty when the brain doesn't know.
window = working memory (small, fresh, per-session)
brain = long-term memory (durable, shared, queryable)
recall = the selector between themThe teams that scale agents don't stretch the window; they externalize memory and keep the window short. Quickstart.
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.
Why Not Just Use a Vector Database for Agent Memory?
A vector DB gives you similarity search over chunks. Agent memory needs visibility scopes, fact supersession, conflict handling, and prompt-ready recall - the layer above the index.