Memory

What a coworker remembers across sessions, and how it's kept from growing without bound.

Three layers

Heartbeat memory — small, per-tick markdown files (last-tick, next-actions, decisions, open-questions) — is the fast, cheap layer every session reads first to reorient.

Memory stores — structured, queryable memories with full CRUD, versioning, and search — sit behind a Postgres durable layer with a Redis LRU read-through/write-through cache in front, so a hot memory is a cache hit and a cold one still resolves correctly.

Dreams — a consolidation job, not a live read path. A dream reorganizes and deduplicates a memory store: it curates what's accumulated, folds near-duplicates together, and archives what's no longer load-bearing, so the store a coworker reads from tomorrow is smaller and more accurate than the one it wrote to today.

Why the split

A coworker should never have to choose between "remember everything" (which gets slow and contradictory) and "remember nothing" (which re-derives the same context every session). Heartbeat covers the first few seconds of a session; memory stores cover a specific fact a coworker needs mid-task; dreams keep both from silently degrading over months of use.

Redaction

Memory that touches PII goes through a redaction pass before it's written durably — a memory store is an audit trail as much as a cache, and the two goals (recall, and not retaining what shouldn't persist) are handled at write time, not left to be cleaned up later.

Related

• Proactivity — the heartbeat tick that reads this
• How it works