Protocolo A2A: cómo delegar entre agentes y cuándo usar MCP

El protocolo A2A sirve para delegar trabajo en un agente que opera de forma independiente. Model Context Protocol (MCP) sirve para darle acceso a herramientas o datos. A2A v1.0 cambia el contrato de integración, así que la decisión depende tanto de qué sistemas necesitas conectar como de las versiones que admiten sus endpoints.

MCP vs A2A: acceso a herramientas y datos o delegación de trabajo

MCP da acceso a capacidades. A2A permite pedirle a otro agente que se haga cargo de un trabajo. Ambos pueden convivir en un mismo sistema.

Model Context Protocol (MCP) estandariza la conexión de una aplicación de IA con sistemas externos, incluidas herramientas y fuentes de datos. Agent2Agent (A2A) estandariza la comunicación entre agentes independientes. La documentación oficial los presenta como complementarios. Introducción a MCP, A2A y MCP.

Ejemplo con MCP: consultar un pedido

Imagina un agente de atención al cliente que debe responder una pregunta sobre una entrega. Un servidor MCP expone una herramienta de consulta de pedidos. El agente envía el identificador del pedido, recibe sus datos y redacta la respuesta al cliente.

La ventaja para el negocio es disponer de una conexión reutilizable con el sistema de pedidos. No hace falta incorporar otro agente solo para recuperar un registro. La guía de servidores MCP aborda la parte de esta decisión que corresponde a la conexión con herramientas.

Ejemplo con el protocolo A2A: delegar una preselección de proveedores

Imagina un asistente de compras que necesita una preselección de proveedores adecuados. Otro proveedor opera un agente especializado en búsqueda de proveedores, que se encarga de todo el proceso de investigación. El asistente de compras envía los requisitos, responde una consulta sobre las necesidades de entrega y recibe una preselección estructurada.

El asistente de compras no necesita saber cómo busca el agente especializado, qué modelo utiliza ni cómo organiza sus pasos internos. Necesita acordar qué le pide y recibir un resultado útil. A2A está diseñado para facilitar esa relación entre sistemas.

El agente especializado podría usar MCP internamente para consultar datos de catálogos. En ese diseño, A2A permite delegar el trabajo; MCP proporciona el acceso a los datos.

La diferencia está en la interfaz que necesitas. Una herramienta MCP puede tener una lógica de implementación sofisticada. Elige A2A cuando quieras que el otro sistema se presente como un agente cuyas habilidades puedan descubrirse y cuyo trabajo tenga un ciclo de vida definido. La decisión no depende de lo inteligente que parezca su funcionamiento interno.

¿Qué es el protocolo A2A?

A2A establece un contrato de comunicación común entre agentes creados por distintos proveedores o con distintos frameworks. Permite interactuar con un agente sin acceder a su memoria interna, sus herramientas ni su lógica de decisión. El sitio del protocolo describe esos elementos internos como opacos. Descripción general de A2A.

Quien inicia la solicitud es el cliente A2A; el sistema que la acepta es el servidor A2A, también llamado agente remoto. Para quien funda una empresa y contrata una capacidad especializada, esto permite centrar la integración en la interfaz del servicio, sin tener que reconstruir la implementación del especialista.

¿Quién desarrolló A2A y quién dirige el proyecto?

El sitio oficial lo expresa con precisión: «A2A fue desarrollado originalmente por Google y donado a la Linux Foundation». También indica que un Comité Directivo Técnico mantiene el proyecto. Por tanto, su estructura de gobierno va más allá de su desarrollador original. Gobernanza y código abierto.

El repositorio a2aproject/A2A es el punto de entrada a la especificación, los enlaces a los SDK y los ejemplos. A2A es un protocolo; sigue siendo necesario elegir el software con el que crear y operar los agentes.

Especificación del protocolo A2A: conceptos que conviene distinguir

La distinción fundamental está entre la conversación, el trabajo cuyo progreso se sigue y el resultado que se entrega. Separarlos facilita el diseño de una integración con el protocolo.

Agent Card: cómo descubre el cliente lo que ofrece un agente

Una Agent Card es un documento de metadatos en JSON que describe la identidad de un agente, sus habilidades, capacidades, información de conexión y requisitos de autenticación. Ayuda al cliente a decidir si debe contactar con ese agente y cómo hacerlo. Conceptos básicos.

En el ejemplo de compras, la tarjeta podría anunciar habilidades de investigación de proveedores. Es el punto de partida para integrar el servicio, pero no demuestra que la preselección que entregue vaya a cumplir los criterios de compra.

La ruta de descubrimiento conocida que documenta el protocolo es /.well-known/agent-card.json. Las tarjetas también pueden obtenerse mediante configuración directa o un registro con entradas seleccionadas. A2A no define una API estándar para esos registros. Descubrimiento de agentes.

Tareas, mensajes, partes y artefactos

Una tarea es una unidad de trabajo con estado, identificador y ciclo de vida. Un mensaje es un turno de comunicación. Una Part contiene el texto, el contenido o la referencia de un archivo, o los datos estructurados. Un artefacto es un resultado concreto producido durante una tarea. Conceptos básicos.

En el ejemplo de proveedores, «¿En qué región se necesita la entrega?» es comunicación. El trabajo de búsqueda cuyo progreso se sigue es la tarea. La preselección terminada es un artefacto. El flujo de compras debería recibir esa preselección como un entregable, sin tener que buscar en la transcripción de una conversación algo que parezca un resultado final.

Un agente puede devolver un mensaje completo por sí mismo o crear una tarea. Las interacciones relacionadas se agrupan mediante contextId. Cuando una tarea llega a un estado terminal, cualquier ajuste da lugar a una tarea nueva, en lugar de reiniciar la anterior. Ciclo de vida de una tarea.

Esta distinción importa cuando el comprador cambia los requisitos después de la entrega. Conserva la identificación de la preselección original y trata su revisión como un trabajo nuevo, para que quienes utilicen después el resultado sepan cuál aprobaron.

Transportes: cómo se transmite un mismo contrato

Un transporte o enlace de protocolo define cómo se transmiten las operaciones a través de la conexión. La especificación define enlaces JSON-RPC, gRPC y HTTP+JSON/REST. Las interfaces de la Agent Card identifican el endpoint, el enlace y la versión del protocolo. Especificación de A2A.

Las consultas periódicas, el streaming y las notificaciones push determinan cómo llegan las actualizaciones de una tarea. Esta decisión es independiente del enlace utilizado. En un panel de compras pueden bastar las consultas periódicas; en una experiencia interactiva, recibir actualizaciones a medida que avanza el trabajo puede ser importante. Comprueba qué funciones admite el endpoint concreto antes de diseñar una interfaz que dependa de ellas.

¿Qué cambia en A2A v1.0?

Las integraciones existentes necesitan una revisión de compatibilidad; no basta con cambiar la cadena de versión. Estos son los cambios que describe la página oficial de novedades al comparar v0.3.0 con v1.0:

• Una definición compartida: a2a.proto pasa a ser la definición de referencia del protocolo, con especificaciones formales para sus enlaces.
• Cambios en el formato de transmisión: una Part unificada sustituye a los tipos de contenido separados; los nombres de los miembros reemplazan los discriminadores kind y los valores de las enumeraciones usan SCREAMING_SNAKE_CASE.
• Agent Cards reorganizadas: supportedInterfaces agrupa los detalles de conexión y declara la versión del protocolo por interfaz.
• Operaciones actualizadas: message/send pasa a ser SendMessage; ListTasks incorpora listados con filtros y paginación por cursor.
• Cambios para entornos empresariales: los campos de tenant, las reglas de verificación de firmas de Agent Card y los flujos OAuth actualizados afectan al diseño de la integración.

Estos cambios se verificaron en la página de novedades de v1.0 del proyecto el 12 de octubre de 2026.

Si ya tienes un conector, revisa en conjunto las solicitudes serializadas, el procesamiento de las respuestas, el descubrimiento de tarjetas y las operaciones que utilizas. Que la conexión funcione no demuestra por sí solo que todas las interacciones sigan comportándose correctamente.

¿Qué frameworks y plataformas admiten A2A?

Hay implementaciones documentadas, pero no todas cubren las mismas versiones y funciones. Elige según el comportamiento que necesita tu flujo de trabajo. El soporte y las limitaciones que se describen a continuación se comprobaron en la documentación pública de cada proveedor el 12 de octubre de 2026; no se hicieron pruebas dentro de una cuenta del producto.

Google Agent Development Kit

Google Agent Development Kit (ADK), un framework para crear agentes, documenta to_a2a para exponer un agente y generar su Agent Card. Su integración A2A para Python está marcada como experimental. La documentación contempla a2a-sdk 0.3.x y 1.x.x, y orienta las integraciones nuevas hacia 1.x.x. Guía de ADK para exponer agentes.

ADK también documenta RemoteA2aAgent para utilizar un agente remoto. Así, quien desarrolla con ADK dispone de puntos de entrada documentados para ambos lados de la delegación. Aunque el componente que facilita la integración resulte práctico, su estado experimental debe tenerse en cuenta al decidir el despliegue. Guía de ADK para utilizar agentes remotos.

LangGraph mediante LangSmith Agent Server

LangSmith Agent Server, la capa de servicio documentada para los despliegues de LangGraph, expone un endpoint A2A en /a2a/{assistant_id}. Su documentación especifica el enlace JSON-RPC de v1.0 y la aceptación de nombres de métodos de v0.3. El grafo necesita un campo messages en su estado. Documentación A2A de LangSmith.

La misma página enumera sus límites: gRPC y HTTP+JSON no están implementados, y todavía no se admiten SubscribeToTask ni la configuración de notificaciones push. Se admite el streaming de un mensaje, pero eso no implica que estén disponibles todas las operaciones de suscripción o notificación. Es un motivo concreto para revisar qué operaciones existen antes de elegir un diseño para tareas en segundo plano.

CrewAI y CrewAI AMP

CrewAI, un framework para coordinar agentes, documenta A2AClientConfig para delegar en agentes remotos y A2AServerConfig para exponer agentes. Un mismo agente puede configurarse para ambas funciones. Documentación de delegación de CrewAI.

CrewAI AMP, su plataforma de despliegue, marca los agentes servidores A2A como versión inicial y enumera las versiones del protocolo 0.2 y 0.3. También describe un almacenamiento distribuido persistente que sustituye al estado en memoria de la implementación de código abierto. Que CrewAI admita A2A no permite suponer que un endpoint de AMP admita v1.0. A2A en AMP.

Microsoft Foundry Agent Service

Microsoft Foundry Agent Service, una plataforma administrada de agentes, documenta un tipo de herramienta a2a con disponibilidad general para el protocolo 1.0. El tipo anterior, a2a_preview, admite 0.3 y sigue en versión preliminar. Microsoft recomienda el tipo con disponibilidad general para las integraciones nuevas. Documentación A2A de Foundry.

La página también indica que los agentes de Foundry que reciben las solicitudes solo admiten texto y no admiten respuestas en streaming. Un flujo que necesite un entregable multimedia en streaming debe tener en cuenta esa limitación. Los tipos de contenido que permite un protocolo no garantizan que todas las plataformas de alojamiento los implementen.

La comparativa de frameworks para agentes de IA ayuda a tomar la decisión más amplia sobre el framework. Estas notas de integración responden a una pregunta más concreta: ¿qué interfaz A2A documenta el sistema que sirve al agente?

Qué implica para quienes desarrollan, operan y contratan agentes

La ventaja es una interfaz de integración más reutilizable, siempre que valga la pena operar el servicio añadido. Las consecuencias cambian según quién tome la decisión.

Desarrollo: define qué delegas antes de incorporar un transporte. «Preparar una preselección con fuentes y justificaciones» delimita un servicio. «Ejecutar esta consulta a la base de datos» delimita una herramienta. Mantén esa distinción aunque ambas acciones acaben provocando llamadas a modelos.

Operación: asigna un responsable de la tarea después de delegarla. En el ejemplo de compras, alguien debe decidir qué ocurre si el agente de búsqueda pide más información, deja de responder o entrega una preselección que no cumple los criterios de aceptación. Compartir un formato de mensajes no resuelve esas responsabilidades.

Compras y fundadores: pide información sobre la versión del protocolo, el enlace, las operaciones y los tipos de contenido compatibles, además del estado del despliegue. Contrasta esos datos con los requisitos del flujo de trabajo. Una afirmación de compatibilidad sin ese detalle no basta para comprometerse con una integración.

Cómo presupuestar un despliegue de A2A

No existe una configuración única de despliegue de A2A con la que calcular la factura mensual. Un especialista alojado por un proveedor y un servicio que operas por tu cuenta tienen costos distintos, y la documentación del protocolo no establece un precio universal de plataforma.

Usa esta ecuación de planificación para un mismo período presupuestario:

Beneficio neto de la integración = costos de conectores evitados menos costos de migración, infraestructura adicional y operación continua.

Incluye entre los costos operativos el uso de modelos, el alojamiento, el almacenamiento de tareas, la monitorización y la responsabilidad de atender incidentes. Usa tus propios costos para cada término. A2A se justifica cuando elimina suficiente trabajo repetido de integración para compensar la nueva interfaz entre servicios que tendrás que mantener.

¿Qué se exagera sobre A2A?

Un protocolo común no vuelve confiables a los agentes desconocidos ni hace que el trabajo distribuido sea fiable de forma automática. Su estandarización resulta útil, pero las decisiones de la aplicación siguen siendo tuyas.

Una Agent Card anuncia lo que ofrece un servicio. Tú debes decidir si confías en su operador y aceptas sus resultados. Las recomendaciones empresariales de A2A dejan en manos de la implementación la aplicación de la autenticación y la autorización, incluidos los permisos sobre las acciones subyacentes. Guía de implementación empresarial.

En el flujo de búsqueda de proveedores, permite investigar sin conceder de forma implícita autorización para comprar. Devolver una recomendación y realizar un pedido deberían requerir permisos separados en la aplicación.

Gestiona por separado el artefacto recibido, el estado de su tarea y tu propio registro de aceptación. Antes de permitir que un flujo delegado cree una orden de compra, define cómo detectará la aplicación las acciones de negocio repetidas y cómo resolverá un resultado incierto.

Otra exageración consiste en añadir A2A a cada llamada interna a un subagente. El alcance del propio proyecto excluye expresamente definir cómo llama un agente a sus subagentes o herramientas internas. Si los componentes comparten el mismo contrato de aplicación, puede que los mecanismos de composición del framework ya resuelvan esa necesidad. Alcance de A2A.

¿Necesito A2A, MCP o ambos?

Empieza por las conexiones que tu producto necesita hoy.

Elige MCP cuando un agente necesite acceder a sistemas de negocio, archivos o API mediante interfaces de herramientas reutilizables. Si necesitas exponer una capacidad propia, sigue la guía para crear un servidor MCP en Python. Cuando el reto sea controlar el acceso a través de esas conexiones, la guía sobre gateways MCP aborda esa capa.

Elige A2A cuando otro agente, operado de forma independiente, se haga cargo de un trabajo sustantivo y necesites un mecanismo común para descubrir su interfaz, intercambiar instrucciones y seguir el progreso. Incorpóralo ahora si ya tienes esa necesidad de integración y los endpoints documentan funciones compatibles.

Elige ambos cuando tu agente delegue en un especialista que también necesite herramientas y datos. El ejemplo de proveedores encaja aquí: A2A para delegar la investigación y MCP para acceder al catálogo desde un agente.

Espera para incorporar A2A si el especialista externo todavía es una posibilidad hipotética. Un agente que funciona bien con sus herramientas actuales no necesita cambiar por la mera existencia de un nuevo protocolo entre agentes. Tampoco hacen falta estos estándares para cada llamada interna a una función. Adopta el contrato de conexión que resuelva un problema real de integración.

El siguiente paso para implementarlo

Define el contrato de delegación para un resultado de negocio acotado antes de migrar el resto de la arquitectura. En un asistente de compras, empieza por una preselección de proveedores y deja la ejecución de compras fuera del alcance inicial.

1. 1

   Define qué artefacto se puede aceptar

   Especifica qué información debe contener la preselección, qué condiciones la vuelven inaceptable y qué aplicación registra el resultado aceptado. Asigna al agente remoto una responsabilidad acotada.

2. 2

   Comprueba la compatibilidad de las interfaces documentadas

   Registra las versiones del protocolo del cliente y del servidor, el enlace, los requisitos de autenticación y las operaciones necesarias. Comprueba si el flujo necesita streaming o notificaciones push y si ambos endpoints los admiten.

3. 3

   Prepara la gestión de los casos pendientes de resolución

   Decide quién se ocupa de las aclaraciones, los tiempos de espera agotados, los rechazos y las respuestas inciertas después de un reintento. Define qué verá el usuario mientras el trabajo esté pendiente y cómo sustituirá un artefacto revisado a una versión anterior.

Ese contrato ofrece una base concreta para incorporar A2A. Si al redactarlo descubres que el supuesto especialista solo recupera un registro, implementa primero la conexión con la herramienta.

Preguntas antes de incorporar A2A

¿Puedo usar A2A sin MCP?

Sí. A2A no define cómo accede el agente remoto a sus propias herramientas y datos. MCP resulta útil cuando también necesitas conexiones estandarizadas con herramientas. Cómo se complementan.

¿Los dos agentes deben usar el mismo framework?

No. La interoperabilidad entre frameworks es uno de los objetivos centrales de A2A. Lo que debe coincidir es la interfaz expuesta y las funciones que exige la interacción, no la implementación interna de los agentes. Descripción general de A2A.

Para recibir guías prácticas sobre cómo crear sistemas de agentes útiles, suscríbete al boletín.