Cuando Azure AI Foundry y Copilot Studio se sumaron al protocolo A2A el 7 de mayo de 2025, quedó claro que esto ya no era solo un experimento de Google era la señal de que el ecosistema completo se alineaba en torno a un estándar abierto para la comunicación entre agentes de IA.
¿Qué problema resuelve A2A?
Imagina que tienes un agente de ventas construido sobre Azure AI Foundry y quieres que delegue una tarea contable a otro agente especializado que está corriendo sobre LangGraph en una infraestructura completamente distinta. Sin un protocolo común, eso implica integraciones a medida, código de pegamento y acuerdos punto a punto que no escalan. A2A nació precisamente para eliminar esa fricción.
El protocolo fue anunciado por Google en abril de 2025 con el respaldo de más de 50 partners tecnológicos, Microsoft incluido. Desde entonces ha sido donado a la Linux Foundation, lo que refuerza su carácter verdaderamente abierto. No es propiedad de nadie y eso importa.
La idea central es sencilla: que cualquier agente pueda descubrir a otro agente, enviarle una tarea y recibir el resultado, independientemente de en qué framework está construido o en qué nube reside. Semantic Kernel, LangGraph, CrewAI, agentes propios todos pueden hablar el mismo idioma.
Figura: A2A y MCP como protocolos complementarios en el stack de agentes (fuente: github.com/a2aproject/A2A)
Los bloques técnicos del protocolo
A2A se apoya en tecnologías web estándar — JSON-RPC 2.0 sobre HTTP(S) y Server-Sent Events para streaming. No hay nada exótico. Quien ya sabe construir una API REST entiende el 80% del protocolo con solo leer la especificación.
AgentCard: la tarjeta de visita del agente
El punto de entrada de cualquier integración A2A es el AgentCard, un documento JSON que el servidor de agente publica en /.well-known/agent.json (o en la ruta que defina). Esa tarjeta describe qué sabe hacer el agente, qué métodos acepta, qué esquemas de autenticación soporta y cuál es su endpoint. Es, literalmente, el contrato público del agente.
Un AgentCard mínimo tiene esta estructura:
{
«name»: «CurrencyExchangeAgent»,
«description»: «Convierte divisas usando tasas de cambio en tiempo real»,
«url»: «https://mi-agente.azure.com/a2a»,
«version»: «1.0»,
«capabilities»: {
«streaming»: true,
«pushNotifications»: false
},
«skills»: [
{
«id»: «convert_currency»,
«name»: «Convertir divisa»,
«description»: «Convierte un importe de una divisa a otra»
}
],
«securitySchemes»: {
«bearerAuth»: { «type»: «http», «scheme»: «bearer» }
}
}
Cuando un agente cliente quiere colaborar con este agente, lo primero que hace es resolver esa tarjeta. En el SDK .NET de A2A, eso se traduce en dos líneas:
A2ACardResolver cardResolver = new A2ACardResolver(new Uri(«http://mi-agente.azure.com/»));
AgentCard agentCard = await cardResolver.GetAgentCardAsync();
El ciclo de vida de una tarea
Una vez que el cliente conoce al agente, le envía mensajes y obtiene tareas a cambio. El ciclo de vida de esas tareas es uno de los aspectos más cuidados de la especificación. Hay ocho estados posibles:
- SUBMITTED la tarea se ha recibido y está en cola
- WORKING el agente está procesando activamente
- COMPLETED éxito — estado terminal
- FAILED error — estado terminal
- CANCELED cancelada antes de terminar — estado terminal
- REJECTED el agente rechazó la tarea — estado terminal
- INPUT_REQUIRED el agente necesita más información del usuario
- AUTH_REQUIRED se requiere autenticación adicional
Los cuatro primeros son los que verás en el 90% de los casos. Los dos intermedios (INPUT_REQUIRED y AUTH_REQUIRED) son interesantes para flujos humano-en-el-bucle, donde el agente necesita pausar y pedir algo al usuario antes de continuar.
Streaming con SSE
Para tareas que tardan, A2A usa Server-Sent Events. El cliente abre una conexión y el servidor va empujando eventos — actualizaciones de estado, fragmentos de resultado, artefactos — hasta que la tarea llega a un estado terminal. Nada de polling. En el SDK .NET:
await foreach (SseItem<A2AEvent> sseItem in client.SendMessageStreamAsync(
new MessageSendParams
{
Message = new Message
{
Role = MessageRole.User,
Parts = [new TextPart { Text = «Convierte 1000 EUR a USD» }]
}
}))
{
// Procesa cada evento según llega
Console.WriteLine(sseItem.Data);
}
Figura: Actores del protocolo A2A: client, server y sus roles (fuente: github.com/a2aproject/A2A)
A2A en el ecosistema Microsoft
El 7 de mayo de 2025 Microsoft anunció el soporte de A2A en Azure AI Foundry y Copilot Studio. No fue un anuncio menor — Copilot Studio tiene más de 230.000 organizaciones activas y Azure AI Foundry cuenta con 70.000 empresas usando sus capacidades. La implicación práctica es que los agentes de Copilot Studio podrán invocar agentes externos (incluidos los construidos fuera del ecosistema Microsoft) de forma segura y estandarizada.
Pero la integración más inmediata para desarrolladores es la de Semantic Kernel. Hay una muestra oficial en Python que ilustra cómo dos agentes colaboran para planificar un viaje y convertir divisas — sin código de orquestación personalizado, solo el protocolo. El agente central (TravelManager) recibe la petición A2A, identifica qué agente especializado puede resolverla (ActivityPlannerAgent o CurrencyExchangeAgent) y delega. Semantic Kernel mantiene la historia de conversación entre turnos.
Para .NET, el SDK oficial está en github.com/a2aproject/a2a-dotnet y se instala con dos paquetes NuGet: A2A y A2A.AspNetCore. El servidor se levanta con una sola línea en la configuración de ASP.NET Core:
// En Program.cs
app.MapA2A(taskManager, «/agent»);
El SDK está en preview — la API puede cambiar. Pero la especificación del protocolo en sí es estable (versión 1.0 bajo gobernanza de la Linux Foundation), así que lo que construyas hoy seguirá siendo válido cuando el SDK madure.
Figura: Diagrama de integración Semantic Kernel + A2A Protocol (fuente: devblogs.microsoft.com/foundry)
A2A y MCP: protocolos complementarios, no competidores
Cuando salió A2A, algunos lo compararon inmediatamente con MCP (Model Context Protocol de Anthropic). La confusión es comprensible — ambos son protocolos abiertos para agentes de IA — pero responden a preguntas distintas.
MCP conecta agentes con herramientas y datos: bases de datos, APIs, sistemas de ficheros. Es la capa de acceso a recursos. A2A conecta agentes con otros agentes: delegar trabajo, coordinar subtareas, orquestar pipelines distribuidos. Es la capa de colaboración entre pares.
En la práctica, los usarás juntos. Un agente puede recibir una tarea de otro agente vía A2A y, para resolverla, hacer llamadas a herramientas externas vía MCP. No son competidores — son las dos piezas que faltaban en el stack de agentes productivos.
Seguridad: lo que la especificación garantiza
Una de las preguntas que aparece siempre en proyectos de producción es: ¿cómo controlo quién puede llamar a mis agentes? A2A tiene respuesta. La especificación incluye soporte nativo para API Key, HTTP Basic, OAuth2, OpenID Connect y mTLS. Los agentes declaran sus esquemas de autenticación en la AgentCard y los clientes deben presentar las credenciales adecuadas antes de poder enviar tareas.
En el contexto de Azure, esto se complementa con lo que Microsoft ya tiene: Microsoft Entra para autenticación, mutual TLS en la capa de red y Azure AI Content Safety para filtrar contenido en las comunicaciones entre agentes. El principio que aplica Microsoft es ‘trust by default’ — cada llamada pasa por los mismos controles que cualquier otra petición a un servicio Azure.
Hay también un mecanismo de Extended AgentCard: una versión más detallada de la tarjeta del agente que solo se expone a clientes autenticados. Útil para no revelar capacidades sensibles a todo el mundo.
Por dónde empezar
Si quieres experimentar con A2A hoy mismo, el camino más directo depende de tu stack. Para Python con Semantic Kernel, el repositorio oficial de muestras de A2A tiene un ejemplo de travel planner que levanta en local sin necesidad de infraestructura Azure. Para .NET, el SDK está en GitHub y el artículo del Microsoft Foundry Blog tiene un tutorial paso a paso para construir un agente eco y probarlo con el A2A Inspector.
Ojo con la versión del SDK: está en preview. Antes de meterlo en producción, sigue el repositorio en GitHub para estar al tanto de los cambios de API. La especificación del protocolo es estable, pero los SDKs todavía están evolucionando.
Y si trabajas con Copilot Studio, el soporte A2A está llegando — en el momento de publicar este artículo ya estaba en roadmap activo. La dirección que está tomando el ecosistema es clara: los agentes van a ser ciudadanos de primera clase en redes distribuidas, y A2A es el pasaporte.
En definitiva
A2A no es solo otro protocolo de integración. Es la apuesta del sector — con Google, Microsoft y decenas de partners detrás — por hacer que los sistemas multi-agente sean interoperables por defecto, no por accidente. AgentCard para el descubrimiento, JSON-RPC para la comunicación síncrona, SSE para el streaming, ciclo de vida de tareas bien definido, seguridad basada en estándares web. Todo encaja.
Si estás construyendo agentes hoy, vale la pena entender A2A aunque no lo uses todavía. Porque cuando tus agentes necesiten colaborar con los de un partner o los de otro departamento — y ese momento llegará — querrás tener el protocolo claro desde el principio.
Fuentes y recursos
- Especificación oficial A2A (Linux Foundation): https://a2a-protocol.org/latest/
- Repositorio oficial A2A: https://github.com/a2aproject/A2A
- SDK .NET A2A: https://github.com/a2aproject/a2a-dotnet
- Blog Microsoft Cloud — anuncio A2A (7 mayo 2025): https://www.microsoft.com/en-us/microsoft-cloud/blog/2025/05/07/empowering-multi-agent-apps-with-the-open-agent2agent-a2a-protocol/
- Microsoft Foundry Blog — Semantic Kernel + A2A: https://devblogs.microsoft.com/foundry/semantic-kernel-a2a-integration/
- Microsoft Foundry Blog — A2A .NET SDK: https://devblogs.microsoft.com/foundry/building-ai-agents-a2a-dotnet-sdk/
- Azure Blog — Agent Factory (MCP + A2A): https://azure.microsoft.com/en-us/blog/agent-factory-connecting-agents-apps-and-data-with-new-open-standards-like-mcp-and-a2a/