Long-running AI agents hit a hard wall when context windows fill up, but a new design pattern called 'Chain of Recall' proposes a radical solution: stop storing history in the prompt and start storing pointers. Derived from the DeepSeek Harness essay 'Exploring Super-agent Design' published on November 1, 2026, this architecture assigns stable, immutable IDs to every Trigger, Thread, and Worker. Instead of saturating the context window with raw logs, the agent retains only brief summaries and identifiers, fetching full details only when necessary.

The Cache Architecture: Inline vs. Spill

The core mechanic treats the context window as a cache with two distinct actions: 'Inline' and 'Spill'. Inline elements are what the agent likely needs immediatelyβ€”IDs, short summaries, and nearby messages. Everything else gets 'Spilled', meaning the raw data is truncated and replaced with a pointer. For example, a CI failure trigger might keep a one-line summary in the prompt but store the 41 KB full log behind a GET /triggers/trg_8f21/payload endpoint. This ensures the agent never pays the token cost for data it doesn't actively need in the current turn.

Navigating the Reference Graph

Chain of Recall functions as a graph traversal rather than a semantic search. When an agent needs to recall a past event, it follows links between stable IDs. A typical retrieval involves three hops: locating the Thread (e.g., thr_pr_412), identifying the responsible Worker (wkr_77a0), and fetching the specific Trigger payload (trg_8f21). This method is deterministic and precise, contrasting sharply with vector-based RAG, which relies on similarity scores and can hallucinate connections between unrelated events if the embeddings are close but the context is wrong.

Implementation Risks and API Contracts

This pattern is not a plug-and-play feature; it is an architectural discipline that requires rigorous API design. The source material warns that there is no 'switch' to turn this on. For the chain to hold, underlying APIs must guarantee four strict contracts: IDs must never change or be reused, queries by ID must be exact and lightweight, unknown IDs must return explicit 404 errors (not empty 200s), and pagination cursors must be lossless. If a migration renumbers IDs or an API returns a silent empty object, the agent's memory breaks, leading to hallucinations or dead ends.

Key Takeaways

  • Chain of Recall is a design pattern from DeepSeek's 'Super-agent Design' essay, not a released product.
  • It replaces context saturation with pointer-based retrieval using stable IDs for Triggers, Threads, and Workers.
  • It complements rather than replaces RAG; vector search finds 'similar' data, while Chain of Recall finds 'linked' data.
  • Success depends entirely on API stability; silent failures in ID resolution will break the agent's memory chain.

The Bottom Line

This is the most practical approach to agent memory I've seen in months. We've been drowning in vector search complexity for simple event logs; Chain of Recall reminds us that if you have an ID, you don't need an embedding. Build the API contracts first, then add the memory.