Agent Handoffs
Agent Handoffs describe un patrón de transferencia de responsabilidad operativa o control desde una ejecución agente hacia otra. La transferencia puede incluir objetivo, contexto, estado, restricciones, evidencia y trabajo pendiente para que el receptor continúe un tramo de la tarea. No queda definida por un producto, una llamada de API o un protocolo específico.
La pregunta central es quién debe actuar después y bajo qué condiciones. Enviar información no demuestra que esa responsabilidad se transfirió. Tampoco el handoff desplaza automáticamente la responsabilidad humana u organizacional por requisitos, aceptación y efectos. Su alcance operativo debe interpretarse dentro del encargo y del runtime concreto.
Transferir control y transferir información
Context handoff es transferencia de información pertinente. Agent handoff mueve responsabilidad o control de la ejecución. El segundo suele necesitar el primero, pero la información puede compartirse sin cambiar quién conduce el trabajo. Un resumen enviado a un revisor puede ser una contribución informativa, no una transferencia de toda la tarea.
Context Engineering for Software Development estudia selección y transferencia de contexto en desarrollo. Aporta criterios para que el receptor tenga información útil sin copiar todo el historial. No determina por sí solo cuándo deja de actuar el origen ni quién debe completar el próximo paso.
Esta distinción permite evaluar un handoff por sus efectos reales. Una interfaz puede anunciar “transferido” y solo haber preparado un mensaje. Un mensaje completo puede no haber llegado al receptor. El sistema necesita representar qué ocurrió suficientemente bien para no confundir intención de transferir con continuación efectiva.
Handoff y delegación
En Subagents and Delegation, un llamador asigna trabajo acotado y conserva una responsabilidad más amplia para integrar el resultado. En un handoff, el control o la responsabilidad de continuar pasa a otra ejecución. Las implementaciones pueden combinar ambas relaciones y permitir retornos o transferencias temporales.
No se exige que todo handoff sea definitivo ni que todo delegado tenga un lifecycle idéntico. Interesa reconocer qué parte del trabajo cambió de dueño operativo. Un subagente que explora y devuelve evidencia no implica necesariamente un handoff; una transferencia entre pares no crea necesariamente un subordinado.
El mismo modelo puede participar en ambas ejecuciones con distintos contextos o recursos. La identidad comercial del modelo no define la relación. Tampoco cambiar a otro modelo demuestra que se haya transferido el control si el primer agente sigue decidiendo todos los pasos.
Qué necesita el receptor
El receptor puede necesitar intención vigente, alcance autorizado, revisión de partida, decisiones tomadas y preguntas abiertas. También resultados relevantes y límites de lo que se comprobó. La selección depende de la tarea: investigar un fallo exige evidencia distinta de preparar una entrega o revisar un contrato.
Un handoff que dice solo “continuá donde quedé” puede omitir que una herramienta falló o que ciertos cambios no estaban autorizados. Uno que copia todo el historial puede ocultar la decisión importante entre mensajes repetitivos. La transferencia útil permite localizar las fuentes y distinguir hechos, hipótesis y propuestas.
Planning puede aportar próximos pasos, pero el plan no describe necesariamente el estado actual. Development Context and Execution Records conserva acciones y resultados realizados. Ambos ayudan a la continuidad sin que ninguno, por sí solo, demuestre que el receptor ya asumió responsabilidad.
Estado compartido y revisión de partida
El origen y el destino pueden observar recursos distintos o versiones diferentes. Un resultado de pruebas sobre una revisión anterior no describe automáticamente el workspace que recibe el siguiente agente. Si hay cambios locales, importa conocer cuáles pertenecen al encargo y cuáles son ajenos.
La continuidad no debería basarse en hacer que el entorno coincida con una narración antigua descartando trabajo existente. Conviene contrastar estado real y evidencia antes de modificar. Workspace Isolation for Coding Agents puede ayudar a preservar copias, pero no transfiere por sí sola decisiones ni establece quién continúa.
Los recursos externos también pueden haber cambiado. Una publicación marcada como pendiente quizá ya ocurrió y perdió su confirmación. El receptor necesita reconocer esa incertidumbre antes de repetir efectos. El handoff transmite lo que se sabe y lo que falta comprobar, no una garantía de que el mundo permanece igual.
Autoridad y recursos
Transferir contexto no crea permisos. Agent Permissions and Approval Boundaries delimita qué puede hacer la identidad que recibe el trabajo y cuándo necesita otra autorización. El receptor puede tener menos herramientas, otro entorno o restricciones distintas de las del origen.
Una nota que dice “publicar después” no constituye necesariamente autoridad vigente para desplegar. También puede existir autorización previa suficiente que no necesita solicitarse otra vez. La interpretación debe seguir el encargo y los controles aplicables, sin tratar el handoff como una concesión universal de acceso ni como motivo para bloquear cada acción rutinaria.
Agent Execution Environment ubica recursos e identidades reales. Si el siguiente agente no puede ejecutar una comprobación necesaria, corresponde informar o resolver esa condición dentro del alcance permitido. La transferencia no elimina las limitaciones técnicas del destino.
Handoff y A2A
Agent2Agent Protocol permite interoperabilidad entre sistemas agentes mediante sus contratos de comunicación. Puede apoyar un handoff, una consulta o trabajo delegado. No es la definición del concepto de transferencia de responsabilidad, y utilizar el protocolo no demuestra que se haya producido un handoff operativo.
Un runtime puede transferir control entre ejecuciones locales sin A2A. También puede comunicarse por A2A con un sistema que devuelve un dato sin asumir la continuación de la tarea. La semántica de la interacción necesita interpretarse en la arquitectura y el encargo concreto, no deducirse del transporte.
MCP y ACP conservan sus propios propósitos de integración. No hace falta adoptar todos los protocolos para transferir una tarea. Tampoco un objeto Session o Task de un protocolo establece por sí solo la definición general de sesión, responsabilidad o estado del agente.
Aceptación y continuación
Un sistema necesita suficiente claridad sobre si el receptor aceptó o empezó el trabajo y qué ocurre mientras tanto. No se prescribe un protocolo universal de acknowledgements. Puede haber una transferencia síncrona sencilla o un recorrido asíncrono con estados intermedios que importan para la continuidad.
Si el origen asume que el destino continuó y el destino nunca recibió el encargo, la tarea queda sin dueño. Si ambos siguen actuando sobre el mismo recurso, pueden duplicar cambios o efectos. La recuperación comienza por establecer el estado real de la transferencia y quién debe realizar la siguiente acción.
La terminación del origen también tiene significado concreto. Puede haber completado su parte del trabajo y dejar una entrega pendiente en otra ejecución. Un reporte global debería reflejar esa frontera en lugar de afirmar que toda la tarea terminó cuando solo cambió quién la conduce.
Si el receptor rechaza el encargo o carece de una condición necesaria, ese resultado necesita un dueño para el siguiente paso. Devolver información al origen no resuelve automáticamente la responsabilidad. La recuperación debe aclarar si se reasigna, se limita el trabajo o se detiene con una explicación verificable de lo que falta.
Evidencia de la transferencia
Agent Tracing puede relacionar solicitud de handoff, receptor, estado y continuación. Esos eventos ayudan a reconstruir dónde quedó el trabajo. No requieren exponer razonamiento privado ni conservar todas las conversaciones de ambos participantes para ser útiles.
La evidencia también puede registrar restricciones que siguen vigentes y resultados que no deben repetirse. Un resumen no debería convertir comprobaciones previstas en ejecutadas. Si faltan eventos, la ausencia de un registro no demuestra automáticamente que nada ocurrió; puede haber cobertura parcial que necesita contrastarse con otras fuentes.
Agent Checkpoints and Recovery preserva estado restorable, una responsabilidad diferente. Un checkpoint puede facilitar continuidad tras una interrupción sin transferir control a otro agente. Un handoff puede ser efectivo sin que exista un mecanismo de restauración del runtime.
Ejemplo: de investigación a preparación de release
Un agente investiga una falla de CI y obtiene evidencia sobre una incompatibilidad de rutas. Otra ejecución continuará preparando la corrección y su entrega. El handoff útil identifica el SHA que falló, los logs pertinentes, la hipótesis confirmada o candidata y las acciones que todavía no se realizaron.
Si el receptor prepara una release, necesita además conocer qué publicación está autorizada y qué controles deben pasar. La responsabilidad de continuar ese tramo no le permite ampliar permisos por inferencia. Puede ejecutar dentro de la autorización existente o detener la acción concreta que requiere una decisión adicional.
El origen no debe presentar una corrección preparada como desplegada. El receptor tampoco debe dar por ejecutadas pruebas que el registro solo recomendaba. La transferencia conserva una frontera verificable entre contribución anterior, siguiente trabajo y resultado final.
Costo y selección de una frontera
Un handoff introduce transferencia de contexto y posible pérdida de conocimiento tácito. Puede ayudar a pasar de una especialidad a otra o a continuar una tarea prolongada, pero también obliga a reconstruir supuestos. No toda pausa o cambio de foco necesita otra ejecución agente.
Una frontera útil deja claro qué parte está resuelta y qué resultado debe producir el receptor. Si hay dependencias estrechas que requieren conversación constante, separar ejecuciones puede aumentar costo sin mejorar claridad. Multi-Agent Coordination trata esas dependencias y conflictos más amplios.
La elección no se guía por una escala donde más agentes significa mejor sistema. Puede ser suficiente mantener la tarea en una sola ejecución y actualizar su contexto. También puede ser apropiado transferir un tramo cuando su responsabilidad y evidencia son claramente delimitables.
Límites del patrón
Agent Handoffs organiza continuidad de responsabilidad o control. No equivale a copiar contexto, crear un subagente, restaurar un checkpoint ni usar A2A. Tampoco garantiza que el receptor tenga información suficiente o produzca un resultado correcto.
El criterio de éxito es que la continuación tenga un dueño operativo reconocible, contexto pertinente y límites vigentes. Esa claridad permite colaborar entre ejecuciones sin abandonar trabajo entre interfaces ni atribuir a un protocolo o un resumen una autoridad que no tienen.