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 memory anchor 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, internal memory anchors, feedback blocks, system notices, and compaction summaries. A single prolonged turn can also contain more than one visible assistant completion when followups land while the turn is still open. 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. Selected internal memory anchors can remain visible as conversation anchors even when older regions get cold. So the visible context is a derived view over deeper memory, not the whole durable store itself.

The raw timeline itself stays append-only. Restored conversation order is reconstructed later from truthful event-start timestamps: ts for discrete blocks and ts_first for streamed aggregates. That distinction matters when a followup lands while an earlier assistant answer is already streaming. The followup can be appended to the durable log before the later synthesized completion block is written, while the restored view should still place the answer according to when it actually started becoming visible.

React writes those anchors through react.write(channel="internal"). By default they are internal file artifacts. If the agent sets scratchpad=true, a short inline react.note is also created. They are user-invisible conversation anchors for decisions, stable technical facts, achievements, preferences, and key artifacts worth reopening later. They are not automatically promoted into durable user memory.

2. Internal memory anchors are conversation anchors

Internal memory anchors are not free-form journaling and they are not the same thing as durable user memory. They are short protocol lines React leaves for itself with react.write(channel="internal") when something becomes worth carrying forward: a decision, a stable technical fact, a milestone, or a key artifact path that future turns should reopen first.

The important runtime property is that React treats selected anchors as anchors. They can survive pruning/compaction as authored notes or compact digests, and they can be indexed for react.memsearch(targets=["notes"]). That is how React can recover a few important cues without keeping the whole old transcript in the prompt.

3. 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.

4. 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. Busy-turn continuation attachments use the same idea with message-scoped paths, for example fi:turn_123.external.followup.attachments/mabc123/receipt.pdf.

5. 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 human-readable notes, the runtime saves them as react.notes blocks on the timeline at the moment that step becomes visible. Some of those notes are emitted around tool calls; others can be emitted around completion or exit without any tool call at all. 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.

6. Turn log and indexed storage hold deeper layers

The turn log is the per-turn reconstruction substrate. It stores the ordered append-only blocks emitted during one turn along with light metadata. Fetch APIs, snippet recovery for react.memsearch, and other reconstruction flows rely on it. When a conversation is restored, the runtime reconstructs the visible order from those timestamps and first-seen stream markers rather than from raw append position alone.

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.

visible exact path
  -> react.read([path])
  -> react.pull([fi_path]) if execution needs a local file

visible summary path (ws:/su:)
  -> react.read([summary_path])
  -> react.read(["ar:<turn_id>.react.turn.index"]) if refs are incomplete
  -> react.read([ar_or_tc_or_so_path, ...]) / react.pull([fi_path, ...])

topic only
  -> react.memsearch(query, targets=["summary", "notes", "user", "assistant", "attachment"])
  -> read returned refs or the returned turn_index_path

durable user fact/preference
  -> use [USER MEMORY HOTSET] if already in ANNOUNCE
  -> memory.search / memory.read when memory tooling is enabled

7. 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.

8. 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.

9. 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, including targets=["notes"] for indexed react.note blocks
• memory search/read tools for durable user memories when the memory subsystem is enabled
• ar:<turn_id>.react.turn.index when the turn is known but the exact refs are not
• react.search_files for the current local filesystem surface
• react.pull to materialize historical workspace and artifact slices locally as readonly reference material
• react.checkout to seed or overlay the active current-turn workspace from historical fi:...files... refs
• generated code and exec when local materialized memory needs richer inspection

10. 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.

React v3 keeps this same memory contract. Its added feature is safer multi-action scheduling in one decision response, not a different memory substrate: working summaries, turn indexes, react.memsearch, react.read, and artifact paths remain the recovery language.