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, 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.

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.

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.

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.

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.

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.