A2A: Agente a Agente, una guía de campo para constructores

Para principios de 2026, había dejado de contar cuántas revisiones de arquitectura empresarial comenzaban con el mismo diagrama. Un cuadro para el agente del proveedor de CRM. Un cuadro para el agente del proveedor de procesamiento de documentos. Un cuadro para el agente del equipo interno de ciencia de datos, el que construyeron sobre LangGraph y del que están muy orgullosos. Y luego un conjunto de flechas entre los cuadros que, cuando preguntas qué protocolo representan, resultan significar “un endpoint REST que alguien escribirá más tarde”.

Cada proveedor ahora envía un agente. Esa parte está hecha y no hay vuelta atrás. Lo que veo en el campo, principalmente en bancos y aseguradoras, es el problema de segundo orden: ninguno de estos agentes puede comunicarse entre sí. Cada par de cuadros necesita integraciones a medida, y cada pieza de integración es propiedad del equipo que perdió la negociación. Los traspasos son prompts ad hoc y payloads JSON ensamblados, sin versionar y sin auditar. Cuando un examinador pregunta “qué agente decidió esto, basándose en qué entrada”, nadie puede responder a partir de los registros. Eso no es un problema de IA. Es un problema de integración disfrazado de IA, y ya hemos resuelto problemas de integración antes. Los resolvemos con protocolos.

A2A (Agent2Agent) es el protocolo que ha surgido para esta capa. Coescribí una serie de dos partes al respecto para el blog de Camunda con Joyce Johnson, cubriendo el marco de decisión y una construcción completa de préstamos hipotecarios, y ahora he construido sistemas hipotecarios multiagente basándome en estas ideas dos veces: una como una demostración orquestada de Camunda, y otra como un proyecto de hackathon independiente de Gemini 3 con Agent Cards reales y contratos JSON-RPC. Esta guía es la destilación: qué especifica realmente A2A, dónde se sitúa en relación con MCP, AG-UI y AP2, los dos patrones de orquestación que utilizo, la costura de privacidad de datos que hace posible y el modelo de amenazas que nadie pone en la diapositiva de lanzamiento.

Los sistemas multiagente son un problema de integración antes que un problema de IA

Aquí está la afirmación que sigo defendiendo en salas llenas de personas que quieren hablar de modelos: la parte difícil de los sistemas multiagente en una empresa no es la inteligencia del agente. Es que diferentes equipos son propietarios de los agentes, los grandes modelos de lenguaje y las fuentes de datos, y esos equipos tienen diferentes ciclos de lanzamiento, diferentes posturas de seguridad y diferentes definiciones de “terminado”.

Sin un estándar, se obtienen N agentes y hasta N×(N-1) integraciones punto a punto, cada una con su propia forma de payload, semántica de reintento y comportamiento de falla. He visto esta película en la era SOA y de nuevo en la era de los microservicios. La trama nunca cambia. Las integraciones que eran “temporales” se vuelven críticas. El equipo que escribió el pegamento se reorganiza. Dos años después, una revisión de incidentes descubre que el agente de decisión de crédito estaba recibiendo prompts ensamblados por concatenación de cadenas en un servicio que nadie posee.

En las industrias reguladas, lo que está en juego es mayor porque los propios traspasos son la superficie de cumplimiento. Una decisión hipotecaria que fluye a través de cuatro agentes necesita un registro reconstruible de cada salto: qué se envió, qué se recibió, qué versión de qué agente lo produjo. La integración ad hoc hace que ese registro sea costoso o imposible. Un protocolo lo convierte en un subproducto de la realización del trabajo.

Qué es A2A

A2A es un protocolo abierto para que los agentes se descubran entre sí, intercambien mensajes y ejecuten tareas a través de los límites de procesos, equipos y organizaciones. Google lo anunció en abril de 2025 con docenas de socios de lanzamiento y lo donó a la Linux Foundation en junio de 2025, donde ahora reside como un proyecto de código abierto neutral. La especificación alcanzó la versión 1.0 en 2026.

Hecho	Detalle
Origen	Anunciado por Google, abril de 2025; donado a la Linux Foundation, junio de 2025
Gobernanza	Linux Foundation (el proyecto A2A, a2aproject en GitHub)
Especificación actual	1.0 (versiones anteriores desplegadas: 0.2, 0.3; se espera desfase en la práctica)
Transporte	JSON-RPC 2.0 sobre HTTP(S); enlaces gRPC y HTTP+JSON/REST añadidos más tarde en la vida de la especificación
Descubrimiento	Agent Card: metadatos JSON servidos en /.well-known/agent-card.json
Unidad de trabajo	Tarea, con un ciclo de vida definido y un ID único
Resultados	Artefactos (salidas estructuradas), distintos de los mensajes conversacionales
Streaming	Server-Sent Events en el enlace HTTP; streaming de servidor en gRPC
Trabajo de larga duración	Notificaciones push a un webhook de cliente, más resuscripción para reconexión
Autenticación	Declarada en la Agent Card: clave API, HTTP Basic/Bearer, OAuth 2.0, OpenID Connect, TLS mutuo

Dos decisiones de diseño importan más que el resto. Primero, A2A es opaco por intención: los agentes no exponen su estado interno, pesos del modelo o herramientas entre sí. Exponen capacidades e intercambian resultados. Esa opacidad es lo que permite que un agente construido por un proveedor, sobre un modelo que usted no controla, participe en su proceso sin que necesite confiar en sus internos, solo en su contrato. Segundo, A2A está orientado a tareas en lugar de a chats. El objeto central del protocolo es una tarea con un ciclo de vida, no un hilo de mensajes. Esa única elección es lo que lo hace utilizable para el trabajo empresarial, porque el trabajo empresarial no es una conversación. Es una unidad de trabajo con un estado, un propietario y una fecha límite.

La pila de protocolos: A2A, MCP, AG-UI, AP2

El marco más útil que he encontrado, y el que sigo dibujando en pizarras, es una pila. Cada protocolo responde a una pregunta diferente, y se componen en lugar de competir.

Protocolo	Capa	Pregunta que responde	Analogía aproximada
MCP	Agente a herramienta	¿Cómo llama un agente a las herramientas y accede a las fuentes de datos?	USB-C para capacidades
A2A	Agente a agente	¿Cómo se descubren los agentes pares entre sí y delegan tareas?	HTTP entre servicios
AG-UI	Agente a usuario	¿Cómo transmite un agente el estado a una interfaz orientada al humano?	WebSocket al front end
AP2	Agente a comerciante	¿Cómo prueba un agente la autoridad de pago y realiza transacciones?	Mandatos firmados que viajan en las capas inferiores

Un recorrido concreto por la pila: un usuario solicita a un agente de corredor una recomendación hipotecaria (AG-UI lleva la interacción a la interfaz de usuario). El corredor delega el análisis de riesgos a un agente de suscripción (A2A). El agente de suscripción extrae el expediente del solicitante de un almacén de documentos interno (MCP). Si el flujo terminara con el agente pagando un informe de crédito en nombre del usuario, la autoridad de pago viajaría como mandatos AP2. Cuatro protocolos, cuatro límites, un proceso.

La consecuencia práctica del marco de la pila es la disciplina arquitectónica. Cuando alguien propone exponer una base de datos interna como “un agente”, la pila le da el vocabulario para decir que no: eso es una herramienta, póngala detrás de MCP. Cuando alguien propone conectar dos agentes de proveedores con un webhook personalizado, la pila dice: eso es una delegación entre pares, use A2A y obtenga el ciclo de vida de la tarea de forma gratuita. Escribí un análisis profundo separado sobre la capa de pagos en la guía de campo de AP2; esta guía se centra en la costura de agente a agente.

La mecánica que importa

La especificación es larga. Cuatro piezas realizan la mayor parte del trabajo en la práctica.

Agent Cards: el descubrimiento como contrato

Una Agent Card es un documento JSON, servido en https://{host}/.well-known/agent-card.json, que describe qué es un agente, qué puede hacer y cómo comunicarse con él de forma segura. Es el equivalente A2A de un documento OpenAPI, excepto que describe capacidades y habilidades en lugar de endpoints y esquemas.

{
  "name": "Underwriter Agent",
  "description": "Analyzes applicant risk from income, debts, and credit score",
  "url": "https://agents.example.com/underwriter",
  "version": "1.4.0",
  "capabilities": { "streaming": true, "pushNotifications": true },
  "securitySchemes": { "oauth": { "type": "oauth2" } },
  "defaultInputModes": ["application/json", "text/plain"],
  "defaultOutputModes": ["application/json"],
  "skills": [
    {
      "id": "risk-analysis",
      "name": "Mortgage risk analysis",
      "description": "Produces a structured risk assessment for a loan applicant",
      "tags": ["underwriting", "risk"]
    }
  ]
}

En mi construcción del hackathon, la prueba de humo para todo el sistema es literalmente curl http://localhost:4001/.well-known/agent-card.json | jq '.name'. Si la tarjeta se resuelve, el agente es detectable; todo lo demás se basa en eso. La tarjeta también declara los requisitos de autenticación del agente y si admite streaming y notificaciones push, lo que un cliente debe verificar antes de confiar en cualquiera de ellos. La especificación actual admite tarjetas firmadas (una firma JWS sobre el contenido de la tarjeta) para que un cliente pueda verificar que una tarjeta fue emitida por quien dice ser. Use eso. Volveré a explicar por qué en el modelo de amenazas.

El ciclo de vida de la tarea

Cada delegación en A2A es una tarea con un ID y una máquina de estados. Los estados definidos, en sus formas JSON:

Estado	Significado	¿Terminal?
submitted	Reconocida, aún no iniciada	No
working	Procesando activamente	No
input-required	Pausada, esperando que el cliente proporcione más entrada	No (interrumpida)
auth-required	Pausada, esperando autorización adicional	No (interrumpida)
completed	Finalizada con éxito, artefactos disponibles	Sí
failed	Finalizada con un error	Sí
canceled	Cancelada antes de su finalización	Sí
rejected	El agente rechazó la tarea	Sí

Dos estados merecen atención porque codifican una realidad empresarial que los protocolos con forma de chat ignoran. input-required significa que una tarea puede pausarse a mitad de camino y solicitar más información, que es como un agente de suscripción remoto solicita un documento faltante sin que falle toda la tarea. rejected significa que un agente puede rechazar el trabajo para el que no está calificado o autorizado, lo cual es el gancho a nivel de protocolo para la aplicación de políticas. Un cliente que no maneja ambos estados no ha implementado A2A; ha implementado la demostración.

Mensajes, partes, artefactos

La comunicación dentro de una tarea utiliza mensajes (rol: usuario o agente), y cada mensaje lleva partes: texto, bytes sin procesar, una referencia de archivo o datos estructurados arbitrarios. Los resultados se devuelven como artefactos, que también se componen de partes pero son distintos de la conversación. Esta separación suena burocrática hasta que se construye algo real. La conversación es cómo negociaron los agentes; los artefactos son sobre lo que se actúa y lo que se audita. En el sistema hipotecario, el artefacto del agente de suscripción es una evaluación de riesgo estructurada. Los pasos posteriores consumen el artefacto, nunca la charla que lo produjo.

Streaming y tareas de larga duración

Para el trabajo interactivo, el enlace HTTP transmite objetos TaskStatusUpdateEvent y TaskArtifactUpdateEvent a través de Server-Sent Events (en el enlace JSON-RPC, message/stream). Eso es lo que impulsa una interfaz de usuario de progreso en vivo: la lista de verificación de suscripción animada de mi demostración hipotecaria se renderiza directamente a partir de actualizaciones de estado transmitidas.

La pieza que más importa para las empresas es el caso de larga duración. Las tareas reales en un banco no terminan en una sola conexión HTTP. Una verificación de “conozca a su cliente” puede llevar días. Una tasación de propiedad implica que un humano conduzca hasta una casa. A2A maneja esto con notificaciones push: el cliente registra un webhook, el servidor POSTea eventos de estado y artefactos a este a medida que la tarea progresa, y un cliente que se reconecta puede volver a suscribirse a una tarea por ID. Ninguna conexión necesita permanecer abierta, y ninguna de las partes necesita estar ejecutándose continuamente.

Pero observe lo que el protocolo no hace aquí: no recuerda nada por usted. Si su proceso cliente falla el segundo día de una tarea de tres días, A2A entregará felizmente el evento de finalización a un webhook que ya no sabe por qué le importa. El estado duradero en el lado del cliente es su problema, y es exactamente el problema para el que se construyeron los motores de flujo de trabajo. Esta es la razón técnica por la que la pregunta de la orquestación viene a continuación.

Orquestación versus enjambre

Hay dos formas de conectar agentes A2A a un sistema, y la elección importa más que cualquier otra en esta guía.

En el modelo de enjambre, los agentes se delegan entre sí de igual a igual. El corredor llama al agente de suscripción, el agente de suscripción decide por sí mismo llamar a un agente de documentos, el agente de documentos llama a otra cosa. El flujo de control es emergente. En el modelo de orquestación, un motor de procesos es el propietario del flujo y llama a los agentes A2A como pasos. El motor decide qué se ejecuta, en qué orden, con qué tiempo de espera; los agentes realizan el pensamiento dentro de cada paso. Mi versión de una línea, y el patrón que demostré en la serie de Camunda: el proceso es el orquestador.

En la serie de blog de dos partes, desglosamos esto en una heurística de decisión que todavía uso al pie de la letra. Si la pregunta en un paso dado es “llamar a este agente ahora, esperar hasta X minutos, reintentar Y veces y escalar en caso de falla”, ese paso pertenece a un flujo de proceso determinista con A2A invocado como una tarea de servicio. Si la pregunta es “a qué agente debo llamar, y qué debemos hacer a continuación”, ese paso pertenece a un subproceso de agente de IA donde A2A es una herramienta entre varias y el agente elige en tiempo de ejecución. En la construcción de Camunda, estos son literalmente dos modos de conector (autónomo versus herramienta de agente), pero el patrón es agnóstico al motor: en Temporal es una actividad versus un flujo de trabajo hijo impulsado por un planificador LLM; en LangGraph es un borde fijo versus un nodo de enrutador. Primero los patrones, luego los productos.

Los dos patrones son complementarios, no competitivos. Mis sistemas en funcionamiento utilizan ambos: una columna vertebral determinista para la ruta crítica, selección de herramientas impulsada por agentes dentro de las áreas exploratorias.

Lo que rechazo, con firmeza, es el enjambre puro en entornos regulados. Tres modos de falla surgen en cada revisión seria:

Auditabilidad. En un enjambre, reconstruir “qué agente decidió esto, basándose en qué” significa correlacionar registros entre servicios propiedad de diferentes equipos o diferentes empresas. En un flujo orquestado, cada llamada A2A es un paso en una instancia de proceso: entradas, salidas, tiempos y reintentos se registran como estado del proceso por construcción. Cuando construí la demostración hipotecaria, cada resultado intermedio del agente aterrizó en una variable de proceso nombrada que un operador podía inspeccionar. Eso no fue trabajo extra. Surgió de la arquitectura.

Cancelación atómica. Un cliente retira su solicitud. En un flujo orquestado, usted cancela la instancia del proceso y el motor cancela las tareas A2A en curso (el protocolo le da tasks/cancel; el motor le da a alguien para que lo llame). En un enjambre, la cancelación es un rumor que se propaga a la máxima velocidad posible a través de agentes que pueden o no respetarla. Ahora imagine que la tarea que se cancela es “enviar la solicitud de crédito”.

Investigación de incidentes. Cuando un flujo orquestado se rompe, el incidente tiene una dirección: instancia de proceso, paso, marca de tiempo, payload. Cuando un enjambre se rompe, la primera semana de la investigación es establecer lo que sucedió, y los propios registros narrativos de los agentes no son evidencia, son testimonio.

Comentario de revisión: si su arquitectura multiagente no tiene un único lugar donde alguien pueda responder “cuál es el estado de la solicitud de este cliente en este momento”, no ha construido un sistema. Ha construido un chat grupal con claves API.

Nada de esto requiere Camunda específicamente. Requiere que algo duradero e inspeccionable sea el propietario del flujo. Camunda es donde construyo porque es mi trabajo diario y porque BPMN ofrece a los auditores un diagrama que pueden leer, pero el argumento es válido para cualquier motor con estado duradero, temporizadores y semántica de cancelación.

Un patrón aplicado: el conserje hipotecario

He construido este sistema dos veces, así que describiré la forma generalizada y seré honesto sobre lo que cada construcción probó y lo que simuló.

El elenco, cuatro agentes y un límite:

• Agente corredor. La puerta de entrada. Recibe la solicitud del solicitante, decide qué especialistas contratar y elabora la recomendación final. En la construcción de Camunda, este es un subproceso de agente de IA con clientes A2A, tablas de decisión DMN, un almacén vectorial y una búsqueda de CRM en su caja de herramientas. En la construcción del hackathon, es un servicio de orquestación independiente.
• Agente de suscripción (remoto). Análisis de riesgos impulsado por Gemini sobre ingresos, deudas y puntaje de crédito. En la construcción del hackathon, este agente carga una guía completa de regulación hipotecaria (aproximadamente 85k tokens de la Guía de Venta de Fannie Mae) en contexto a través de la API de Archivos y cita códigos de regulación específicos, por ejemplo B3-6-02, en su salida. Es remoto y debería serlo: funciona completamente con datos que el solicitante eligió enviar, y se beneficia del modelo más potente disponible.
• Agente de investigación de mercado (local). Encuentra tasas aplicables para un perfil de riesgo. Deliberadamente alojado dentro del límite de confianza. Más sobre por qué en la siguiente sección.
• Agente juez. Evalúa la salida ensamblada por el corredor y califica su confianza. Por encima del umbral, el proceso procede automáticamente. Por debajo, el proceso se dirige a una tarea de revisión humana con el contexto completo adjunto. En la variante del hackathon, este rol es un agente de QA adversario que verifica las matemáticas (cálculos de deuda-ingresos, relaciones préstamo-valor) y rechaza las citas de regulación alucinadas antes de que un usuario las vea, enviando autónomamente las salidas fallidas de vuelta para su corrección.

El juez es la pieza que la gente subestima. Un respaldo humano con umbral de confianza convierte “el modelo a veces se equivoca” de una objeción en una ruta diseñada. El umbral es una decisión de negocio que se puede ajustar por clase de riesgo, y la tarea de revisión humana es un paso de proceso de primera clase con un SLA, no un manejador de excepciones atornillado después del primer incidente.

Honestidad sobre la brecha entre la demostración y la producción:

En mis demostraciones	En producción
Datos de crédito introducidos por el solicitante	Integración con buró de crédito con seguimiento de consentimiento
Un umbral de juez para todo	Umbrales por producto y clase de riesgo, propiedad del área de riesgo, revisados periódicamente
Agentes descubiertos por URLs de tarjetas codificadas	Un registro de tarjetas con verificación de firma y lista blanca
Cancelación de ruta feliz	Lógica de compensación para cada paso con efectos secundarios
Un equipo propietario de los cuatro agentes	Cuatro propietarios, cuatro ciclos de lanzamiento, pruebas de contrato en cada tarjeta

La última fila es la que lo cambia todo. Con un solo propietario, A2A es una buena convención interna. Con cuatro propietarios, es lo único que se interpone entre usted y el problema de pegamento N×(N-1) del principio de esta guía.

El patrón de límite de privacidad de datos

local-sensible / remoto-público

Este es el patrón de la construcción hipotecaria que más se generaliza, y el que me encuentro dibujando con mayor frecuencia para los bancos.

Divida sus agentes por sensibilidad de datos, no por función. Los agentes que manejan datos sensibles (PII del prestatario, historial de cuentas, cualquier cosa con restricciones de residencia regulatorias) se ejecutan localmente, dentro de su límite de confianza, en modelos que usted aloja o en contratos que usted controla. Los agentes que trabajan con datos públicos (tasas de mercado, comparables de propiedades, textos regulatorios) pueden ejecutarse de forma remota en el modelo de frontera más potente disponible. A2A es la costura entre las dos zonas.

El protocolo hace que esta costura sea limpia de una manera que la integración ad hoc no lo hace. La Agent Card anuncia la capacidad sin exponer datos: el corredor remoto sabe que el agente local de investigación de mercado existe y qué habilidades ofrece, pero cada intercambio real es una tarea A2A explícita y registrada cuyas partes del mensaje usted controla. Los campos sensibles simplemente nunca aparecen en las partes salientes, y debido a que todo el tráfico transfronterizo fluye a través de un solo protocolo, puede hacer cumplir eso con un gateway de salida que inspecciona los payloads A2A en un único punto de estrangulamiento en lugar de auditar una docena de integraciones a medida.

En el sistema hipotecario: el agente de suscripción (remoto, Gemini) ve los datos financieros que el solicitante envió exactamente para este propósito. El agente de investigación de mercado (local) realiza su recuperación dentro del límite y devuelve tasas, no contexto del cliente, en sus artefactos. El juez ve ambas salidas pero se ejecuta localmente. Nada en el patrón es exótico. Es segmentación de red, aplicada a agentes, con A2A como el protocolo enrutable en el límite. Esa familiaridad es una característica: su equipo de seguridad ya sabe cómo revisar este diseño.

Modelo de amenazas: las partes difíciles

A2A le proporciona una superficie de contrato. Las superficies de contrato son atacadas. Estos son los cinco problemas que planteo en cada revisión de diseño, aproximadamente en orden de cuán pronto le causarán problemas.

Suplantación de Agent Card

La tarjeta es un archivo JSON en una URL conocida. Cualquier cosa que pueda servir JSON puede afirmar ser su agente de suscripción. TLS protege el canal, no la afirmación: una entrada DNS comprometida, un subdominio secuestrado o un servicio interno malicioso pueden presentar una tarjeta perfectamente bien formada para un agente que no opera, y su corredor le enviará felizmente solicitudes de préstamo. Mitigaciones, en orden creciente de seriedad: fijar las URLs de las tarjetas en lugar de seguir el descubrimiento ciegamente; verificar las firmas de las tarjetas (la especificación admite tarjetas firmadas con JWS) contra emisores de confianza; y ejecutar un registro interno de tarjetas que actúe como una lista blanca, de modo que “detectable” y “invocable” sean privilegios diferentes. Trate una nueva Agent Card como trataría una nueva dependencia ascendente, porque eso es lo que es.

Deriva de capacidades

La tarjeta dice versión 1.4.0 y anuncia una habilidad de análisis de riesgos. Seis semanas después, el equipo detrás de ella cambia el modelo, reescribe el prompt del sistema y lanza la versión 1.4.1 con texto de tarjeta idéntico y un comportamiento materialmente diferente. Nada en el protocolo detecta esto; el contrato que A2A impone es estructural, no conductual. La mitigación es la misma que usamos para cualquier dependencia de servicio, adaptada para la no determinismo: pruebas de contrato que ejecutan tareas “golden” contra el agente en vivo según un cronograma y alertan sobre cambios en la distribución de los artefactos, no solo sobre rupturas de esquema. Si consume un agente que no posee, necesita un conjunto de evaluación para él. He medido suficientes cambios de modelo para decir esto claramente: misma tarjeta, mismo esquema, modelo diferente es un agente diferente.

Desfase de versiones

La especificación avanzó rápidamente: de 0.2 a 0.3 a 1.0 en aproximadamente un año, y los cambios no fueron cosméticos. Se agregaron enlaces de transporte, e incluso la ruta de descubrimiento conocida cambió en el camino (las implementaciones tempranas servían agent.json, la especificación actual dice agent-card.json). En un despliegue con múltiples propietarios, tendrá agentes en diferentes versiones de la especificación simultáneamente, garantizado. Registre la versión del protocolo en cada registro de tarea, pruebe explícitamente la ruta de negociación de versiones y no asuma que los SDK del ecosistema interpretan los casos extremos de manera idéntica, porque no lo hacen.

Observabilidad a través de los límites organizacionales

Dentro de su límite, puede rastrear todo. En el momento en que una tarea cruza al agente de un socio, su rastreo termina en su puerta. A2A le proporciona IDs de tarea e IDs de contexto para correlacionar, pero la correlación solo funciona si ambas partes mantienen y comparten los registros. Esto es una negociación de contrato, no un problema de código: acuerde la propagación de IDs de rastreo, la retención de registros y el acceso antes de salir en vivo, porque negociarlo durante un incidente es miserable. Mi posición predeterminada es que la parte que posee el resultado del cliente mantiene un registro autorizado de cada tarea transfronteriza: solicitud, respuesta, tiempo y versión de la tarjeta. La orquestación hace que esto sea casi gratuito; un enjambre lo convierte en un proyecto.

Quién es el propietario del SLA

Una tarea A2A contra un agente asociado tiene un tiempo de espera que usted establece y un tiempo de finalización que ellos controlan. Cuando el agente de suscripción se ralentiza de cuarenta segundos a cuatrocientos, ¿de quién es el incidente? El protocolo no se lo dirá. Incluya números en el acuerdo operativo (percentiles de tiempo de respuesta por habilidad, rendimiento, ventanas de mantenimiento planificadas) y haga cumplir su parte mecánicamente: presupuestos de tiempo de espera por paso, retroceso basado en temporizador en el sondeo, un número máximo de reintentos y una ruta de escalada definida cuando se agotan los reintentos. En el patrón determinista, todo eso reside en el modelo de proceso donde las operaciones pueden verlo. Si su única aplicación de SLA es la esperanza de que el agente remoto sea rápido, el enjambre ya ha ganado y usted ya ha perdido.

Comentario de revisión: cada uno de estos cinco es un problema organizacional con una superficie técnica. El protocolo le da la superficie. No puede asistir a la reunión de gobernanza por usted.

Lo que A2A no resuelve

La forma más rápida de perder credibilidad ante una junta de arquitectura es sobrevalorar un protocolo. Aquí está el límite honesto de este.

Semántica. A2A garantiza que un mensaje llega con una estructura válida. No garantiza que los dos agentes signifiquen lo mismo con income. ¿Bruto o neto? ¿Anual o mensual? ¿Hogar o individual? Dos agentes que cumplen con la especificación pueden intercambiar JSON impecable y producir una decisión incorrecta. Todavía necesita vocabularios compartidos, y en dominios regulados necesita tenerlos por escrito. El protocolo eleva el problema de integración un nivel; no lo disuelve.

Confianza. Las tarjetas firmadas le dicen quién publicó una declaración de capacidad. No le dicen si el agente es competente, si sus datos de entrenamiento fueron apropiados o si su operador seguirá existiendo el próximo trimestre. La reputación, la certificación y la rendición de cuentas de los agentes son problemas abiertos. Hoy se resuelven mediante contratos entre empresas, como siempre.

Pagos. A2A mueve tareas, no dinero. Cuando un agente necesita probar que está autorizado para gastar en nombre de un usuario, ese es un problema diferente con requisitos criptográficos diferentes, y para eso existe AP2. Lo escribí por separado en la guía de campo de AP2.

Calidad del modelo. Una tubería perfectamente orquestada de agentes mediocres produce mediocridad auditable. La capa de protocolo hace que las fallas sean visibles y atribuibles, lo cual es de gran valor, pero el patrón de agente juez y las evaluaciones honestas son lo que hace que las salidas sean confiables. Presupueste para ambos.

Estado de larga duración. El protocolo define cómo se comunica una tarea de varios días. No persiste su lado de la historia. Algo duradero tiene que recordar por qué inició la tarea, qué depende de ella y qué hacer cuando se completa o falla. Traiga un motor de flujo de trabajo, o prepárese para construir uno por accidente.

La versión de un párrafo

Cada proveedor envía un agente, por lo que el problema multiagente empresarial es un problema de integración antes que un problema de IA, y los problemas de integración se resuelven con protocolos. A2A (Google, abril de 2025; Linux Foundation, junio de 2025; especificación ahora en 1.0) es la capa de agente a agente de la pila, junto con MCP para herramientas, AG-UI para interfaces y AP2 para pagos: los agentes publican Agent Cards firmadas en /.well-known/agent-card.json, intercambian tareas a través de un ciclo de vida definido (submitted a completed, failed, canceled o rejected, con input-required y auth-required para pausas), transmiten el progreso a través de SSE y manejan el trabajo de varios días mediante webhooks. Conecte esos agentes con un orquestador duradero en lugar de un enjambre peer-to-peer, porque la auditabilidad, la cancelación atómica y la investigación de incidentes son lo que realmente pagan las industrias reguladas; divida los agentes a través de un límite de privacidad de datos (datos sensibles locales, datos públicos remotos, A2A como la costura); controle la salida autónoma con un juez con puntuación de confianza que recurra a la revisión humana; y sea consciente de lo que el protocolo le deja por resolver: semántica compartida, confianza del agente, SLAs a través de los límites organizacionales y el estado duradero que recuerda por qué se inició una tarea de tres días.

Referencias

• Coescribí la serie de dos partes en la que se basa esta guía con Joyce Johnson: Using A2A to Achieve Your Business Goals, Part 1 (el marco de decisión: pasos A2A deterministas versus selección de herramientas impulsada por agentes) y Part 2 (la construcción completa de préstamos hipotecarios, ambos patrones implementados).
• Especificación del protocolo A2A, la fuente autorizada para Agent Cards, estados de tareas, transportes y esquemas de seguridad; código fuente y SDKs en github.com/a2aproject/A2A.
• gemini3-hackathon-mortgage-concierge, mi construcción pública de precalificación hipotecaria multiagente: agentes de corredor, visión y suscripción con Agent Cards, contratos JSON-RPC 2.0, un contexto regulatorio de 85k tokens a través de la API de Archivos y un bucle de QA adversario.
• AP2: la capa de pagos, una guía de campo, mi análisis profundo complementario sobre lo que sucede cuando los agentes necesitan mover dinero, no solo tareas.