Con il rilascio dell’A2A Protocol v1.0 e il relativo supporto nel Microsoft Agent Framework per .NET, il mondo degli agenti AI multi-vendor fa un passo importante verso la maturità. Non si tratta solo di un aggiornamento di versione: A2A v1 è il primo standard stabile e production-ready per la comunicazione tra agenti intelligenti, indipendentemente dal framework o dal provider che li ospita.
Il problema: isole di agenti incompatibili
Chi sviluppa sistemi multi-agente in ambienti aziendali lo sa bene: ogni team usa il proprio framework, ogni divisione ha i propri provider AI, e ogni volta che due agenti devono comunicare si finisce a scrivere codice di integrazione su misura. Il costo di questo «collante» cresce più in fretta del valore che gli agenti stessi producono.
Il protocollo A2A nasce esattamente per eliminare questa frizione. L’analogia è quella di HTTP e REST per i servizi web: prima di avere standard condivisi, ogni integrazione richiedeva codice proprietario. Dopo, è diventato possibile comporre servizi indipendentemente dal linguaggio o dalla piattaforma sottostante. A2A vuole fare la stessa cosa per gli agenti AI.
Chi c’è dietro A2A v1
Il protocollo è governato da un comitato tecnico con rappresentanti di AWS, Cisco, Google, IBM Research, Microsoft, Salesforce, SAP e ServiceNow. Non è un progetto Microsoft-only, ma uno standard aperto con ampio supporto industriale. La versione 1.0 segnala che il protocollo è maturo: i contorni aspri delle bozze precedenti sono stati levigati, le aree ambigue chiarite, e la superficie API è stata progettata per la durabilità nel tempo.
Novità di A2A v1 rispetto alla v0.3
Per chi veniva dalla versione precedente (v0.3), ecco cosa cambia:
- Stabilità e supporto a lungo termine: v1.0 è la prima versione con garanzie di compatibilità stabile. L’investimento nel codice scritto oggi sarà protetto.
- Funzionalità enterprise: supporto multi-tenancy, Agent Card firmate crittograficamente per la verifica dell’identità degli agenti, e flussi di sicurezza migliorati per ambienti regolamentati e multi-parte.
- Architettura web-aligned: A2A v1 si appoggia su protocolli e pattern già consolidati nell’infrastruttura web. È possibile scalare le interazioni tra agenti usando gli stessi load balancer, gateway e strumenti di observability già in uso per i servizi HTTP.
Come funziona nel Microsoft Agent Framework per .NET
La filosofia di design del framework è che l’interoperabilità non deve richiedere una ristrutturazione del codice. Un agente remoto A2A appare nel codice esattamente come qualsiasi altro AIAgent locale: stessa interfaccia RunAsync, stesso streaming, stessa gestione della sessione.
Connettere un agente remoto A2A via discovery automatica
Il protocollo A2A definisce un percorso standard per la discovery degli agenti: /.well-known/agent-card.json. Con A2ACardResolver è possibile scoprire e istanziare un agente remoto in una sola chiamata:
using A2A;
using Microsoft.Agents.AI;
// Punta il resolver all'host dell'agente remoto
A2ACardResolver resolver = new(new Uri("https://a2a-agent.example.com"));
// Risolve l'Agent Card e crea un AIAgent in un solo passaggio
AIAgent agent = await resolver.GetAIAgentAsync();
// Usalo come qualsiasi altro AIAgent
Console.WriteLine(await agent.RunAsync("Qual è il meteo a Milano?"));Configurazione diretta (per ambienti di sviluppo)
In scenari di sviluppo o sistemi strettamente accoppiati dove l’endpoint è già noto, si può creare un A2AClient direttamente:
using A2A;
using Microsoft.Agents.AI;
A2AClient a2aClient = new(new Uri("https://a2a-agent.example.com"));
AIAgent agent = a2aClient.AsAIAgent(
name: "my-agent",
description: "Un assistente specializzato.");
Console.WriteLine(await agent.RunAsync("Di cosa ti occupi?"));Selezione del protocollo di trasporto
A2A v1 supporta più binding di protocollo. Per default, il framework preferisce HTTP+JSON con JSON-RPC come fallback. È possibile specificarlo esplicitamente:
A2ACardResolver resolver = new(new Uri("https://a2a-agent.example.com"));
A2AClientOptions options = new()
{
PreferredBindings = [ProtocolBindingNames.HttpJson]
};
AIAgent agent = await resolver.GetAIAgentAsync(options: options);Streaming in tempo reale
A2A supporta lo streaming via Server-Sent Events. RunStreamingAsync permette di ricevere aggiornamenti in tempo reale mentre l’agente elabora la risposta — particolarmente utile per task lunghi o per mostrare progressi all’utente:
await foreach (var update in agent.RunStreamingAsync("Analizza questo documento..."))
{
Console.Write(update.Text);
}Esporre il proprio agente come endpoint A2A
Il meccanismo funziona anche in senso inverso: qualsiasi AIAgent già costruito — su Microsoft Foundry, Azure OpenAI, OpenAI, Anthropic, AWS Bedrock o qualsiasi altro provider supportato — può essere esposto come endpoint A2A con poche righe di hosting. Nessun boilerplate di protocollo da scrivere, nessun refactoring necessario quando si decide di rendere un agente interno disponibile ad altri team o a partner esterni.
Quando ha senso adottare A2A v1
A2A v1 diventa rilevante non appena si esce dai prototipi mono-agente. I casi d’uso tipici includono:
- Un agente di procurement che deve consultare un servizio di compliance di un partner
- Un agente di customer support che cede il controllo a un agente specializzato di un’altra divisione
- Pipeline di elaborazione dove agenti diversi (analisi, sintesi, verifica) sono costruiti da team differenti
- Ecosistemi ISV dove prodotti di terze parti devono integrarsi con gli agenti della piattaforma principale
Conclusioni
A2A v1 è una tappa importante nell’evoluzione degli agenti AI verso sistemi distribuiti e interoperabili. La scelta di costruirlo come standard aperto con sponsorship industriale ampio — e non come API proprietaria Microsoft — è un segnale di maturità dell’ecosistema. Per i team .NET che stanno costruendo o pianificando sistemi multi-agente, vale la pena investire nella migrazione dalla v0.3 o nell’adozione diretta di v1: la stabilità garantita e le funzionalità enterprise rendono il protocollo adatto alla produzione oggi.
Fonte: A2A v1 Is Here – Microsoft Agent Framework Blog (Sergey Menshykh, Microsoft)