A good way to understand React memory is to stop asking “where is the memory store?” and instead ask “what kind of memory is this?” A prompt, a plan snapshot, a plan acknowledgement, a pulled file, a source row, a feedback reaction, a compaction summary, and a terse internal note are all memory, but they live in different surfaces for different reasons.

1. Timeline memory is the durable event history

The timeline is the conversation’s temporal source of truth. It stores prompts, attachments, assistant completions, tool calls, tool results, plan snapshots, feedback blocks, system notices, and compaction summaries. That makes it much richer than a plain chat transcript.

But React does not always see the whole durable timeline. What the model consumes is a rendered session view after pruning, compaction, replacement rendering, cache-point placement, and attention-area append. So the visible context is a derived view over deeper memory, not the whole durable store itself.

2. The attention area is always-on-top memory

React keeps two rolling tail surfaces together: SOURCES POOL and ANNOUNCE. SOURCES POOL is the source registry with SIDs, previews, and file/image references when eligible. ANNOUNCE is the attention board: budget, temporal ground truth, open plans, workspace state, prune notices, feedback notices, and other must-see signals.

This is memory too, just not long-form historical memory. It is the part React is supposed to find first, because the runtime keeps it in one fixed place at the tail.

3. Logical paths are the memory routing layer

React keeps many memory realms coherent through logical paths. A path is both an identifier and a recovery handle. When the agent sees one in a tool result, on the timeline, or inside replacement text, it knows how to reopen the hidden or remote content later.

4. Notes and plans are working memory, not decoration

React does not only remember through long durable blocks. It also keeps a rolling working-memory layer in notes and plan state. When the agent emits a tool call with human-readable notes, the runtime saves that as a react.notes block on the timeline before the tool executes. That makes intent, rationale, and progress traceable later as memory, not just as ephemeral reasoning.

Plans are memory too. The plan tool writes react.plan snapshots, the runtime exposes the current plan again via ar:plan.latest:<plan_id>, and short human-readable react.plan.ack blocks record completed, failed, or in-progress steps as the turn moves forward. That gives React an auditable progress trail instead of a vague internal checklist. These working-memory artifacts are also directly reopenable, for example as ar:turn_123.react.notes.tc_abc or ar:turn_123.react.plan.ack.2.

5. Turn log and indexed storage hold deeper layers

The turn log is the per-turn reconstruction substrate. It stores the ordered blocks emitted during one turn along with light metadata. Fetch APIs, snippet recovery for react.memsearch, and other reconstruction flows rely on it.

Underneath that, the conversation store keeps full payload bodies while PostgreSQL index rows keep compact summaries and, for some artifact kinds, embeddings. That gives the system both full durable bodies and fast searchable records.

6. Workspace is project memory

Workspace is not just scratch disk. It is the memory surface for project continuity. React distinguishes durable workspace state under files/... from non-workspace artifacts under outputs/.... It can preserve project history in either custom or git mode while still keeping historical activation explicit.

That is why workspace memory is not just “what exists locally right now”. It spans current editable state, historical versions, hosted binary artifacts, and logical refs that can reopen the relevant slice when needed.

7. Summaries, hide replacements, and feedback are transformed memory

Some of the most important memory is derived rather than raw. When compaction runs, the runtime inserts a durable conv.range.summary block with path su:<turn_id>.conv.range.summary. That summary becomes the new compact representation of the older visible range, and on later loads the persisted timeline starts from the latest summary boundary onward.

Replacement text from TTL pruning or react.hide is another transformed memory form. It is intentionally short, but it preserves the meaning of what was removed and, crucially, the recovery path back to the underlying content. Feedback also belongs here: it persists as reaction artifacts, can land on the timeline, and can surface again as a live signal in ANNOUNCE.

In other words, React does not only store memories. It continuously converts memories into lighter forms while preserving how to reopen them. That is why summaries, plan aliases, note tags, and replacement text are not secondary implementation details. They are part of the memory architecture itself.

8. Retrieval is a routing problem across surfaces

React does not reopen memory through one generic “RAG step”. It uses different routes depending on what kind of memory it wants:

• react.read when the exact logical path is known
• react.memsearch when the topic is known but not the exact turn or path
• react.search_files for the current local filesystem surface
• react.pull to materialize historical workspace and artifact slices locally
• generated code and exec when local materialized memory needs richer inspection

9. The point is availability, not permanent visibility

React’s memory model is built on one core principle: if something is not visible, that does not mean it is gone. The system keeps information available in different states: visible, always-on-top, hidden with replacement text, summarized by compaction, persisted in storage, searchable in the index, or materializable back into workspace.