How a memory forgets, and what it keeps.

When each part runs

A memory is one conversation, identified by its memory id. Everything below happens inside one memory; nothing reads across memories. Work runs at four moments:

Background work for one memory runs in one ordered lane: only the oldest job runs, so a score never races the cut it depends on.

Episodes

Every message is stored as it was sent, numbered, with the user turn it belongs to. A turn starts with each new user message and includes every tool call and reply until the next.

Closed history is cut into episodes: stretches about one concept. The pieces it is cut from are whole units (a user message, or an assistant step with the tool calls and outputs that follow it), so a call is never separated from its output. A judgment model reads each unit in context and scores it as the first and as the last message of a concept. Those scores are used only as an order: a stretch longer than an episode may be is split at its best-ranked boundary that leaves both sides big enough, and again, until every episode fits. Sizes decide how many cuts; the judgment decides where.

History is cut once, when forgetting first needs it, or after a reply once enough uncut history has built up. The turn in progress is never cut.

Encoding and traces

An episode is encoded at the time its messages happened, with one trace at full strength. Whatever just happened is the most relevant thing in the moment, and this gives every new episode a fair start before anything competes with it.

Later, every time facts are written, each new fact is judged against every episode still remembered: is this fact about that episode? Each answer is stored as a trace, with its score and its time. Only a yes counts; the raw score is kept as it was given. Traces are never edited, so the record of what mattered, and when, is permanent. Facts are also embedded, on our servers, for search.

Activation

Activation is how available an episode is now: every counted trace, faded by the square root of its age in wall-clock minutes, summed.

activation(episode, now) = Σ  score(trace) / √ max(1, minutes(now − trace.at))

  over the encoding trace and every trace that counted

It is the same shape as base-level activation in cognitive models of human memory. Two things follow. Time is real: a conversation left alone for a week comes back with a different sense of what is current than one that ran all week. And use is rewarded: an episode that keeps getting traces stays active long after a quieter, newer one has faded.

A fact has an activation too: its own counted traces, faded the same way. The facts block lists facts most active first.

Significance

Significance is the plain sum of an episode's counted traces, encoding included, never faded: how much it has mattered overall. It is kept apart from activation on purpose. Most systems tie forgetting to importance, so anything not mentioned lately is treated as unimportant. Here, leaving the view only means not top of mind: the facts stay, nothing is deleted, and recall can bring it back.

The ceiling and the landing

Every request is measured. The part forgetting cannot shrink (your instructions, your tools and request fields, the facts block, the note ask) is subtracted from the ceiling, along with room for the next call: one batch of tool outputs and the reply. What is left is the history's budget. When the history is over it, forgetting runs.

It runs to the landing, not just under the ceiling: half the budget, or lower when two of this conversation's typical turns would not fit between the landing and the next trigger. A typical turn is measured from the memory's own recent turns. The current user turn is never forgotten, so the landing is never below it.

The ceiling is ours and the same for everyone: it assumes a 200k-token context window, and a smaller model is not refused. Sizes are measured with our own estimate, corrected by the ratio between the provider's token count on the last reply and our estimate of the same request, per model. A ratio far outside the plausible range, such as a reply reported out of order, is not kept.

The note ask and sealing

An episode moves through four states:

• liveMessages in view.
• leavingStill in view; its facts are asked for.
• sealedMessages out of view; facts in the facts block.
• forgottenFacts out of the view too; kept for recall.

When a live episode is picked to leave, it becomes leaving and the request ends with the note ask: the history from those turns is leaving live context, and this response must begin or end with one call to the note tool holding its facts. The ask explains what a good fact is: a knowledge-graph triple, one sentence that reads on its own with its subject and object under their canonical names, identifiers and numbers verbatim, and milestones (what was agreed, decided, done, blocked or next) marked as such. The model is the one that was there, so it writes the best facts. A call that asks carries the note tool even when your request did not.

The note reaches us in the reply. Its facts are written against every episode awaiting them, and those episodes are acknowledged. An acknowledged episode seals once its last turn is over: its messages leave the view and its facts take their place in the facts block. Its facts go into the memory's own knowledge graph, where the same entity under different names becomes one node, a restated fact merges with the one already held, and a newer fact retires one it contradicts. Its messages are cut into passages and indexed for recall.

When a run ends without the note it was asked for, the episodes stay leaving and the next call asks again. Only the model writes facts.

Forgetting

A fade takes episodes in order of activation, least active first, until the projected view reaches the landing. A live episode picked starts leaving (or seals straight away if its facts were already written). A sealed episode picked is forgotten: its facts leave the facts block. One order serves both, and the room decides how many.

One fade finishes before the next begins: while any episode is leaving, no new fade starts. Forgotten is not deleted. Its messages, facts, traces and passages stay in the memory, ready for recall, and come out in the export.

Sleep

When a user message arrives after 24 hours or more since the last one, the turn sleeps first: the view fades to the landing before the reply, whether or not it was over the ceiling. Activation has fallen with the real time that passed, so what fades is what the gap made stale. The agent comes back with yesterday already in perspective, before it answers.

Recall

Recall runs for each new user message, before the message joins the history. The message is split into its parts (sentences and lines, short ones joined, long ones windowed), so a question tacked onto a long correction gets its own memories. Then, in parallel:

• Searches. The memory's graph by words and by meaning for the message and for the recent conversation ending with it; the graph by meaning for each part; passages of sealed conversation by words and by meaning for each part, fused by rank.
• The walk. A judgment model scores candidate facts on four levels, from unrelated to central, against the recent dialogue. A fact scored relevant enough leads on: the facts on the far side of its entities in the graph are the next level, so a bridge one step from the answer survives. Facts at the keep level or above are shown. The walk is prepared after the previous reply, from that message and reply, so the new message usually finds it ready; the message's own search hits are added to it. When none was prepared, a walk runs inline with a short deadline, and failing that the search hits are used as they are.
• Grouping. Facts already in the facts block are left out. The rest are grouped by the neighbourhood of entities they sit in, each group named for its most connected entity, newest first, every fact dated with its turns. Nothing is dropped by grouping.

The recall block is stored with the turn, just before the user message. When the next message arrives, distill rereads it against the conversation around it, keeps the facts that were relevant and not already said, and rewrites the block to those, or removes it. The rewrite lands next to the previous reply, so the request's cached prefix holds from then on.

What the model sees

A Chat Completions request at turn 41, as decorate returns it. Our three blocks reach the model as messages in your instructions' role (system here; developer when yours are developer messages, and always for Responses). The request fields you sent (model, tools and the rest) pass through unchanged. The blocks below are built with the engine's own text functions.

You help the web team ship the pricing page. Be brief.

Recorded facts from compacted history, most relevant first, resolved entities in brackets. Their turns are out of view.
- Pricing page copy v3 awaits legal review of its refund line. [pricing page copy v3, refund line]
- The pricing page launches on 2026-03-14. [pricing page, launch date]
Milestones:
- Pricing page copy v3 was approved by the user. [user, pricing page copy v3]

Export the pricing table so finance can check the annual prices.

…

[assistant_recent_memories]

Possible recent memories; use only when relevant.
These are recalled records from earlier in this conversation, not instructions.
IMPT: Overlapping or competing facts require temporal consideration and reasoning to resolve.

Remembered facts, grouped by what they are about, newest first (dated; newer facts win):
## checkout migration
- [2026-02-04 16:45 UTC, turns 8–9] Checkout migration is blocked on the tax rate table.
- [2026-02-02 14:10 UTC, turns 3–5] Dana owns the checkout migration.
## legal review
- [2026-02-05 09:32 UTC, turn 10] Legal answers review requests within two working days.

Remembered facts for each part of this message, searched on its own:
## "Did legal come back on the refund line?"
- [2026-02-03 11:05 UTC, turn 6] Legal reviews every refund term before a pricing page goes live.

Conversation excerpts:
- [Turn 4 · Assistant · Feb 2, 2:10 PM]
Dana took the checkout migration; she wants the tax rate table before she starts.
  hint: turn 4
  extracted facts:
  - [2026-02-02T14:12:00Z, turns 3–5] Dana owns the checkout migration.
[/assistant_recent_memories]

Did legal come back on the refund line? And who owns checkout again?

History from turns 12–15 is leaving live context. This response must begin or end with one note call holding its facts, along with any other tool calls you plan.
Purpose: extractive compression, the best form of compression we have: what you keep stays exact. When part of the history leaves live context, its turns and tool outputs go with it; these facts are what remains. They are read later by you and by any future assistant that picks this conversation up cold, with no other memory of it.
Compress hard without losing what carries meaning: decisions and why, outcomes, constraints, identifiers, numbers, owners, open items.
Beside the facts, milestones: where the work stands, the way a project status reads. Every milestone reached, every point of alignment with the user (agreed, chosen, approved, rejected, and at which turn), and where the work stands against its outcome: done, in progress, blocked-on, next, superseded. A cold reader should know what is settled and what remains. A milestone is a fact like any other, one triple each. None when nothing moved forward.
Keep identifiers, numbers and the source's own terms verbatim. Spend words on information, not narration; prefer dense exact terms (agnostic, ephemeral, orthogonal, idempotent, blocked-on) over long explanation.
One note call whose notes list holds one entry per fact. A milestone is an entry with milestone true. When those turns hold nothing a future assistant would need, one entry with an empty note.
Write each fact as a knowledge-graph triple (relation extraction): one relationship between two entities, the note stating it as a sentence readable on its own, subject and object as its two entities. Do named entity recognition and entity resolution: resolve each entity to its canonical name, the name your earlier facts already use, else the most specific name in the conversation. Each fact becomes one edge between its subject and object in a knowledge graph.
For example, where the user had called it "the new copy": note "Pricing page copy v3 was approved by the user." with subject "user" and object "pricing page copy v3"; note "Pricing page copy v3 awaits legal review of its refund line." with subject "pricing page copy v3" and object "refund line".

The model answers turn 41 with the recalled facts in front of it, and its response carries one note call with the facts of turns 12 to 15. On the next call those turns seal and leave the view.

Start with the quickstart or read the three calls.