Agent2Agent Protocol — A2A
Problema que resuelve
Agent2Agent Protocol es un protocolo abierto para que sistemas agentes interoperables descubran capacidades, intercambien mensajes y soliciten o cooperen en trabajo sin compartir su implementación interna. Define una frontera de comunicación entre sistemas que pueden pertenecer a equipos, organizaciones o frameworks diferentes. No define por sí mismo cómo construir un agente ni cómo coordinar toda una organización de agentes.
El problema aparece cuando una capacidad especializada se encuentra en otro sistema. En vez de integrar sus herramientas internas una por una, un participante puede solicitar un resultado y observar su progreso bajo un contrato compartido. Eso permite conservar opacidad sobre modelos, memoria y procesos internos. No implica que el resultado sea correcto, que la delegación resulte conveniente o que cualquier agente esté autorizado a usarlo.
Un sistema de coding podría pedir una revisión acotada a un agente especializado en otro dominio. La solicitud necesita comunicar objetivo, contexto pertinente y límites. A2A puede representar el intercambio; la elección del especialista y la evaluación de su resultado siguen siendo decisiones del diseño y del trabajo de ingeniería. No todo problema requiere otro agente ni una frontera remota.
Estado actual y gobernanza
Consulta del 2026-10-27: el proyecto publica la línea estable 1.0, con release de especificación v1.0.1. La especificación actual distingue compatibilidad Major.Minor del patch de publicación. Una versión de SDK es otro artefacto; no demuestra por sí sola qué protocolo y funciones comparte un par de participantes.
La gobernanza del proyecto asigna supervisión técnica a un Technical Steering Committee. La incorporación a AAIF, anunciada en agosto de 2026, sitúa el proyecto bajo esa fundación de Linux Foundation. Su origen en Google no define una propiedad exclusiva actual ni justifica describir el protocolo mediante un único producto comercial.
El nombre vigente sigue siendo Agent2Agent. Este canonical conserva identidad sin incluir la versión en título o ID. No lo califica como obligación universal o estándar adoptado por todo el sector. Cambios en bindings, mensajes o extensiones requieren revisar detalles fechados, manteniendo separado el propósito durable de interoperabilidad.
Participantes y opacidad
Los conceptos oficiales distinguen A2A Client, que inicia la interacción en representación de un usuario o servicio, y A2A Server / Remote Agent, que ofrece la capacidad. El cliente puede ser otro agente, una aplicación o un servicio. Por eso «agente ↔ agente» orienta el propósito principal sin excluir otros clientes compatibles.
El participante remoto puede verse como una caja opaca: el cliente no necesita acceso a sus herramientas o memoria interna para encargar trabajo. Esa separación favorece fronteras de implementación, pero no es un sandbox ni una garantía de confidencialidad suficiente por sí sola. Importan los datos compartidos, identidades y controles donde se producen los efectos.
agents conserva el significado general de sistema orientado a objetivos. El rol A2A identifica cómo participa una implementación en el protocolo, no demuestra qué decisiones toma internamente. Un endpoint HTTP genérico no se vuelve A2A por recibir texto, y un framework de agentes no es el protocolo por ofrecer un adapter compatible.
Agent Discovery y Agent Card
La Agent Card es una descripción protocolaria del sistema remoto: identidad anunciada, interfaces, capacidades, skills y requisitos de autenticación. Permite orientar selección e interacción. Encontrarla puede involucrar una ubicación well-known, un catálogo curado o configuración directa/privada; la existencia de la card no exige un registro público único.
Anunciar una capacidad no certifica su calidad ni concede permiso para utilizarla. Una card puede estar obsoleta o no corresponder al endpoint que el cliente esperaba. Conocer qué se ofrece es información para decidir, no una cadena automática de confianza. Firmas y controles de acceso pueden aportar garantías concretas, sin probar que cualquier resultado o acción sea apropiado.
agent-profiles configura una especialización reutilizable. Una Agent Card anuncia cómo interoperar con un sistema. Una definición local podría aportar información para generar parte de la card, pero sus responsabilidades son distintas: describir públicamente una capacidad no configura por sí mismo al actor que la realiza. Tampoco obliga a revelar instrucciones privadas o todos sus recursos internos.
Skill tiene aquí una colisión importante. Una descripción AgentSkill de A2A anuncia una clase de capacidad para discovery. agent-skills describe un procedimiento empaquetado, y Agent Skills specification define su representación. Anunciar una skill A2A no significa distribuir SKILL.md ni compartir un procedimiento ejecutable. Son niveles diferentes aunque una implementación los relacione.
Messages, Tasks y Artifacts
El intercambio utiliza mensajes y partes de contenido para solicitudes, respuestas y contexto. Una interacción puede devolver un mensaje sin una Task, según el caso. Task identifica una unidad de trabajo con estado y ciclo de vida; no es el texto del encargo ni un sinónimo de task-prompts. Una misma necesidad de desarrollo puede involucrar varios intercambios protocolarios.
Artifact representa un resultado o dato producido dentro de ese modelo. No pertenece a la clasificación documental del Atlas: canonical, perspective y MOC tienen otra función. Un informe recibido como Artifact podría convertirse en evidencia de un trabajo, pero su tipo protocolar no lo transforma automáticamente en conocimiento canónico ni en una decisión aceptada.
La guía del ciclo de una tarea distingue progreso, necesidad de input y estados terminales. Una tarea terminada no se reinicia como si nunca hubiera ocurrido; la continuidad relacionada necesita el tratamiento previsto. El estado completed informa sobre la ejecución remota, sin demostrar por sí solo que el solicitante acepta el resultado o que todos sus criterios fueron verificados.
| Elemento | Función en A2A | Concepto que no reemplaza |
|---|---|---|
| Agent Card | Describir interfaces y capacidades. | Agent Profile o permiso de uso. |
| Message | Intercambiar contenido de comunicación. | Encargo de desarrollo completo por definición. |
| Task | Identificar trabajo con estado. | Goal general, workflow o sesión universal. |
| Artifact | Comunicar resultado/datos producidos. | Canonical/MOC o evidencia automáticamente confiable. |
| Context identifier | Relacionar interacciones según el protocolo. | Memoria interna compartida. |
Trabajo prolongado, actualizaciones y fallos
La documentación de streaming y operaciones asíncronas contempla actualizaciones incrementales y notificaciones para trabajo prolongado, sujetas a capacidades. Una conexión abierta no es obligatoria para toda tarea y no todo participante soporta cada modalidad. Polling, streams o notificaciones tienen contratos de entrega y uso que deben verificarse.
Streaming permite observar progreso o resultados parciales, sin garantizar que el trabajo vaya bien. Un cliente puede perder conexión mientras la tarea continúa. Cancelar es otra operación con resultado y límites propios; no debe confundirse con cerrar la vista del usuario ni con revertir efectos ya realizados. El solicitante necesita comprobar el estado antes de repetir trabajo que pudiera haber producido una mutación.
Los fallos incluyen participante indisponible, versión no compatible, autenticación fallida, capacidad ausente, tarea rechazada y error de ejecución. Una tarea que solicita input adicional tampoco está en la misma situación que una tarea fallida. Conservar esas diferencias evita convertir cualquier interrupción en retry automático o cualquier respuesta válida en éxito comercial.
Las llamadas entre sistemas introducen preocupaciones distribuidas: correlación, timeouts y trazabilidad. deadline y idempotency aportan conceptos pertinentes cuando se fijan presupuestos o se evalúan repeticiones. El protocolo no elimina esas decisiones. development-context-and-execution-records puede conservar identificadores y resultados relevantes sin copiar toda la memoria remota.
Bindings y extensiones
La especificación separa operaciones y modelo de datos de sus bindings, incluidos JSON-RPC, gRPC y HTTP+JSON/REST. Compartir semántica no elimina la necesidad de elegir una interfaz compatible. Hablar HTTP o validar JSON no basta para implementar A2A. Tampoco un SDK que serializa mensajes define la estrategia de cooperación entre participantes.
Las extensiones de A2A permiten funciones adicionales identificadas mediante URIs y soporte declarado. No equivalen a agent-extension-packages: una describe una ampliación protocolaria y otro distribuye artefactos para un host. Una extensión requerida pero no comprendida limita la compatibilidad, aunque el núcleo general pueda reconocerse.
Interoperabilidad es comunicación mediante un contrato común. Portabilidad implica trasladar artefactos o implementaciones entre sistemas. Un agente remoto compatible no hace portables sus instrucciones, skills, modelo, memoria o resultados de calidad. La frontera puede facilitar cooperación sin prometer equivalencia de comportamiento ni acceso a mecanismos internos.
A2A frente a coordinación, subagents y handoffs
Multi-Agent Coordination es el problema de organizar varios agentes y sus responsabilidades. A2A puede transportar interacciones dentro de ese diseño, pero no decide división de trabajo, manejo de conflictos o aceptación de resultados. Un sistema multiagente puede usar mecanismos internos sin A2A; usar A2A tampoco demuestra una coordinación sofisticada o correcta.
Un subagent es una ejecución delegada bajo el diseño de otro agente o harness. Su existencia no exige un endpoint A2A. Un sistema podría exponer una capacidad delegada mediante el protocolo, pero la relación de delegación y la comunicación interoperable siguen siendo ejes distintos. No debe deducirse jerarquía, concurrencia o aislamiento de la sola presencia de una card.
Agent Handoffs transfiere responsabilidad o control; Context Handoff transfiere información. A2A puede participar en ese intercambio, sin definir por sí mismo que la responsabilidad se transfirió correctamente. Seleccionar contexto también exige conservar su autoridad. Enviar mensajes a otro agente no significa compartir toda la conversación ni renunciar al criterio de aceptación del solicitante.
Orchestrator–Workers es una familia de composición descrita en agentic-workflow-patterns. Los workers podrían comunicarse mediante A2A o mediante interfaces internas. El protocolo no es el orquestador ni el patrón. Mantener esa separación permite revisar cuándo hace falta interoperabilidad entre sistemas independientes y cuándo una delegación interna más simple es suficiente.
A2A frente a MCP y ACP
model-context-protocol expone capacidades y contexto a una aplicación AI; A2A organiza intercambio de trabajo con sistemas agentes. Un participante A2A puede utilizar MCP internamente. Eso no vuelve idénticos al servidor de herramientas y al agente remoto ni establece que los protocolos compitan por toda integración.
agent-client-protocol integra cliente/editor y coding agent. A2A tiene otro propósito principal, aunque una aplicación pueda ocupar el rol cliente y un coding agent participar en ambos. Las fronteras se superponen en sistemas reales; no constituyen una pila obligatoria ni una clasificación por la máquina donde corre cada componente.
La composición ilustrada en MCP ubica editor, coding agent, capacidades y otro sistema agente. Un repositorio .NET podría usar A2A solo para solicitar una revisión acotada. El contrato del resultado debe indicar qué revisión y alcance se observaron, qué evidencia existe y qué quedó pendiente. Ninguno de los tres protocolos es requisito para realizar esa revisión mediante otra integración.
Identidad, autorización y confianza
La guía de implementación enterprise sitúa autenticación y protección de transporte en mecanismos existentes, con requisitos anunciados por el sistema remoto. La adquisición de credenciales y la política de autorización necesitan su tratamiento correspondiente. A2A no inventa una identidad confiable por recibir una descripción ni autoriza todo trabajo que un participante sabe expresar.
Que Agent A solicite algo a Agent B no significa que B herede la autoridad de A, ni que deba usar sin límites sus propias credenciales. La autorización debe corresponder al solicitante, destino y operación. Confused Deputy y Least Privilege son relaciones importantes para analizar esa frontera, sin desarrollar aquí sus canónicos ni una guía completa de seguridad.
agent-permissions-and-approval-boundaries conserva esa distinción y agent-sandboxing limita recursos donde se aplique efectivamente. El sandbox del solicitante no demuestra aislamiento del sistema remoto. Compartir un resultado no obliga a compartir toda memoria o contexto; datos privados y secretos necesitan tratamiento adecuado antes de cruzar la frontera.
Conexión no implica confianza. Discovery no implica permiso. Un schema válido no demuestra acción segura. Identidad no equivale a autoridad delegada. El resultado de otro agente tampoco es una instrucción superior al encargo vigente. Estas separaciones permiten aprovechar la interoperabilidad sin sustituir controles por etiquetas de protocolo.
Contrato del resultado y responsabilidad
En la revisión acotada de Commerce, el solicitante necesita saber qué revisión del código observó el sistema remoto y qué significa su conclusión. «No encontré problemas» sin alcance o evidencia tiene un valor diferente de un análisis que identifica condiciones verificadas y límites. La opacidad de la implementación no impide pedir un resultado revisable; tampoco justifica exigir memoria privada o razonamiento interno para aceptar una contribución.
El resultado puede contener recomendaciones fuera del encargo. El solicitante debe tratarlas como información que necesita evaluación, no como instrucciones que automáticamente amplían autoridad. Si el agente remoto propone desplegar para comprobar una hipótesis, esa propuesta no crea aprobación de release. La separación protege tanto al solicitante como al proveedor frente a una delegación interpretada de manera más amplia que la acordada.
La responsabilidad de integrar el resultado tampoco desaparece por haber utilizado otro sistema. Un cliente puede recibir un Artifact correcto en forma y todavía necesitar contrastar su compatibilidad con restricciones del proyecto. Puede decidir aceptar una parte, pedir aclaración o registrar una comprobación pendiente. A2A transporta la cooperación; la decisión de producto y el criterio de ingeniería conservan sus dueños. Esta distinción ayuda a evaluar interoperabilidad por el trabajo que habilita, sin confundirla con una garantía global de calidad.
Relaciones en el Atlas
agent-harness puede sostener una implementación que participe en A2A, sin estar definido por él. coding-agent conserva el trabajo delegado de software; ai-assisted-software-engineering ofrece navegación hacia artefactos e interoperabilidad. Este documento no materializa una arquitectura multiagente ni inicia workflows, endpoints o integraciones reales.
Fuentes
Fuentes primarias consultadas el 2026-10-27. Definición de trabajo, comparaciones y consecuencias de diseño son síntesis editorial. Estado de versiones, entidades y bindings corresponden a las fuentes actuales, sin reproducir sus schemas.
- A2A: Specification y release v1.0.1.
- Core Concepts, Agent Discovery y Life of a Task.
- Streaming & Asynchronous Operations, Extensions y Enterprise Features.
- Project governance y AAIF: A2A joins AAIF, contexto institucional.