Handoffs: pasar trabajo entre agentes sin perder el hilo

Mira lo que pasa de verdad cuando el trabajo se mueve entre agentes. Un primer agente parte una feature en tareas. Le pasas una tarea a un segundo agente para que la construya. Construye algo plausible, y reconstruye una decisión que el primer agente ya había tomado y descartado, porque esa decisión nunca viajó con la tarea. Ahora estás revisando código que resolvió la versión equivocada del problema, y la razón no es que ningún agente fuera malo. Es que el handoff cargó el qué y soltó el porqué.

Los handoffs son donde el trabajo multiagente se escapa. Cada vez que el trabajo cruza una frontera, entre dos agentes, entre dos sesiones del mismo agente, entre el run de anoche y el de esta mañana, hay una posibilidad de que el contexto no llegue al otro lado. Y lo que se pierde casi nunca es el código. El código está ahí en la rama. Lo que se pierde es todo lo que no es código: las decisiones ya tomadas, las restricciones que deben mantenerse, los caminos ya probados y descartados, la pregunta que sigue abierta. Ese es el hilo, y es lo que un buen handoff tiene que cargar.

Por qué un transcript no es un handoff

El handoff por defecto es “aquí está el chat, ponte al día”. No funciona, por la misma razón por la que darle a alguien la grabación de tres horas de una reunión no es un briefing. La información puede que esté técnicamente ahí, pero quien la recibe tiene que reconstruirla, y reconstruir es caro y con pérdidas.

Peor, un transcript es casi todo ruido. Contiene cada callejón sin salida que exploró el primer agente, cada llamada a herramienta, cada corrección, sin señal sobre qué partes siguen importando. Un agente en fresco leyéndolo no distingue la decisión que se quedó de la idea que se probó y se soltó. Así que o vuelve a explorar los callejones sin salida o, peor, trata un enfoque abandonado como el plan actual. Cuanto más largo el transcript, peor esto, lo que enlaza directo con gestionar la ventana de contexto: volcar una historia entera en una sesión fresca no transfiere entendimiento, transfiere ruido y se come el presupuesto que necesitabas para el trabajo de verdad.

Un handoff no es la historia en bruto. Es el estado destilado: qué es verdad ahora, qué debe seguir siendo verdad, y qué queda abierto.

Qué tiene que viajar

Un handoff limpio carga un paquete pequeño y deliberado. En mi experiencia operando agentes entre sesiones, es más o menos esto:

• El contrato. Qué construimos y qué cuenta como hecho, dicho como criterios que quien recibe pueda comprobar, no intuiciones que tenga que inferir. Es el mismo artefacto portable que defiendo en las especificaciones de software deberían ser portables: un contrato que viaja vale más que uno atrapado en la sesión que lo escribió.
• El estado actual. Dónde está el trabajo de verdad. Qué está hecho y verificado, qué en marcha, qué sin tocar. No “lee el diff y adivina”.
• Las decisiones ya tomadas, con motivos. Las elecciones que están cerradas y por qué, para que quien recibe no las reabra. Una decisión sin su motivo se vuelve a litigar al contacto.
• Los callejones sin salida. Qué se probó y se descartó, y por qué. Esta es la parte que los transcripts entierran y la que más tiempo ahorra, porque impide que el siguiente agente recorra el mismo camino equivocado con seguridad.
• La pregunta abierta. La única cosa que el handoff de verdad le pide al siguiente agente que resuelva. Si un handoff no nombra qué quiere, quien recibe adivina.

Fíjate en lo que no está en esa lista: la historia entera. El paquete es un resumen de estado, no una repetición de eventos. Esa es la diferencia entre un handoff que deja al siguiente agente continuar y un transcript que le hace empezar de cero.

Handoffs, recuperación y memoria son un solo problema

En cuanto ves el paquete, ves que tres cosas que podrías tratar por separado son la misma cosa.

Un handoff entre agentes pasa ese paquete de lado, de un agente a otro. Recuperar un run muerto lo pasa hacia delante en el tiempo, del run fallido de anoche al resume de esta mañana, que es justo por qué la recuperación es un flujo de primera clase y no heroísmo: un run que puedes resumir es un run que se hizo handoff limpio a su propio futuro. Y la memoria es el mismo paquete persistido, para que sobreviva cuando nadie lo está pasando activamente. En cada caso la pregunta es idéntica: ¿el estado que importa vive en algún sitio fuera de la sesión, en una forma sobre la que el siguiente lector pueda actuar? Cuando lo hace, los tres funcionan. Cuando no, los tres colapsan en leer un transcript que nadie quiere leer.

El relato de Anthropic sobre un sistema multiagente de investigación aterriza en un punto relacionado desde el lado de la orquestación: coordinar varios agentes es en gran parte un problema de qué se le dice a cada uno y cómo se combinan sus salidas, no de la capacidad bruta de ningún agente. El formato de handoff es esa coordinación hecha concreta.

Diseñar handoffs en los que puedas confiar

Puedes hacer los handoffs fiables hoy, sin herramientas especiales, tratando el paquete como un artefacto en vez de una intuición:

• Escribe el handoff, no apuntes al chat. Una nota corta y estructurada que cargue las cinco cosas de arriba gana a “sube y lee” siempre. Si escribirla se siente redundante, es porque tú eres quien todavía se acuerda. Quien recibe no.
• Mantén el contrato fuera de la sesión. Si los criterios de aceptación viven en un fichero o una tarea en vez de en el contexto de un agente, cada handoff los hereda gratis en vez de volver a derivarlos.
• Registra las decisiones según las tomas, no al final. Una decisión capturada con su motivo en el momento en que se toma sobrevive al handoff. Una reconstruida después está medio inventada.
• Nombra la pregunta abierta explícitamente. Termina cada handoff con la única cosa que el siguiente agente debe resolver. La ambigüedad aquí es donde se pierde el hilo.

Esto no es una disciplina nueva. Es lo mismo que hacen los buenos equipos en un cambio de turno y los buenos ingenieros en la descripción de un pull request. Los agentes solo hacen que el coste de saltárselo aparezca más rápido, porque correrán con seguridad con lo que sea que no les entregaste.

Dónde encaja PaellaDoc

Un handoff pierde el hilo cuando el estado que importa vive solo en un transcript, y uno limpio funciona cuando el contrato, las decisiones y la pregunta abierta viajan como un artefacto sobre el que el siguiente agente puede actuar. Ese es el mecanismo. Es también la misma maquinaria que necesitan la recuperación y la memoria, por lo que los trato juntos y no como tres features. PaellaDoc guarda el contrato, las decisiones y el estado del run como artefactos de primera clase que persisten fuera de cualquier sesión, así que pasar trabajo entre agentes, resumir un run muerto y recordar entre días son la misma operación en vez de tres actos separados de heroísmo. La persona que hace esa reconciliación a mano ahora mismo, sosteniendo el hilo a través de cada frontera, es el runtime.

FAQ

¿Qué debería incluir un handoff entre agentes?

Cinco cosas: el contrato (qué se construye y qué cuenta como hecho, como criterios comprobables), el estado actual (qué está hecho, en marcha o sin tocar), las decisiones ya tomadas con sus motivos, los callejones sin salida ya probados, y la única pregunta abierta que el siguiente agente debe resolver. Notablemente, no el transcript entero, que es casi todo ruido que quien recibe tiene que volver a filtrar.

¿Por qué no darle al siguiente agente el historial entero del chat?

Porque un transcript es una repetición de eventos, no un resumen de estado. Contiene cada callejón sin salida y corrección sin señal sobre qué sigue importando, así que el agente que recibe o vuelve a explorar caminos descartados o confunde un enfoque abandonado con el plan. Además quema presupuesto de contexto que necesitas para el trabajo real. Un handoff destilado transfiere entendimiento; un transcript en bruto transfiere ruido.

¿Cómo se relacionan los handoffs con la recuperación y la memoria?

Son el mismo problema en tres direcciones. Un handoff pasa el estado de lado entre agentes, la recuperación lo pasa hacia delante en el tiempo para resumir un run muerto, y la memoria lo persiste para que sobreviva cuando nadie lo está pasando. Los tres dependen de que el estado que importa viva fuera de la sesión en una forma sobre la que el siguiente lector pueda actuar.