A2A Protocol no es otro nombre para MCP. Es una capa para que agentes independientes se descubran, negocien tareas y colaboren sin exponer sus herramientas internas.
A2A Protocol, o Agent2Agent Protocol, es un estándar abierto para que agentes de IA independientes se descubran, se autentiquen, intercambien mensajes y gestionen tareas largas. La keyword principal es A2A Protocol; la intención de búsqueda en español es entender qué es, en qué se diferencia de MCP y cómo implementarlo sin abrir una superficie de seguridad absurda.
TL;DR
La definición citable: A2A conecta agentes con otros agentes; MCP conecta agentes con herramientas y recursos. Si tu problema es invocar una función, consulta una base de datos o llamar a una API, piensa en MCP. Si tu problema es delegar trabajo a otro sistema agentic que tiene estado, criterio y herramientas propias, piensa en A2A.
Mi postura: A2A merece atención porque ya no es solo una propuesta de Google. Está bajo Linux Foundation, tiene especificación 1.0 y adopción empresarial, pero no deberías desplegarlo como federación abierta de agentes hasta tener identidad, firmas de Agent Card, límites de datos, auditoría y threat modeling.
Qué es A2A Protocol y por qué importa ahora
La especificación oficial define A2A como un estándar abierto para comunicación e interoperabilidad entre sistemas agentic independientes y potencialmente opacos. Esa palabra, opacos, es clave: el cliente no necesita saber si el agente remoto usa Claude, Gemini, LangGraph, herramientas internas, memoria propia o un humano en el bucle. Necesita saber qué capacidades ofrece, cómo autenticarse y cómo seguir el estado de una tarea.
El momento importa porque A2A ya no vive solo como anuncio de producto. Google transfirió el proyecto a Linux Foundation para darle gobernanza neutral y la fundación comunicó en abril de 2026 que más de 150 organizaciones apoyaban el estándar, con integraciones en grandes nubes y despliegues empresariales. Eso no garantiza éxito, pero sí cambia el riesgo: ignorarlo puede dejarte fuera de una capa de interoperabilidad que tus proveedores empiecen a asumir.
Para DevAI Semanal, la lectura práctica es esta: A2A es interesante si estás diseñando un ecosistema de agentes, no si solo quieres que un asistente llame a tus tools. La frontera técnica evita muchas arquitecturas infladas.
A2A vs MCP: la diferencia que evita malas arquitecturas
La documentación oficial lo explica con una separación bastante limpia. MCP estandariza cómo un agente usa herramientas, APIs, bases de datos y recursos con entradas y salidas estructuradas. A2A estandariza cómo agentes autónomos colaboran entre sí, descubren capacidades, negocian interacción, mantienen contexto y gestionan tareas más largas.
Ejemplo: si un agente de soporte necesita consultar get_invoice(customer_id), eso es MCP o una tool function. Si ese mismo agente necesita delegar una investigación completa a un agente de facturación que conversa, valida políticas, puede pedir más datos y devuelve un resultado auditable, eso encaja mejor con A2A.
La arquitectura sana combina ambos. Un agente puede hablar A2A con otro agente y, por dentro, ese segundo agente puede usar MCP para llamar a sus herramientas. Dicho en una frase: A2A es coordinación entre agentes; MCP es acceso a capacidades.
Los bloques técnicos: Agent Card, Message, Task, Part y Artifact
El primer concepto es la Agent Card. Es un documento JSON que describe identidad del agente, endpoint de servicio, capacidades A2A, requisitos de autenticación y lista de skills. Es la tarjeta de presentación técnica que un cliente analiza antes de decidir si puede interactuar con ese agente.
Después vienen los elementos de comunicación. Message representa un turno entre cliente y agente. Part es el contenedor de contenido dentro de mensajes y artefactos: texto, datos estructurados, bytes inline o referencia por URL. Artifact es una salida tangible de una tarea, como un documento, datos estructurados o un archivo generado.
La unidad operativa importante es Task: trabajo con estado, ID único y ciclo de vida propio. Eso permite operaciones largas, multiturno, streaming, polling y notificaciones. Si tu caso no necesita estado ni lifecycle, probablemente estás intentando usar A2A donde bastaba una tool.
Cómo viaja una petición A2A
En su forma práctica, un cliente descubre o recibe una Agent Card, valida si el agente remoto soporta la capacidad que necesita, se autentica con el esquema declarado y envía una petición. La versión 1.0 formaliza bindings equivalentes para JSON-RPC, gRPC y HTTP+JSON; la ruta simple puede empezar con una petición HTTP, pero el diseño soporta polling, streaming y webhooks.
Lo que conviene comprobar
En JSON-RPC, los métodos core incluyen enviar mensaje, enviar mensaje con streaming, obtener tarea, listar tareas, cancelar tarea, suscribirse a una tarea y gestionar configuración de push notifications. Eso ya te dice qué tipo de sistema espera A2A: no una llamada stateless de 200 milisegundos, sino colaboración con progreso, cancelación, reintentos y seguimiento.
La implicación para backend es clara: A2A no se añade como un endpoint fino encima de un prompt. Necesitas persistencia de tareas, IDs, estados, logs, control de permisos, timeouts, límites de concurrencia y una historia razonable para errores.
Un endpoint mínimo que no me daría vergüenza revisar
Empieza por un único agente remoto con una skill estrecha. No publiques veinte skills genéricas como do_work. Publica algo auditable: review_openapi_contract, triage_ci_failure o summarize_security_finding. Cada skill debe tener descripción, input esperado, outputs, límites y requisitos de autenticación.
La Agent Card pública debe contener lo mínimo para discovery: nombre, versión, endpoint, capacidades, protocolos soportados, auth y skills no sensibles. Si necesitas exponer detalles internos, usa extended Agent Card autenticada. La especificación contempla tarjetas extendidas para devolver información adicional según el nivel de autenticación.
Para la implementación, crea una tabla agent_tasks con task_id, client_id, skill_id, state, created_at, updated_at, expires_at, input_hash, artifact_refs y audit_log_ref. Si no puedes responder qué pasó con una tarea hace dos días, todavía no tienes un servidor A2A serio.
Checklist de implementación
Define una sola skill inicial y su contrato de entrada/salida.
Publica una Agent Card mínima y versionada.
Valida schema de Agent Card, Message, Task, Part y Artifact.
Exige autenticación antes de aceptar trabajo con datos sensibles.
Implementa estados de tarea, cancelación y timeouts.
Separa artifacts de logs y aplica retención explícita.
Añade streaming solo si aporta valor real al usuario.
Firma o verifica Agent Cards cuando dependas de agentes externos.
Registra quién delegó qué tarea, a qué agente y con qué permisos.
Prueba fallos: agente lento, tarea duplicada, payload inválido y credencial revocada.
Seguridad: la Agent Card también puede ser entrada hostil
El error ingenuo es tratar la Agent Card como documentación inocua. En realidad, un agente o directorio externo puede publicar descripciones, tags, ejemplos o metadatos diseñados para influir en otro agente. La investigación sobre seguridad A2A menciona riesgos como spoofing de Agent Card, task replay, escalada de privilegios, prompt injection y flujos de datos no autorizados.
A2A v1.0 mejora la base con verificación de firmas de Agent Card mediante JWS y canonicalización JSON, declaraciones de seguridad más ricas, soporte de mutual TLS, flujos OAuth modernos, PKCE y paginación. Eso no te salva si tu implementación acepta cualquier tarjeta, mezcla datos de tenants o deja que una descripción remota entre directa al prompt del agente principal.
Trata Agent Cards y Artifacts como input externo: valida schema, sanitiza texto antes de meterlo en prompts, limita tamaño, verifica origen, registra versión, aplica allowlists de dominios y separa permisos por skill. Un agente federado no debe heredar automáticamente tus tools internas.
Cuándo usar A2A y cuándo no
Sí usaría A2A para marketplaces internos de agentes, coordinación entre departamentos, agentes especializados de proveedores, flujos de backoffice largos, atención al cliente con handoff entre dominios o sistemas donde un agente necesita delegar a otro sin conocer su implementación interna.
No lo usaría para wrappers simples de API, funciones deterministas, scripts internos, consultas de base de datos, retrieval de documentos o automatizaciones que no necesitan estado propio. En esos casos MCP, OpenAPI, colas normales o llamadas HTTP bien diseñadas suelen ser más simples y más auditables.
La pregunta de decisión es: ¿el otro lado razona, mantiene estado y puede producir artefactos a lo largo de una tarea? Si la respuesta es no, A2A probablemente es sobrearquitectura.
Observabilidad y gobernanza
Un despliegue A2A sano necesita más que trazas HTTP. Debes poder responder: qué agente pidió la tarea, qué Agent Card se usó, qué versión de skill aceptó el trabajo, qué datos cruzaron la frontera, qué artifacts se generaron, qué permisos estaban activos y quién aprobó el resultado si hubo acción sensible.
Mide tasa de tareas completadas, canceladas, expiradas y fallidas por skill; latencia p50/p95; bytes de artifacts; refusals o bloqueos de política; llamadas a herramientas internas hechas por el agente remoto; y revisiones humanas requeridas. Si solo mides número de delegaciones, puedes estar celebrando trabajo que nadie revisa.
Gobernanza pragmática: directorio de agentes aprobados, owner por Agent Card, expiración de credenciales, revisión periódica de skills, límites por tenant y kill switch por proveedor. A2A facilita interoperabilidad; no decide por ti qué agentes merecen confianza.
Errores comunes
- El primer error es llamar A2A a cualquier webhook. Si no hay Agent Card, tareas, autenticación, estado y contrato de interacción, probablemente solo tienes una API.
- El segundo error es publicar skills demasiado amplias.
general_coding_agentsuena potente y revisa fatal. Una skill amplia hace más difícil limitar datos, permisos y expectativas. - El tercer error es confundir discovery con confianza. Encontrar una Agent Card no significa que el agente sea legítimo, actualizado o autorizado para tu tenant.
- El cuarto error es olvidar retención. Los artifacts y mensajes pueden contener datos sensibles; define cuánto viven, quién los puede leer y cómo se borran.
Conclusión
A2A Protocol es una pieza seria si estás construyendo sistemas multiagente entre equipos, proveedores o plataformas. Su valor no está en reemplazar MCP, sino en cubrir una capa distinta: colaboración stateful entre agentes que no quieren o no pueden exponer sus herramientas internas.
Lo que conviene comprobar
Mi recomendación es empezar pequeño: un agente, una skill, una Agent Card mínima, auth fuerte, tasks persistidas, logs útiles y revisión humana en acciones sensibles. Si eso aporta valor, escala. Si no, vuelve a MCP o a una API normal. La madurez técnica está en elegir la capa más simple que preserve seguridad y trazabilidad.
Preguntas frecuentes
¿Qué es A2A Protocol?
A2A Protocol es un estándar abierto para que agentes de IA independientes se descubran, se comuniquen y colaboren en tareas con estado.
¿A2A Protocol reemplaza a MCP?
No. A2A y MCP son complementarios: A2A sirve para colaboración entre agentes; MCP sirve para que un agente use herramientas y recursos.
¿Qué es una Agent Card en A2A?
Una Agent Card es un documento JSON que describe identidad, endpoint, capacidades, skills y requisitos de autenticación de un agente.
¿A2A usa JSON-RPC?
Sí. La especificación 1.0 define bindings para JSON-RPC, gRPC y HTTP+JSON, con equivalencia funcional entre ellos.
¿Cuándo debería usar A2A?
Úsalo cuando delegas trabajo a otro agente autónomo con estado, capacidades propias y artefactos; no para una llamada simple a una función.
¿Qué riesgos de seguridad tiene A2A?
Los riesgos principales son Agent Card spoofing, prompt injection en metadatos, replay de tareas, permisos demasiado amplios, fuga de artifacts y confianza automática en agentes externos.
Fuentes y referencias
- A2A Protocol: specification
- A2A Protocol: A2A and MCP
- A2A Protocol: core concepts
- A2A Protocol: what's new in v1.0
- A2A Protocol: announcing version 1.0
- Linux Foundation: A2A adoption milestones
- Google Developers Blog: A2A donated to Linux Foundation
- arXiv: Building a Secure Agentic AI Application Leveraging Google's A2A Protocol
📬 Suscríbete gratis a DevAI Semanal — cada semana, herramientas de IA para devs (agentes, MCP, seguridad) en un email de 5 minutos. En español y sin ruido.
Publicado originalmente en devaisemanal.com.