A2A y Microsoft Agent Framework en .NET: agentes que hablan entre sí sin casarte con un stack
Cuando hablamos de agentes de IA, normalmente pensamos en prompts, herramientas, memoria, function calling o MCP.
Pero hay otro problema que empieza a aparecer cuando el sistema deja de ser una demo: ¿cómo se comunican agentes creados por equipos distintos, en lenguajes distintos o incluso en plataformas distintas?
Ahí entra A2A, o Agent2Agent.
No lo veo como “otro protocolo de moda”. Lo veo más como una señal de madurez del ecosistema. Si los agentes van a salir del experimento local y van a convivir en empresas reales, necesitan algo más que llamadas HTTP improvisadas entre servicios.
Y aquí es donde, para mí, cambia la conversación. Ya no estamos hablando del demo bonito donde todo corre en el mismo Program.cs. Estamos hablando de sistemas donde hay equipos, permisos, despliegues, contratos, versionado y dependencias que no controlas completamente.
Qué es A2A en pocas palabras
A2A es un protocolo abierto para que un agente pueda hablar con otro agente.
La idea no es obligarte a usar la misma librería en todos lados. Es más bien lo contrario: que un agente en .NET pueda comunicarse con otro hecho en Python, con otro framework o con una plataforma externa, siempre que ambos respeten el mismo contrato.
La forma más simple de verlo es esta:
- un agente publica una especie de carta de presentación
- otro agente lee esa carta
- entiende qué capacidades hay disponibles
- sabe a qué URL llamar
- y conversa usando un formato conocido
Esa carta se llama Agent Card.
No es una metáfora perfecta, pero ayuda: la Agent Card es como cuando un servicio te dice “esto hago, aquí estoy, esta es mi versión, estas son mis capacidades y así puedes hablar conmigo”.
Después de eso vienen los mensajes, las tareas y el streaming. Pero la idea base es bastante humana: presentarse bien para que otro sistema pueda colaborar contigo sin tener que adivinar cómo funcionas.
Por qué esto sí tiene sentido
En una empresa real no todo vive en el mismo proceso, ni en el mismo repositorio, ni bajo el mismo equipo.
Un agente de soporte puede necesitar consultar a un agente de facturación. Un agente interno puede delegar validaciones a un agente de compliance. Un agente construido en .NET puede tener que hablar con un agente especializado que otro equipo ya resolvió en Python.
Sin un estándar, cada integración se vuelve una negociación distinta:
- endpoint custom
- payload custom
- autenticación custom
- manejo de errores custom
- streaming custom
- versión custom
Y ya sabemos cómo termina eso: integraciones frágiles, difíciles de probar y llenas de “esto solo funciona si lo llamas exactamente así”.
A2A intenta poner orden en esa parte. No reemplaza la arquitectura. No reemplaza la seguridad. No reemplaza el criterio técnico. Pero sí reduce el pegamento artesanal cuando el problema real es conectar agentes entre fronteras.
Por eso me gusta explicarlo con una imagen mental sencilla: A2A no es “el cerebro” del sistema. Es más bien el idioma común y la tarjeta de presentación para que los agentes puedan encontrarse y colaborar.
A2A no es MCP
Aquí conviene separar conceptos.
MCP se enfoca en cómo un modelo o agente usa herramientas, datos o recursos externos. Por ejemplo: acceder a archivos, consultar una base de datos, llamar una API o usar una herramienta concreta.
A2A se enfoca en cómo un agente habla con otro agente.
La diferencia parece pequeña, pero arquitectónicamente no lo es.
MCP responde mejor a esta pregunta:
¿Cómo le doy herramientas a mi agente?
A2A responde mejor a esta otra:
¿Cómo hago que mi agente delegue trabajo a otro agente remoto?
Se complementan. No son bandos.
Y para mí ese detalle es importante porque evita una confusión que ya se está volviendo común: querer meter todos los problemas de agentes dentro de un solo protocolo.
Dónde entra Microsoft Agent Framework
Aquí es donde .NET empieza a ponerse interesante.
Microsoft Agent Framework ya venía empujando una idea que me gusta: tratar los agentes como sistemas de software, no como scripts con prompts.
Con A2A, el framework facilita dos caminos:
- Consumir un agente remoto A2A como si fuera un
AIAgent. - Exponer un agente .NET existente como endpoint A2A.
Eso es lo valioso.
No tienes que reescribir toda tu aplicación para “soportar A2A”. El framework intenta que el agente remoto se sienta como una abstracción normal dentro de tu código .NET.
Si tuviera que resumirlo visualmente, lo pensaría así: un agente publica su tarjeta, otro agente la lee y a partir de ahí recién empieza la conversación o la delegación.
Consumir un agente A2A desde .NET
Supongamos que tienes un agente remoto publicado con A2A. Puede estar hecho en .NET, Python o cualquier tecnología que implemente el protocolo.
Desde .NET, el flujo básico es descubrir su Agent Card y envolverlo como un AIAgent.
Primero instalas el paquete del cliente A2A:
dotnet add package Microsoft.Agents.AI.A2A --prereleaseusing A2A;using Microsoft.Agents.AI;
A2ACardResolver resolver = new(new Uri("https://agente-remoto.ejemplo.com"));
AIAgent agente = await resolver.GetAIAgentAsync();
AgentResponse respuesta = await agente.RunAsync( "Revisa si esta solicitud cumple con las reglas internas de compliance.");
Console.WriteLine(respuesta.Text);La parte interesante no es que el código sea corto. Eso siempre se puede maquillar en un ejemplo.
Lo interesante es el modelo mental: el agente remoto entra en tu aplicación como una pieza consumible, no como una integración inventada desde cero.
También puedes usar streaming cuando el trabajo necesita ir entregando avances:
await foreach (AgentResponseUpdate update in agente.RunStreamingAsync( "Genera un análisis técnico de este documento.")){ if (!string.IsNullOrWhiteSpace(update.Text)) { Console.Write(update.Text); }}Eso abre escenarios más reales: procesamiento de documentos, análisis largos, revisión de casos, tareas internas y flujos donde no quieres bloquear al usuario sin feedback.
Exponer tu agente .NET como A2A
El otro lado también importa.
Si ya tienes un agente creado con Microsoft Agent Framework, puedes publicarlo para que otros sistemas lo llamen usando A2A.
Para ASP.NET Core, el paquete que habilita el hosting A2A es este:
dotnet add package Microsoft.Agents.AI.Hosting.A2A.AspNetCore --prereleaseEste ejemplo está simplificado, pero muestra la idea:
using A2A.AspNetCore;using Microsoft.Agents.AI;using Microsoft.Agents.AI.Hosting;using Microsoft.Extensions.AI;
var builder = WebApplication.CreateBuilder(args);
IChatClient chatClient = CrearChatClient(builder.Configuration);builder.Services.AddSingleton(chatClient);
var agente = builder.AddAIAgent( name: "compliance-review", instructions: """ Eres un agente de revisión de compliance. Evalúa solicitudes internas y responde con riesgos, observaciones y recomendación. """);
var app = builder.Build();
app.MapA2A(agente, path: "/a2a/compliance", agentCard: new(){ Name = "Compliance Review Agent", Description = "Revisa solicitudes internas y devuelve riesgos de compliance.", Version = "1.0"});
app.Run();
static IChatClient CrearChatClient(IConfiguration configuration){ // En producción aquí configuras Azure OpenAI, Microsoft Foundry, // OpenAI u otro proveedor compatible con Microsoft.Extensions.AI. throw new NotImplementedException();}El punto no es copiar y pegar esto tal cual en producción. El punto es ver la dirección: tu agente .NET puede quedar disponible como un servicio interoperable, con una tarjeta de descubrimiento y un contrato estándar.
Desde ahí ya entran las decisiones serias:
- autenticación
- autorización
- rate limiting
- observabilidad
- versionado
- timeouts
- manejo de errores
- contratos de entrada y salida
Porque A2A estandariza la comunicación, pero no te exime de diseñar bien el sistema.
La documentación oficial de Microsoft muestra este mismo enfoque con MapA2A: registras el agente, defines el agentCard y expones un endpoint A2A desde ASP.NET Core. También muestra que puedes consultar la tarjeta del agente y llamar al endpoint usando el formato de mensajes del protocolo.
Cuándo usar A2A y cuándo no
Aquí es donde hay que bajar un poco el entusiasmo.
Yo usaría A2A cuando hay una frontera real:
- otro equipo mantiene el agente
- el agente vive en otro servicio
- necesitas interoperar con otra tecnología
- hay agentes de terceros
- necesitas descubrir capacidades sin acoplarte al código interno
Pero si todos tus agentes viven en la misma aplicación, mismo equipo, mismo despliegue y mismo proceso, probablemente agents as tools o una composición local sea más simple.
No todo necesita A2A.
Meter un protocolo distribuido donde no hay frontera real solo añade latencia, fallos de red, versionado y complejidad operativa.
Y esto es importante decirlo porque con IA se está repitiendo un patrón que ya vimos con microservicios: agarrar una solución pensada para fronteras reales y meterla en cualquier sitio porque suena más avanzado.
Cuando ya cruzas esa frontera, ahí sí cambia la historia. En ese punto A2A deja de ser una curiosidad y empieza a parecerse más a una pieza de integración: no porque haga el sistema simple, sino porque evita que cada equipo invente su propio protocolo para lo mismo.
Mi lectura como desarrollador .NET
Para mí, la relevancia de A2A en .NET no está en escribir “mi primer agente que habla con otro agente”.
Eso es la demo.
La relevancia está en que Microsoft Agent Framework empieza a darle al ecosistema .NET una forma razonable de integrarse en sistemas multiagente sin quedarse encerrado en un stack.
Y eso importa para nosotros como desarrolladores backend.
Porque el valor profesional no va a estar en decir “sé crear un chatbot”. Eso ya se está comoditizando.
El valor va a estar en saber diseñar sistemas donde agentes, herramientas, workflows, permisos, auditoría y servicios reales convivan sin volverse una caja negra imposible de mantener.
A2A no resuelve todo eso.
Pero sí resuelve una parte muy concreta: cómo hacer que los agentes se entiendan cuando cruzan fronteras.
Y Microsoft Agent Framework lo vuelve mucho más natural para quienes trabajamos con .NET.
Por eso creo que vale la pena mirarlo desde ya. No para meterlo en todos los proyectos, sino para tenerlo en la cabeza cuando el problema deje de ser “tengo un agente” y pase a ser “tengo varios agentes que necesitan colaborar sin depender todos del mismo stack”.
Ahí A2A empieza a tener sentido.
Si quieres seguir aprendiendo sobre estos temas te invito a ver mis otras publicaciones.
Referencias
- A2A Protocol Specification
- Agent-to-Agent en Microsoft Agent Framework
- A2A Agent en Microsoft Agent Framework
- A2A Integration en Microsoft Agent Framework para C#
- A2A v1 en Microsoft Agent Framework para .NET
