¿Qué es Chain of Recall? Cómo los IDs estables dan memoria a los agentes de IA

Chain of Recall es una forma de dotar de memoria a un agente de IA de larga ejecución sin saturar su ventana de contexto. Cada Trigger, Thread y Worker recibe un ID estable. El contexto solo conserva los IDs, resúmenes breves y mensajes cercanos, y el agente recorre los enlaces entre identificadores para recuperar hechos anteriores en unos pocos saltos.

Prueba Apidog hoy

El término proviene del ensayo de diseño de DeepSeek Harness “Exploring Super-agent Design”, publicado el 01-11-2026. Una advertencia antes de continuar: el ensayo describe una arquitectura, no una funcionalidad lanzada al mercado. Parte de ella reside en un plugin prototipo, dsh-superagent-prototype, que los autores definen como «no es un producto oficial de DeepSeek». No existe ningún interruptor para activar Chain of Recall: es un patrón que debes construir.

El problema de la ventana de contexto en un agente de larga ejecución

Un agente de larga ejecución alcanza su límite de contexto porque el flujo de trabajo nunca se detiene. Un superagente que monitoriza el chat, GitHub y CI procesa cientos de eventos al día, y la ventana que albergó el trabajo de ayer no puede contener también el de hoy.

Las soluciones habituales conllevan un coste:

• Conservar todo. La ventana se llena y el coste se dispara con cada turno.
• Resumir turnos antiguos. Un resumen suele descartar el error exacto o el número de PR que necesitarás más adelante.
• Recuperar por similitud. Funciona hasta que el dato que buscas no se parece a tu consulta.

La guía de Anthropic sobre ingeniería de contexto para agentes de IA plantea el contexto como un recurso finito que se debe curar. Chain of Recall es una forma concreta de llevar a cabo esa curación, y nuestra guía explicativa sobre cómo funciona la memoria en los agentes de IA analiza un abanico más amplio de opciones.

Inline frente a spill: el contexto como una memoria caché

El ensayo aborda la ventana de contexto como una memoria caché con dos acciones:

• Inline para lo que el agente probablemente necesite de inmediato: identificadores, resúmenes breves y mensajes cercanos.
• Spill para todo lo demás: truncarlo y dejar un puntero que el agente pueda consultar más tarde.

Un elemento derivado a spill no se elimina; únicamente su puntero permanece en el prompt.

Así se vería el fallo de una integración continua (CI) que llega al Router. Esta estructura es meramente ilustrativa, no es código de DeepSeek:

{
  "trigger_id": "trg_8f21",
  "source": "github.check_run",
  "thread_id": "thr_pr_412",
  "summary": "CI failed on PR #412: 3 of 118 tests red in payments/",
  "neighbours": ["trg_8f1c: review comment asking for retry logic"],
  "spilled": {
    "full_log": "GET /triggers/trg_8f21/payload (41 KB, truncated)"
  }
}

Si el resumen de una sola línea es suficiente, el agente nunca asume el coste del registro de 41 KB. Si no lo es, recupera el log mediante su ID.

Identificadores estables y el grafo de referencias

Chain of Recall funciona porque los ID nunca cambian. En el diseño planteado por el ensayo, tres tipos de objetos los incorporan:

Un Trigger pertenece a un Thread, un Thread es propiedad de uno o más Workers, y el informe de un Worker cita los Triggers sobre los que actuó. Estos vínculos forman un grafo de referencias, y dicho grafo constituye la memoria del agente.

La recuperación de información se lleva a cabo siguiendo los enlaces salto a salto, en lugar de cargar todo el historial o buscar coincidencias de texto. La guía complementaria sobre cómo construir un superagente explica qué papel desempeñan los Triggers, Threads y Workers en el diseño completo de Router y Worker.

Ejemplo práctico de recuperación multisalto

Supongamos que un compañero le pregunta al Router un viernes: «¿Por qué añadimos la lógica de reintento al cliente de pagos?». La conversación original tuvo lugar el martes y se envió a spill hace mucho tiempo. Así se recorre la cadena:

1. Salto 1: localizar el Thread. El contexto del Router aún conserva una entrada de índice de una línea: thr_pr_412: payments retry PR, merged Wed. Ejecuta un GET /threads/thr_pr_412.
2. Salto 2: identificar el Worker. El registro del Thread incluye owner_workers: ["wkr_77a0"]. El Router realiza un GET /workers/wkr_77a0 y lee su informe final.
3. Salto 3: descubrir la causa. El informe cita trg_8f21, el fallo de CI. El Router obtiene la carga útil de ese Trigger y lee los errores de tiempo de espera (timeout) en el log.
4. Respuesta. «La CI en el PR #412 falló el martes por 3 tiempos de espera en los pagos. El Worker wkr_77a0 añadió reintentos con retroceso exponencial (backoff) y el PR se fusionó el miércoles».

Tres peticiones pequeñas y precisas. No se dedujo nada al azar ni hubo información ocupando espacio en el prompt durante tres días.

Chain of Recall frente a la memoria vectorial y los resúmenes

Chain of Recall no reemplaza a otras técnicas de memoria; responde a una pregunta diferente. La recuperación vectorial, popularizada por el artículo sobre generación aumentada por recuperación, plantea «¿qué se parece a esto?». Chain of Recall plantea «¿qué está vinculado a esto?».

En la práctica, lo habitual es combinarlos: un índice vectorial identifica el ID del Thread inicial y, a partir de ahí, Chain of Recall avanza hasta los datos exactos. La jerarquía de memoria al estilo de un sistema operativo propuesta en el artículo de MemGPT es un concepto muy cercano. Si prefieres comenzar con una solución lista para usar, consulta nuestra guía sobre cómo añadir memoria persistente a agentes de IA con MCP.

Existen dos limitaciones. El ensayo sitúa la memoria a largo plazo entre los problemas aún abiertos y no afirma que Chain of Recall lo resuelva. Además, en su experimento, eliminar la transferencia directa de Threads (Thread pass-through) incrementó los tokens de lectura de caché de 23,2 M a 31,8 M por ejecución (alrededor de un 37 % más): se trata del coste asociado a una funcionalidad ausente, no de un ahorro atribuible a Chain of Recall.

Qué deben garantizar las API subyacentes

Cada salto en este recorrido corresponde a una llamada a la API. Si una llamada devuelve un registro diferente, o ninguno, la cadena se rompe y el agente se detiene o responde basándose en suposiciones. Por ello, las API que respaldan Chain of Recall deben cumplir cuatro contratos esenciales:

1. Los identificadores nunca cambian. Un ID devuelto hoy debe resolver el mismo objeto el mes que viene. Nada de reutilizarlos tras eliminarlos ni de renumerarlos tras una migración.
2. La consulta por ID es ligera y exacta. GET /threads/{id} devuelve ese único registro. No realiza búsquedas ni devuelve la «coincidencia más cercana».
3. Los identificadores desconocidos fallan de forma explícita. Un ID inexistente devuelve 404 Not Found, según lo define la norma RFC 9110, con un cuerpo de error claro. Un código 200 con un objeto vacío induciría al agente a creer que existe un recuerdo cuando no es así.
4. Los cursores paginan sin omisiones. GET /threads/{id}/events?cursor= recorre un Thread extenso en orden. Cada evento aparece exactamente una vez, no se salta ninguno y el cursor sigue siendo válido a medida que llegan nuevos eventos.

Estos contratos suelen romperse de forma silenciosa durante las refactorizaciones, por lo que deben formar parte de las pruebas automatizadas. Las respuestas de las herramientas también deben mantenerse compactas, un aspecto que abordamos en profundidad en nuestra guía sobre las respuestas de las herramientas del agente y la ventana de contexto.

Permite que tu agente de programación pruebe las API de recuperación con Apidog CLI

Chain of Recall es tan confiable como lo sean sus endpoints de consulta por ID, y un agente de programación puede escribir y volver a ejecutar esas validaciones por ti. Apidog CLI proporciona al agente comandos para definir los endpoints, crear casos de prueba y ejecutarlos directamente desde el terminal.

Configúralo una sola vez:

npm install -g apidog-cli@latest
apidog auth login --with-token <YOUR_TOKEN>
npx -y skills add https://apidog.com   # pick your agent when prompted

A continuación, proporciona a Claude Code, Codex o cualquier agente que utilices el siguiente [REDACTED PROMPT]
In Apidog project , define three endpoints for our agent memory
service: GET /threads/{id}, GET /threads/{id}/events?cursor=, and
GET /workers/{id}. Then create test cases that check:

1. A thread_id returned by GET /threads/{id} resolves to the same record on a second call, and each owner worker ID resolves via GET /workers/{id}.
2. An unknown thread ID and an unknown worker ID both return 404.
3. Paging GET /threads/{id}/events with the cursor returns every event once, in order, with no gaps. Run them against the staging environment and summarize any failures.

El agente lee el esquema de cada payload, valida su JSON antes de escribir nada y, posteriormente, genera y ejecuta las pruebas:

bash
apidog cli-schema get endpoint-create
apidog cli-schema validate endpoint-create --file thread-get.json
apidog endpoint create --project --file thread-get.json

apidog cli-schema get test-case-create
apidog cli-schema validate test-case-create --file id-resolves.json
apidog test-case create --project --file id-resolves.json

apidog run --test-case --project -e -r cli,json

El generador de informes `cli` muestra las aserciones superadas y fallidas en el terminal, y el reporte `json` proporciona al agente un archivo interpretable para identificar con precisión qué salto falló. Si un ID deja de resolverse tras una migración, lo verás reflejado en el informe antes de que el agente comience a responder basándose en una cadena rota. Para ejecutar estas mismas comprobaciones en cada merge, cambia el reporter a `-r junit`; nuestra guía sobre [Apidog CLI en Claude Code](https://apidog.com/es/blog/apidog-cli-in-claude-code?utm_source=dev.to&utm_medium=wanda&utm_content=n8n-post-automation) muestra el ciclo completo del agente.

## Dónde encaja Chain of Recall

Utiliza Chain of Recall cuando la memoria de tu agente consista en un historial de eventos discretos y enlazables: PR, tickets, ejecuciones de CI, hilos de soporte o despliegues. Estos elementos ya disponen de identificadores naturales, y las preguntas que los usuarios suelen formular sobre ellos («¿por qué hicimos esto?», «¿qué ocurrió después de aquello?») son cuestiones centradas en las conexiones entre dichos eventos.

Recurre a la recuperación vectorial para documentos no estructurados y preguntas difusas, y emplea resúmenes para sesiones breves en las que perder cierto nivel de detalle no suponga un inconveniente.

Chain of Recall surge de un ensayo y un prototipo: es una idea clara y contrastable, no un producto empaquetado. Para conocer la herramienta detrás de este ensayo, echa un vistazo a [qué es DeepSeek Harness](https://apidog.com/es/blog/what-is-deepseek-harness?utm_source=dev.to&utm_medium=wanda&utm_content=n8n-post-automation).

## Preguntas frecuentes

**¿Es Chain of Recall una función de DeepSeek que pueda activar?**
No. Es un término extraído del ensayo sobre superagentes de DeepSeek Harness, y parte de su implementación reside en un plugin prototipo que los propios autores señalan que no es un producto oficial de DeepSeek. El patrón debe implementarlo uno mismo.

**¿Cuál es la diferencia entre inline y spill?**
Inline mantiene los identificadores, los resúmenes breves y los mensajes cercanos dentro del prompt. Spill trunca el resto y deja un puntero que el agente puede consultar por ID cuando lo necesite.

**¿Sustituye Chain of Recall a RAG?**
No. RAG localiza contenido similar, mientras que Chain of Recall sigue enlaces exactos a través de identificadores. Muchos agentes combinan ambos enfoques.

**¿Redujo Chain of Recall el consumo de tokens en un 37 %?**
No. La cifra del 37 % corresponde al Thread pass-through: en el experimento del ensayo, su eliminación provocó que los tokens de lectura de caché aumentaran de 23,2 M a 31,8 M por ejecución. El ensayo no atribuye un ahorro de tokens al propio Chain of Recall.

**¿Qué debe devolver una API de consulta por ID ante un identificador desconocido?**
Un error `404 Not Found` acompañado de un cuerpo explicativo claro. Devolver un `200` con un objeto vacío hace que el agente asuma que el registro existe, rompiendo silenciosamente la cadena de recuperación.

**¿Cómo puedo verificar que las API de memoria de mi agente permanezcan estables?**
Diseña casos de prueba que verifiquen que un ID obtenido en una llamada se resuelve en la siguiente, que los identificadores desconocidos devuelven un 404 y que los cursores paginan sin omisiones. Un agente de programación puede generar y ejecutar estas pruebas con Apidog CLI en cada merge.