Memory
What the runtime keeps — preferences, corrections, and outcomes that compound.
Memory is the difference between a tool you operate and a runtime that knows you. It is a deliberately small layer on top of the context graph that persists three things across runs. Preferences: the standing facts you state once — invoices go out on the 1st, briefs are 250 words, the tone with this client is formal. Corrections: every time you edit a run's output, the delta is kept and surfaced to future runs of the same shape, which is why the third draft of your weekly brief needs no editing. Outcomes: what happened after the run — the email that got a reply, the plan that was approved unchanged — so the runtime learns which of its behaviors actually worked. Everything in memory is inspectable and editable: the dashboard shows every remembered item, where it came from, and which runs have used it, and you can correct or delete any of it. Memory is scoped like everything else — project-level by default, shareable to a team explicitly, never global — and it is excluded from training the same way all customer data is. Forgetting is a feature: items unused for a configurable window decay out, because a memory that only grows becomes another inbox.
[ 01 ]Key features
Preferences, stated once
Standing facts persist across runs — formats, schedules, tone — so prompts stop carrying the same boilerplate.
Corrections that stick
Edit an output and the delta informs every future run of that shape. The system converges on your taste measurably.
Fully inspectable
Every remembered item is visible in the dashboard with its provenance and usage — correct it or delete it at any time.
Decay by design
Unused memories age out on a window you control. The runtime remembers what keeps mattering, not everything.
[ 02 ][ memory item ]
{
"id": "mem_b1290f",
"kind": "correction",
"shape": "weekly_brief",
"learned": "lead with deadlines, cut the preamble",
"source_run": "run_8810cc7d",
"used_by": 14,
"last_used": "2026-06-09",
"decay_window": "90d"
}