A2A Protocol: cómo conectar agentes de IA sin confundirlo con MCP
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 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
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.