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.

1

Write

The Orchestrator writes structured state at every step transition; nothing implicit.

2

Embed

Semantic memories are embedded and tagged with retention rules.

3

Retrieve

Planning queries UDB for state + semantic memory matched to the current intent, scoped by tenant.

4

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.