MCP vs A2A vs UCP vs AP2 vs A2UI: Lo stack di protocolli degli agenti spiegato

I protocolli per agenti IA si stanno moltiplicando rapidamente: MCP, A2A, UCP, AP2, A2UI e gli standard correlati compaiono sempre più spesso negli stessi diagrammi di architettura. Vengono spesso descritti come protocolli concorrenti. In pratica, la maggior parte di essi risolve problemi di interoperabilità diversi su confini differenti. La domanda utile non è "Quale protocollo vincerà?", ma "Quale relazione nel sistema deve essere standardizzata?"

L'errore fondamentale: confrontare protocolli che operano su confini diversi

Un protocollo è utile perché due sistemi implementati in modo indipendente hanno bisogno di un contratto stabile. Il contratto ha senso solo se il confine è chiaro. Un agente che comunica con un database presenta un problema di interoperabilità diverso rispetto a un agente che delega il lavoro a un altro, a un acquirente che autorizza un acquisto o a un agente remoto che chiede a un'applicazione nativa di eseguire il rendering di un modulo.

La guida per sviluppatori di Google del 2026 presenta esplicitamente MCP, A2A, UCP, AP2, A2UI e i protocolli UI correlati come uno stack di standard complementari. Lo stesso flusso di lavoro di esempio può utilizzarne diversi insieme: strumenti per l'inventario, agenti remoti per i fornitori, commercio per gli ordini, autorizzazione al pagamento per la spesa e protocolli UI per l'interazione.

Il Protocol Responsibility Stack

1. MCP: connettere l'agente alle funzionalità

Il Model Context Protocol è uno standard aperto per connettere le applicazioni IA a sistemi esterni in cui risiedono strumenti, dati e risorse riutilizzabili. Un server espone le funzionalità; un host MCP si connette a tale server e rende tali funzionalità accessibili al modello o all'applicazione.

L'attuale documentazione di MCP TypeScript v2 descrive il protocollo esattamente in questi termini: i server espongono strumenti, risorse e prompt, mentre host come ambienti di sviluppo o applicazioni personalizzate si connettono ad essi. Ciò rende MCP principalmente un protocollo di integrazione delle funzionalità.

Quando usare MCP

• Un'applicazione IA necessita di un accesso standardizzato a strumenti o API.
• Si desidera che un unico server di funzionalità funzioni con molteplici host IA compatibili.
• È richiesto un accesso strutturato a dati o risorse senza dover codificare ogni singola integrazione all'interno di ciascun agente.
• Il sistema esterno è un fornitore di funzionalità, non un agente autonomo equivalente (peer).

2. A2A: connettere agenti indipendenti

Agent2Agent (A2A) è progettato per la comunicazione tra sistemi di agenti indipendenti e potenzialmente opachi. La sua attuale specifica v1.0 si concentra su capability discovery, messaggistica, task, artefatti, contenuti multimodali e collaborazione a lungo termine senza richiedere che un agente esponga i propri strumenti interni, la memoria o l'implementazione a un altro.

Quell'opacità costituisce il confine fondamentale. L'agente chiamante non ha bisogno di sapere se l'agente remoto utilizzi internamente MCP, strumenti personalizzati, un planner proprietario, il modello di un altro fornitore o l'escalation umana. Ha solo bisogno di un contratto per scoprire le funzionalità e delegare il lavoro.

A2A v1.0 standardizza inoltre la negoziazione delle versioni e supporta molteplici binding attorno a un modello di dati comune. Il suo meccanismo pubblicato di Agent Card offre ai client un punto di discovery standard per le funzionalità, i protocolli supportati, i requisiti di autenticazione e le competenze di un agente.

Usa A2A quando

• Un agente autonomo deve delegare del lavoro a un altro agente autonomo.
• Il sistema remoto deve rimanere opaco dietro un contratto di funzionalità.
• I task possono essere a esecuzione prolungata, asincroni o richiedere un'interazione human-in-the-loop.
• Gli agenti sono realizzati con framework, linguaggi, fornitori o proprietà organizzative differenti.

MCP vs A2A: integrazione verticale vs collaborazione orizzontale

Lo stesso progetto A2A descrive ora la distinzione come orizzontale rispetto a verticale: MCP connette gli agenti a strumenti interni e database, mentre A2A abilita la collaborazione peer-to-peer tra sistemi di agenti.

3. UCP: standardizzare il commercio basato su agenti

L'Universal Commerce Protocol non è un protocollo generico per agenti. Standardizza i percorsi commerciali tra interfacce consumer, esercenti e fornitori di pagamento. L'implementazione di Google supporta già funzionalità come la creazione del carrello, il checkout, l'evasione e il ciclo di vita degli ordini tramite profili e API con controllo delle versioni.

Un esercente può pubblicare un profilo UCP sotto /.well-known/ucp descrivendo servizi, versioni del protocollo e funzionalità. Questo modello di discovery è importante perché una superficie agentica non dovrebbe aver bisogno di un contratto di checkout su misura per ogni esercente.

UCP è inoltre intenzionalmente componibile. La panoramica tecnica di Google afferma che può integrarsi tramite API, A2A e MCP ed è compatibile con AP2 per l'autorizzazione dei pagamenti agentici.

Usa UCP quando

• Il flusso di lavoro coinvolge prodotti degli esercenti, carrelli, checkout, evasione o ciclo di vita dell'ordine.
• Stai creando una superficie per esercenti che deve funzionare con esperienze di acquisto agentiche.
• L'integrazione necessita di una semantica specifica per il commercio piuttosto che di chiamate a strumenti generici.
• Desideri un contratto commerciale interoperabile in grado di coesistere con MCP, A2A e protocolli di pagamento.

4. AP2: dimostrare che l'agente era autorizzato a spendere

Il commercio agentico introduce un problema che i flussi di checkout ordinari non dovevano risolvere allo stesso modo: un agente può eseguire transazioni senza che l'essere umano prema il pulsante finale in tempo reale. L'Agent Payments Protocol (AP2) gestisce autorizzazione, autenticità e responsabilità per i pagamenti guidati da agenti.

La guida al protocollo 2026 di Google descrive AP2 attraverso mandati tipizzati che acquisiscono l'intento dell'utente, i vincoli di spesa e la specifica transazione in corso di autorizzazione. AP2 può operare come estensione insieme a UCP: UCP descrive la transazione commerciale, mentre AP2 fornisce la prova che l'agente aveva l'autorità per eseguire il pagamento.

Questa distinzione è importante. Un protocollo di checkout può indicare a un esercente cosa acquistare. Di per sé non dimostra chi ha autorizzato l'agente a spendere, entro quale limite, per quale esercente, per quanto tempo, o se il carrello finale sia rimasto nei limiti di tale autorizzazione.

UCP vs AP2: semantica delle transazioni vs autorità

5. A2UI: consentire agli agenti di descrivere le interfacce senza possedere il tuo frontend

L'interfaccia Agent-to-User (A2UI) affronta un altro confine: il modo in cui un agente remoto o locale comunica un'interfaccia interattiva avanzata a un'applicazione host. Invece di inviare HTML, CSS e JavaScript arbitrari, A2UI utilizza dati dichiarativi che l'host renderizza tramite il proprio catalogo di componenti fidati.

Ciò preserva il design system e il modello di sicurezza dell'applicazione host, consentendo comunque a un agente di richiedere interfacce dinamiche. A2UI v0.9 pone particolare enfasi sull'intento di interfaccia utente indipendente dal framework e sugli aggiornamenti in streaming su web, mobile e altri client.

Il successivo lavoro di Google su A2UI + MCP Apps dimostra inoltre che questi modelli di interfaccia utente non sono necessariamente mutuamente esclusivi. L'interfaccia utente nativa dichiarativa e le esperienze applicative integrate più ricche possono coesistere a seconda dell'attività.

Usa A2UI quando

• Un agente remoto deve richiedere moduli, schede, controlli o altra interfaccia utente interattiva.
• L'host deve preservare i propri componenti nativi, lo stile e il perimetro di sicurezza.
• Non desideri che gli agenti remoti distribuiscano codice frontend eseguibile arbitrario.
• Lo stesso intento di interfaccia utente definito dall'agente deve funzionare su diversi framework client.

Il test di selezione del protocollo

Non partire dall'acronimo. Parti dalla relazione che necessita di interoperabilità.

Un flusso di lavoro multi-protocollo realistico

Perché è improbabile che un unico protocollo universale per agenti li sostituisca tutti

Un protocollo universale sembra più semplice finché non deve codificare la semantica di ogni dominio. La scoperta degli strumenti, la collaborazione tra agenti di lunga durata, il checkout, l'autorizzazione dei pagamenti e l'interfaccia utente nativa hanno tutti requisiti diversi di ciclo di vita, sicurezza e correttezza.

Il web stesso si è evoluto attraverso protocolli a livelli piuttosto che con un unico formato di messaggio per ogni problema. Lo stack agentico emergente sembra muoversi nella stessa direzione: primitive orizzontali comuni, contratti di dominio specializzati e individuazione/gestione delle versioni esplicita.

La sfida architetturale si sposta quindi da "quale protocollo vincerà?" a quanto efficacemente i protocolli si compongano senza duplicare la semantica di identità, autorizzazione, stato e audit.

La composizione dei protocolli crea nuove modalità di errore

La scelta del protocollo non sostituisce l'architettura applicativa

Gli standard aperti riducono l'accoppiamento nell'integrazione, ma non definiscono il modello di dominio, la policy di autorizzazione, la fonte di verità, la strategia di retry o i criteri di accettazione. Uno strumento MCP può comunque esporre la funzionalità sbagliata. Un agente A2A può comunque restituire un artefatto errato. Un checkout UCP può comunque contenere dati obsoleti del venditore. Un mandato AP2 può comunque essere applicato in modo errato dalla logica applicativa.

Tratta i protocolli come contratti tra componenti che si evolvono in modo indipendente. Mantieni la verità di dominio e le relative policy nel livello applicativo a cui appartengono, quindi usa i protocolli per rendere interoperabili i confini.

Cosa potrebbe cambiare questa risposta?

Lo stack cambia se i protocolli convergono, se uno standard ne assorbe formalmente un altro o se i vendor standardizzano un livello condiviso di identità e autorizzazione attraverso più confini. UCP dimostra già la composizione supportando API, A2A e MCP e integrandovisi insieme ad AP2 anziché sostituirli.

La risposta cambia anche in base all'ambito applicativo. Un piccolo agente interno potrebbe richiedere solo MCP. Un flusso di lavoro multi-aziendale potrebbe richiedere A2A. Un esercente potrebbe aver bisogno di UCP senza A2UI. Un agente di acquisto delegato potrebbe richiederli tutti. Utilizza il set di protocolli più ridotto possibile che rappresenti i confini reali senza appiattire la semantica di dominio.

Limitazioni

I protocolli discussi in questa sede si trovano a livelli di maturità differenti e presentano diversi modelli di governance. A2A ha raggiunto una specifica v1.0 stabile, mentre altri standard continuano a evolversi rapidamente. Anche l'adozione nell'ecosistema è disomogenea tra fornitori e framework.

Questo articolo si concentra sulla responsabilità architetturale piuttosto che sulla completezza dell'implementazione. Metodi di autenticazione specifici, binding di trasporto, schemi e meccanismi di estensione devono essere ricavati dalle specifiche attuali di ciascun protocollo.

Conclusione

MCP, A2A, UCP, AP2 e A2UI assumono più senso se visti come protocolli per relazioni diverse, piuttosto che come cinque tentativi concorrenti di standardizzare gli “agenti”.

MCP espone le funzionalità. A2A coordina agenti indipendenti. UCP fornisce al commercio un proprio contratto leggibile dalle macchine. AP2 aggiunge un'autorità di pagamento verificabile. A2UI offre agli agenti un percorso dichiarativo sicuro verso le interfacce utente. Il web agentico emergente non sta quindi sostituendo i protocolli con l'IA; sta creando un nuovo stack di protocolli attorno all'IA.

FAQ

Glossario

Fonti primarie e approfondimenti