Chain of Recall: stable IDs give long-running AI agents memory without context bloat

Long-running AI agents eventually hit the limit of their context window, and the usual fixes each give something up: keeping everything gets expensive, summarising old turns drops details, and similarity search fails when the answer does not resemble the question. A dev.to article explains an alternative called Chain of Recall, a design pattern that keeps only stable identifiers and short summaries in context and follows links between those IDs when older information is needed.

Where the pattern comes from

According to the dev.to write-up, the term comes from "Exploring Super-agent Design", a design article published by DeepSeek Harness on November 1, 2026. The piece is careful to frame this as architecture rather than a shipped feature: parts of the design exist only in a prototype plugin named dsh-superagent-prototype, which its authors say is not an official DeepSeek product. There is no toggle to flip — it is a pattern you implement yourself.

The context window as a cache

The design treats the context window like a cache with two operations. Inline keeps what the agent is likely to need immediately: IDs, one-line summaries and neighbouring messages. Spill moves everything else out of the prompt, condensing the content and leaving a pointer behind. Spilled items are not deleted; only a marker stays in the prompt.

The dev.to article illustrates this with a CI failure routed to an agent, noting that the example JSON is illustrative rather than DeepSeek's actual code. Context holds a trigger ID, a thread ID and a single line — CI failed on PR #412, with three of 118 tests red in the payments directory — while the 41 KB full log sits behind an endpoint reference. If the summary suffices, the agent never pays for the log; when it does not, the log is fetched by ID. The article also points to Anthropic's guidance on context engineering, which similarly treats context as a limited resource that must be managed deliberately.

Triggers, Threads and Workers

The scheme works because the IDs never change. Three object types carry them. A Trigger is a single incoming event, such as a chat message, webhook or CI callback (trg_8f21). A Thread is a related sequence of events around one pull request, chat topic or email chain (thr_pr_412). A Worker is an isolated agent session executing a single task (wkr_77a0). A Trigger belongs to a Thread, a Thread is handled by one or more Workers, and a Worker's report references the Triggers it acted on. Those links form a reference graph, and the article argues that this graph effectively is the agent's memory: recall means walking it a few hops rather than loading full history or searching by similarity.

A multi-hop example

Suppose a teammate asks on Friday why retry logic was added to the payments client, and the relevant discussion happened on Tuesday and has since spilled out of context. The Router still holds a one-line index entry — the payments retry thread, merged on Wednesday — so it fetches the thread by ID, reads the owning worker (wkr_77a0), pulls that worker's report, follows the report's reference to the CI-failure trigger, and reads the timeout errors in its payload. Three small, targeted fetches produce an exact answer, with nothing guessed and no days of stale data sitting in the prompt.

Compared with RAG and summaries

The dev.to article positions Chain of Recall as answering "what is connected to this?", while vector retrieval in the RAG style answers "what resembles this?". Following IDs yields exact records, which suits event histories such as pull requests, tickets and CI runs, but the pattern cannot find data that has no links pointing to it. Rolling summaries are lossy by construction, and memory servers exposed via MCP add another service to run and secure. In practice the article expects these techniques combined: a vector index surfaces a starting Thread ID, then the chain walks to the precise facts. MemGPT-style memory hierarchies are described as a close relative.

Costs and caveats

Two limitations are flagged. The design article still lists long-term memory among its open problems, and Chain of Recall is not claimed to solve it alone. In the experiments described, removing a direct pass-through for Threads raised cache-read tokens per run from 23.2 million to 31.8 million, roughly a 37 percent increase — a cost caused by a missing shortcut, not a saving the pattern delivers. Reliability also rests on the backing APIs: every hop is an API call, and if a call returns a different record or none at all, the chain breaks and the agent either stalls or guesses.

Why it matters

As agents run for days across tickets, repositories and pipelines, context management becomes the central engineering constraint. Chain of Recall offers a concrete scheme for it: stable identifiers plus a small reference graph turn the context window into a cache of pointers rather than an archive of everything. For teams building long-lived agents, the useful takeaway is a design discipline more than a product — assign durable IDs early, keep retrieval endpoints stable, and decide what spills before the window fills up.