Cómo diseñar handoffs entre agentes que puedan reconstruirse sin guardar razonamiento privado

Define un sobre de transferencia mínimo. Cada handoff debería transportar un conjunto estable de campos: runKey, tarea, objetivo, estado actual, artefactos relevantes, restricciones, criterio de aceptación y próxima acción esperada. Esa estructura evita que un agente receptor dependa de una conversación larga para descubrir qué debe hacer. No necesitas guardar razonamiento privado paso a paso; necesitas conservar decisiones y evidencia operativa. El contrato debe permitir que otra ejecución comprenda qué quedó resuelto, qué sigue abierto y qué recursos externos necesita volver a comprobar antes de continuar.

Separa hechos, decisiones y propuestas. Un handoff confuso mezcla datos observados con interpretaciones y recomendaciones. Etiqueta cada elemento. Por ejemplo: “archivo X tiene SHA Y” es un hecho verificable; “usar la versión B” es una decisión; “quizá conviene revisar C” es una propuesta. Esta distinción ayuda al agente receptor a saber qué puede reutilizar y qué debe validar. También mejora la auditoría humana: cuando una ejecución falla, el operador puede identificar si el problema nació de una observación incorrecta, una decisión equivocada o una acción que nunca llegó a ejecutarse.

Referencia artefactos por identidad y versión. No pases solo nombres como “reporte final” o “último JSON”. Incluye el identificador estable del recurso, versión, tamaño o hash cuando sea relevante. Si el archivo puede cambiar externamente, marca la dependencia como revalidable. Al recibir el handoff, el siguiente agente debe leer nuevamente ese recurso antes de realizar una acción irreversible. Este patrón evita trabajar sobre una fotografía antigua del mundo. La continuidad útil no consiste en confiar en el estado anterior, sino en saber exactamente qué parte del estado anterior sigue siendo válida.

Incluye una condición explícita de aceptación. El agente receptor necesita saber cuándo su parte termina. Un criterio como “archivo actualizado” es demasiado vago; uno como “mismo FileId, feedDate correcto, 15 items y SHA idéntico al canónico” puede comprobarse. Los criterios reducen discusiones entre agentes y hacen posible que un orquestador detecte avance sin interpretar prosa libre. También permiten reintentos idempotentes: si la condición ya se cumple, el nuevo agente puede cerrar la fase sin repetir la escritura. Un buen handoff describe tanto el trabajo como la evidencia que demostrará su cierre.

Registra el resultado del handoff, no una narración infinita. Guarda quién entregó, quién recibió, hora, estado de entrada, acción tomada y resultado observado. Si el receptor rechaza la transferencia porque falta información, registra qué campo faltó. Esta telemetría permite analizar dónde se rompen los flujos: agentes que entregan demasiado pronto, artefactos que llegan sin versión o objetivos que cambian entre fases. El log se vuelve una secuencia de estados verificables, no un archivo de razonamiento. Eso protege claridad operativa y reduce datos innecesarios.

Diseña una ruta de devolución. Un handoff no siempre debe avanzar. Si el receptor descubre un conflicto, necesita una forma normalizada de devolver la tarea con estado bloqueado, evidencia y siguiente acción sugerida. Evita que el sistema improvise un chat lateral que el orquestador no pueda entender. Define categorías como falta de permiso, versión cambiante, validación fallida o ambigüedad de objetivo. Cada categoría puede tener una política diferente. Esta devolución estructurada permite que la coordinación se recupere sin reiniciar toda la ejecución ni ocultar que una fase necesita intervención.

Prueba el contrato con interrupciones reales. Simula que un agente desaparece después de entregar, que un archivo cambia antes de la siguiente fase y que una transferencia llega duplicada. Comprueba que el receptor puede continuar o detenerse con evidencia suficiente. Mide cuántas veces necesita consultar información fuera del sobre. Para Goatify, este patrón puede convertirse en infraestructura común de habilidades: agentes diferentes pueden colaborar sin conocer su razonamiento interno, porque comparten un lenguaje operacional de objetivos, artefactos, estados, validaciones y responsabilidades.