Pruebas de traspasos entre agentes como contratos

Una demo con varios agentes puede parecer excelente mientras los traspasos entre ellos fallan sin que nadie lo advierta. El agente de investigación encuentra las pruebas adecuadas. El agente de entrega redacta una recomendación convincente. En algún punto entre ambos, desaparece una restricción, un artefacto antiguo pasa por actual o dos agentes deciden que les corresponde ejecutar la siguiente acción.

Yo trataría ese punto de intercambio como un contrato de API. Hay que probar qué lo atraviesa, quién puede aceptarlo y qué ocurre cuando falla la aceptación. Evaluar la respuesta de cada agente de forma aislada deja convenientemente fuera de la evaluación los modos de fallo más interesantes.

La investigación de Anthropic de agosto de 2026 ofrece una advertencia útil: la delegación acotada, similar al uso de una herramienta, y la coordinación abierta entre pares son problemas distintos. Sus experimentos describen fallos de coordinación incluso entre agentes capaces. Eso justifica probar la interacción; no es una predicción de que todos los sistemas multiagente vayan a fallar.

Empieza por un traspaso que puedas explicar

Imagina un flujo de trabajo hipotético que va de la investigación a la entrega. Un agente de investigación recopila documentación de proveedores procedente de fuentes aprobadas. Un agente de entrega convierte esas pruebas en un documento de implementación para que lo revise una persona. Ninguno puede contactar con proveedores, modificar un registro de compras ni publicar el documento.

El trabajo del agente de investigación termina cuando el paquete de pruebas queda disponible de forma persistente. El del agente de entrega empieza cuando acepta exactamente ese paquete. Un coordinador se encarga de la transición y registra la aceptación. Hasta entonces, haber completado la investigación es un avance útil, pero no demuestra que la entrega haya comenzado.

A2A v1.0 proporciona el modelo de comunicación: una Agent Card anuncia las capacidades y los requisitos de interacción; los mensajes contienen los intercambios; las tareas permiten seguir el trabajo; y los artefactos contienen los resultados. Un contextId agrupa las interacciones relacionadas. Estas estructuras ayudan a los agentes a comunicarse. No definen tu esquema de pruebas ni deciden si un documento está listo para su revisión.

Fija la versión del protocolo y la interfaz compatible en tus pruebas de integración. Después, sitúa el contrato de negocio por encima de esa capa de transporte. Lo siguiente es un ejemplo a nivel de aplicación, no un mensaje del protocolo A2A:

{
  "contractVersion": "research-brief/1",
  "handoffId": "handoff-042",
  "workflowId": "supplier-review-17",
  "sourceTaskId": "research-task-8",
  "artifact": {
    "id": "evidence-12",
    "version": 3,
    "digest": "<resumen criptográfico verificado del contenido>"
  },
  "objective": "Redactar un documento de implementación para revisión humana",
  "constraints": [
    "Usar solo fuentes aprobadas",
    "No contactar con proveedores",
    "No publicar"
  ],
  "requiredOutput": "implementation-brief/1",
  "nextOwner": "delivery-agent",
  "deadline": "<marca de tiempo absoluta>"
}

Mantén el sobre del mensaje lo bastante pequeño como para validarlo. Guarda los registros de pruebas en el artefacto referenciado: URL de origen, momento de recuperación, afirmación relevante, limitaciones y cualquier clasificación de acceso necesaria. Explicita el objetivo y las restricciones en lugar de esperar que quien lo recibe los reconstruya a partir de una transcripción.

La aceptación requiere algo más que un JSON válido

La validación del esquema detecta que falta la versión de un artefacto. No detecta un paquete perfectamente formado que responde a la pregunta equivocada.

Para este flujo de trabajo, yo exigiría que el receptor comprobara que el artefacto existe, que su resumen criptográfico coincide, que la versión del contrato es compatible y que sus pruebas responden a la decisión solicitada sobre el proveedor. Un array de pruebas vacío debería generar un rechazo claro o una petición de aclaración. No debería convertirse en una invitación a improvisar.

Prueba también el descubrimiento de capacidades. Anuncia una capacidad que el receptor no pueda ejecutar, elimina un tipo de contenido obligatorio y cambia la versión de contrato admitida. Comprueba que el enrutamiento se detiene antes de empezar el trabajo, con suficiente información de diagnóstico para que el coordinador elija otra vía compatible. Recurrir silenciosamente a un agente genérico hace mucho más difícil detectar los fallos de compatibilidad.

Trata la procedencia como parte de la aceptación. En un caso de prueba, sustituye el artefacto de pruebas por uno anterior sin cambiar el texto que lo rodea. El receptor debería rechazar la discrepancia o solicitar explícitamente la revisión prevista. Esa misma prueba debería fallar si el receptor no puede acceder al artefacto. Una URL no demuestra que su contenido se pueda leer.

Mantén los límites de autorización durante el traspaso

La guía de A2A para entornos empresariales separa la autenticación del contenido de la conversación y deja la aplicación de la autorización en manos del servidor. La distinción importa: que un agente diga «el usuario lo ha aprobado» no constituye una credencial.

En este diseño, el coordinador vincula el traspaso con una identidad autenticada y con la operación permitida mediante un estado de aplicación de confianza. El servicio receptor comprueba esos permisos por sí mismo. No copies un token de portador con permisos amplios del sistema de origen en un prompt o un paquete de pruebas. Utiliza una credencial con el alcance adecuado o un mecanismo de delegación fuera del texto generado.

Crea un caso de prueba negativo con un resultado de investigación válido, pero sin permiso para acceder al registro del proveedor subyacente. Otro caso debe colocar el registro de un cliente distinto detrás de la referencia al artefacto. Ambos deben detenerse antes de la lectura o escritura protegida. Inspecciona los eventos de auditoría del backend y las versiones de los registros; una negativa educada en la respuesta generada no basta si la llamada a la herramienta ya se ha producido.

Conserva los identificadores de traza, las referencias a las tareas de origen y el linaje de los artefactos para que un operador pueda reconstruir el traspaso. Evita registrar credenciales o contenido de las fuentes que no sea necesario. La observabilidad debe explicar una decisión sin crear una segunda copia de los datos con menos protección.

Provoca fallos en la transición y examina sus efectos

Las pruebas más valiosas interrumpen el intervalo entre «enviado» y «aceptado». Utiliza un pequeño entorno de pruebas con un coordinador, un receptor controlable y una API simulada de registros de negocio que registre los efectos intentados. Empieza con casos deterministas; después, repite los mismos casos con el modelo y las herramientas reales.

• Pérdida de contexto: elimina «no publicar» de la entrada del receptor. La política de confianza debería seguir bloqueando la publicación, y la ausencia de la restricción obligatoria debería impedir la aceptación.
• Entrega duplicada: entrega el mismo traspaso dos veces, incluso después de reiniciar el coordinador. El resultado esperado es un único elemento de trabajo aceptado y un único documento, con ambas entregas visibles en el historial de auditoría.
• Pérdida del acuse de recibo: deja que el receptor acepte el paquete y descarta después su respuesta. El coordinador debería conciliar la aceptación registrada antes de enviar trabajo nuevo.
• Responsabilidad ambigua: deja que ambos agentes propongan el siguiente paso. Solo la asignación confirmada por el coordinador debería autorizarlo; ninguna de las propuestas debería desencadenar una acción por sí sola.
• Resultado obsoleto: entrega con retraso el resultado de un intento anterior después de que se haya aceptado un artefacto más reciente. Consérvalo para el diagnóstico sin permitir que sobrescriba la revisión aceptada.

A2A v1.0 permite que las implementaciones utilicen messageId para detectar duplicados; enviar un mensaje no garantiza de forma incondicional que se procese exactamente una vez. Para este flujo de trabajo, yo añadiría un registro persistente de traspasos en la aplicación, con una clave de aceptación única y una transición de responsabilidad protegida. Aplica una regla de unicidad equivalente en el punto donde se producen los efectos. Deduplicar un mensaje de chat sirve de poco si la API de negocio sigue creando dos registros.

Define explícitamente el comportamiento al agotar el tiempo de espera. Una fecha límite puede detener el trabajo nuevo sin demostrar que una acción remota haya fallado. Consulta el estado persistente del receptor y concilia los efectos observados. Si el resultado sigue siendo incierto, conserva el intento para investigarlo en lugar de dar permiso a un segundo agente para repetirlo.

El ciclo de vida de las tareas de A2A también importa aquí: las tareas en estado terminal no se reinician y los ajustes posteriores se convierten en tareas independientes. Mantén explícita la versión del artefacto aceptada por tu aplicación al realizar ese seguimiento. Una tarea nueva no debería borrar silenciosamente el historial del resultado anterior.

Mide el punto de intercambio, además de la respuesta

Registra los traspasos aceptados por cada intento elegible, los elementos de trabajo duplicados, los efectos no autorizados, las pruebas ausentes, el tiempo de espera hasta asignar un responsable y el esfuerzo humano de corrección. Para cada fallo inyectado, define la transición de estado esperada y los efectos permitidos antes de ejecutar la prueba. De lo contrario, un equipo puede acabar contando por accidente como éxito un fallo que parece haberse gestionado bien.

Separa las comprobaciones estructurales de las semánticas. El análisis del contrato, la existencia del artefacto y la prevención de duplicados deben tener comprobaciones deterministas. Determinar si las pruebas realmente respaldan el documento requiere una rúbrica específica del dominio y una revisión humana calibrada. Un modelo puede ayudar a evaluar esto último, pero no debería ser el único testigo de si se ha producido una llamada prohibida a una API.

El trabajo de Nieve en flujos agénticos se centra en integrar agentes personalizables con la infraestructura existente. En ese punto de intercambio, mi recomendación es sencilla: empieza con un traspaso explícito, un registro persistente de aceptación y unos pocos casos de prueba adversarios. Añade más agentes cuando el punto de intercambio existente sea observable y se pueda probar. Rara vez es otro agente lo que falta en una comprobación.

Ideas clave

• Define un contrato de traspaso a nivel de aplicación con un objetivo claro, restricciones, una versión del artefacto y el siguiente responsable.
• Valida las pruebas y su procedencia, además de la compatibilidad del esquema; una respuesta fluida no equivale a una aceptación.
• Aplica la autorización en servicios de confianza y comprueba los registros protegidos y los efectos reales de las herramientas.
• Inyecta duplicados, pérdidas de acuses de recibo, omisiones de restricciones y resultados obsoletos; resuelve la incertidumbre antes de reintentar.
• Mide los fallos de coordinación y el esfuerzo de corrección junto con la calidad de las respuestas individuales.