Tu proveedor te escribe que su agente ya habla A2A y que el tuyo puede conectarse mañana. Suena a infraestructura y parece cosa de una tarde de ingeniería. Pero en cuanto dos agentes de dos organizaciones distintas negocian una tarea —un pedido, una cita, una reclamación—, la pregunta que importa deja de ser cómo viajan los mensajes. Es quién responde cuando el mensaje es correcto y el resultado no.
La tesis en una frase: el protocolo A2A para agentes entre empresas resuelve el transporte y deja intacto el problema de fondo, que es contractual. Para casi todas las pymes, hoy, la decisión no es técnica: es qué firmas con quien pone al otro agente, qué permisos le das al tuyo y cómo vas a reconstruir una conversación que ninguna de las dos partes puede ver entera.
Protocolo A2A y agentes entre empresas: qué resuelve y qué deja sin resolver
A2A (Agent2Agent) es un protocolo abierto para que un agente encargue trabajo a otro sin saber cómo está construido por dentro. Nació en Google y la Linux Foundation anunció el 9 de abril de 2026 su versión 1.0, la primera especificación estable, con más de 150 organizaciones que lo respaldan según la propia fundación. Ojo con la cifra: viene de una nota de prensa de quien promueve el estándar y mide apoyos, no uso en producción.
Sus piezas principales son dos. La «tarjeta de agente», un documento que dice quién es el agente, qué sabe hacer y cómo autenticarse, y que en la 1.0 puede ir firmada. Y un ciclo de vida de tareas con estados estándar: trabajando, completada, fallida, rechazada, a la espera de datos, a la espera de autorización.
Lo que no hace pesa tanto como lo que hace. Según su especificación, cada agente colabora sin acceder al estado interno, la memoria ni las herramientas del otro. Es una virtud técnica —cada parte protege su implementación— y es, a la vez, el problema de gobierno: el agente de tu proveedor es por diseño una caja negra para ti, y el tuyo lo es para él.
| Pregunta | Lo que aporta A2A | Lo que queda para tu contrato |
|---|---|---|
| ¿Quién es el otro agente? | Tarjeta de agente, que puede ir firmada | Quién la emite y quién responde de que sea veraz |
| ¿Cómo se pide y se entrega el trabajo? | Mensajes y estados de tarea estándar | Qué cuenta como «entregado» y qué plazo hay para impugnarlo |
| ¿Quién puede pedir qué? | Esquemas de autenticación y autorización habituales en la web | Qué alcance se concede, a quién y cómo se revoca |
| ¿Qué pasa si se equivoca? | Estados de «fallida» o «rechazada» | Quién asume el error cuando la tarea figura como «completada» y es incorrecta |
| ¿Cómo se audita? | Nada específico | Qué registra cada parte y durante cuánto tiempo |
La última columna no es una opinión nuestra. La especificación se limita al protocolo y deja la confianza, la responsabilidad y la auditoría entre organizaciones en manos de quien lo despliega, y los análisis independientes del sector coinciden en que la seguridad entre organizaciones es la pregunta sin resolver.
¿En qué se diferencia A2A de MCP?
Respuesta corta: MCP conecta tu agente con tus herramientas; A2A conecta tu agente con el agente de otra organización. Con MCP decides tú qué herramientas existen, qué hacen y con qué credenciales; lo explicamos en qué es MCP y por qué cambia los agentes de empresa. Con A2A, al otro lado hay alguien que decide por su cuenta, con su propio modelo, sus propios errores y su propio calendario de cambios. Es la diferencia entre comprar una herramienta y subcontratar un taller.
Un ejemplo hipotético, sin nombres
El agente de compras de un cliente le pide al agente de ventas de su distribuidora «reponer este material al mejor precio». El segundo responde con un precio y un plazo, y la tarea queda marcada como completada. ¿Ese precio vincula? ¿El plazo es un compromiso? ¿Quién comprobó que el agente de la distribuidora usaba la tarifa correcta? Nada de eso viaja en el mensaje. Todo eso es contrato, y si no está escrito lo decide el primero que reclame con más fuerza.
Cuatro preguntas de contrato antes de conectar tu agente con el de un tercero
1. ¿Quién responde del resultado?
Cuando la tarea llega como completada y el resultado es incorrecto —un precio mal confirmado, una cita doble, un pedido por la cantidad equivocada—, el protocolo no tiene opinión. El contrato debe tenerla: qué cuenta como entrega, quién la verifica y cuánto tiempo hay para discutirla.
2. ¿Qué pasa si el agente del otro se equivoca?
Tu agente actúa sobre lo que el otro le dice. Si el otro inventa un plazo de entrega y el tuyo se lo promete a tu cliente, el error ya es tuyo de cara al cliente. Decide de antemano qué puede hacer tu agente solo con una respuesta externa y qué exige confirmación humana: es el razonamiento de los niveles de autonomía de un agente, aplicado a una fuente que no controlas.
3. ¿Cómo se audita una conversación entre dos cajas negras?
Cada parte ve solo su mitad. Para reconstruir qué pasó necesitas guardar lo que tu agente envió, lo que recibió, con qué identidad y con qué resultado, y pactar que la otra parte conserva lo suyo durante un plazo. Sin eso, la primera disputa se resuelve con dos relatos incompatibles. La base es la trazabilidad de decisiones de IA; para el plazo, cuánto tiempo guardar los logs de un agente de IA.
4. ¿Qué puede pedir cada uno y cómo se revoca?
Un agente que habla con el exterior abre una superficie nueva. Dale identidad propia, alcance por tarea y una revocación probada, como detalla la guía de permisos de un agente de IA, y exige lo mismo al otro. Una tarjeta de agente firmada acredita quién es el agente; no acredita que merezca el alcance que pide.
Cuándo NO necesitas A2A (todavía)
Tres situaciones en las que adoptarlo es adelantarse a un problema que no tienes:
- El otro lado ofrece una API normal. Si tu cliente o proveedor expone un servicio con entradas y salidas definidas, una integración clásica es más barata, más fácil de auditar y no depende de que dos modelos se entiendan. A2A compensa cuando el trabajo es abierto y hay negociación, no cuando es una consulta con respuesta cerrada.
- Todos tus agentes viven dentro de tu empresa. La coordinación interna se resuelve con orquestación, no con un estándar entre organizaciones. Empieza por orquestar varios agentes de IA y por preguntarte si hacen falta un agente o muchos.
- Nadie ha pedido que tu agente hable con otro. Un protocolo con muchos logos de apoyo no equivale a muchos casos en producción: el propio análisis del sector separa apoyar un estándar de mantenerlo después del primer incidente real.
Qué hacer esta semana
- Pregunta a tus proveedores clave si su agente ofrece A2A y qué ofrece hoy mismo por API. Si la respuesta es «lo estamos valorando», ya sabes el calendario.
- Para el primer caso candidato, escribe las cuatro preguntas de arriba con nombre y apellido: quién verifica, quién asume el error, qué se registra y qué alcance se concede.
- Define qué decisiones de tu agente exigen confirmación humana cuando el dato viene de fuera, y pruébalo con una respuesta errónea deliberada.
- Comprueba que tu registro guarda lo enviado y lo recibido con la identidad del agente que actuó. Si no, arréglalo antes de abrir ninguna conexión.