AGENT OS · MEMORY LAYER
Memory that doesn't forget. Caches that don't lie.
Structured state, semantic memory, and schema-bound caches that regenerate when systems change.
UDB is the data layer your AI needs to take action, not just talk. It keeps structured state that survives compaction, semantic memory that's auto-retrieved across sessions, and schema-bound caches of expensive queries that quietly regenerate when the underlying systems change. Every record is tenant-isolated and tied to a stable user_ref.
Structured
Survives compaction
Auto-regen
Schema-bound cache
Semantic
Cross-session recall
Three layers of memory
Structured state
renewal_status, last_invoice_id, escalation_owner
Schema-bound cache
monthly active customers (regenerates when schema changes)
Semantic memory
user prefers terse summaries; never on Fridays
Each layer has its own retrieval pattern and its own retention rules.
Why 'just put it in RAG' isn't enough
Three failure modes that quietly kill agent reliability.
Compaction eats critical facts
Auto-summarized chat memory keeps tone and loses numbers. The single ID the next step needs vanishes mid-conversation.
Caches lie when schemas change
Pre-computed views go stale silently when the upstream table is renamed. The agent confidently quotes last quarter's mapping.
Tenant data leaks across users
RAG indexes without strict tenant boundaries return another customer's note when the embedding happens to be close.
What UDB does
Four memory properties that turn an LLM into a teammate.
▦
Structured state survives compaction
Critical facts live in typed records, not in chat scrollback. The Orchestrator pulls them in deterministically — they never get summarized away.
↻
Schema-bound caches that regenerate
Expensive queries (active customer counts, monthly revenue) are cached against the schema they depend on. When the schema changes, the cache invalidates and regenerates.
✸
Semantic memory, auto-retrieved
Preferences, prior decisions, and recurring patterns are embedded and pulled in at planning time without the user re-stating them. RAG with proper retention, not infinite scrollback.
⊟
Tenant + user isolation by default
Every record is keyed by account_id + user_ref. Cross-tenant retrieval is impossible by construction, not by query convention.
How a memory enters and leaves UDB
Write paths, retrieval paths, and the regeneration loop.
Write
The Orchestrator writes structured state at every step transition; nothing implicit.
Embed
Semantic memories are embedded and tagged with retention rules.
Retrieve
Planning queries UDB for state + semantic memory matched to the current intent, scoped by tenant.
Regenerate
When a schema dependency changes, schema-bound caches mark themselves stale and rebuild on next access.
Memory layer, honestly compared
What UDB gives you vs. the alternatives.
| Capability | Interactor UDB | ChatGPT / Cowork | Build from scratch |
|---|---|---|---|
| Never loses critical facts | Yes — structured | Partial (CLAUDE.md) | 1+ month |
| Remembers across sessions | Yes — auto-retrieved | Improving auto-memory | 2+ months |
| Caches that regenerate | Yes — schema-bound | No | Yes — careful design |
| Tenant + user isolation | Yes — by construction | Per-account only | Easy to get wrong |
| Time to a reliable memory layer | Weeks | N/A | 3–6 months |
What we're improving
Today's memory is basic RAG. We're upgrading it.
Embed + cosine similarity + top-k works, but it weights a six-month-old memory the same as yesterday's. We're adding temporal decay, a reranking pass, and structured memory types (facts vs preferences vs decisions) so retrieval matches what humans would actually surface.
Hand us a memory horror story
Tell us what your AI keeps forgetting. We'll model the right UDB record types and show you the retrieval — live.