Nel 2026, chi sviluppa agenti AI si trova inevitabilmente a fare i conti con tre acronimi: MCP, A2A e AG-UI. La domanda più comune è: sono standard in competizione tra loro? Devo usarli tutti e tre? Quale mi serve davvero?
La risposta breve è che non competono affatto — si completano. Ciascuno risolve un problema diverso a un livello diverso dell’architettura degli agenti. Un’analogia utile: pensateli come TCP, HTTP e HTML nel web — protocolli che operano a strati diversi e insieme rendono possibile il funzionamento del sistema.
Il quadro d’insieme
Prima di entrare nel dettaglio, ecco una tabella riassuntiva:
| Protocollo | Creato da | Connette | Risponde alla domanda |
|---|---|---|---|
| MCP | Anthropic | Agente ↔ Strumenti e dati | “Come fa il mio agente a usare i tool?” |
| A2A | Google / Linux Foundation | Agente ↔ Agente | “Come parlano gli agenti tra di loro?” |
| AG-UI | CopilotKit | Agente ↔ Interfaccia utente | “Come comunica il mio agente con l’utente?” |
MCP — Il layer degli strumenti
Il problema che risolve
Il vostro agente deve fare cose concrete: interrogare un database, chiamare un’API, leggere un file, cercare sul web. Prima di MCP, ogni integrazione era custom: codice ad hoc per ogni strumento, ogni framework, ogni modello. MCP standardizza tutto questo in un unico protocollo.
Come funziona
MCP usa un’architettura client-server basata su JSON-RPC 2.0. Il server MCP espone:
- Tools: funzioni che il modello può invocare, con nome, descrizione e schema tipizzato degli input
- Resources: dati in sola lettura che l’agente può consultare (schemi DB, file di configurazione)
- Prompts: template riutilizzabili
Il client MCP — tipicamente integrato nel framework dell’agente — scopre queste capacità e le invoca per conto del modello. I transport sono flessibili: stdio per tool locali (subprocess), Streamable HTTP per deployment remoti in produzione.
Quando usarlo
Usate MCP ogni volta che il vostro agente deve interagire con sistemi esterni: database, API REST, file system, servizi cloud. Se state wrappando un’API esistente per renderla accessibile agli agenti, MCP è il protocollo giusto. L’ecosistema è già maturo: AWS fornisce server MCP open source per S3, DynamoDB, CloudWatch; sono disponibili server per GitHub, Slack, PostgreSQL e decine di altri servizi.
Quando NON usarlo
MCP non è pensato per la comunicazione tra agenti, né per aggiornare interfacce utente. Se avete un agente che deve delegare sotto-task a un altro agente specializzato, quello è territorio di A2A.
A2A — Il layer di collaborazione tra agenti
Il problema che risolve
Avete costruito più agenti specializzati: uno per la ricerca, uno per la generazione di codice, uno per la gestione dei deployment. Come farli collaborare su task complessi senza condividere stato interno, tool o prompt? A2A standardizza come gli agenti si scoprono, delegano task e si scambiano risultati.
Come funziona
A2A usa un modello client-server su HTTP con JSON-RPC 2.0 (e opzionalmente gRPC dalla v0.3). Il principio chiave è l’opacità: gli agenti non espongono i propri internals, pubblicizzano solo ciò che sanno fare.
I concetti fondamentali:
- Agent Cards: documenti JSON ospitati su
/.well-known/agent.jsonche descrivono nome, capacità (“skills”), tipi di input/output supportati e requisiti di autenticazione. Un biglietto da visita machine-readable. - Tasks: l’unità di lavoro. Un client invia un messaggio al remote agent, che crea un task con lifecycle:
submitted → working → completed(ofailed,canceled). - Interaction patterns: sincrono per task semplici, SSE (Server-Sent Events) per streaming su task lunghi, webhook per workflow veramente asincroni.
Quando usarlo
A2A brilla nei sistemi multi-agente dove gli agenti non devono condividere stato interno. Pattern comuni:
- Un agente supervisor che delega a specialisti
- Collaborazione cross-organizzazione (il vostro agente che interagisce con quello del vendor)
- Setup multi-framework: un agente LangGraph che coordina un agente CrewAI — grazie all’opacità, non importa cosa c’è “dentro”
Quando NON usarlo
Per agenti singoli che devono solo chiamare tool, A2A aggiunge overhead non necessario. Se avete bisogno di accoppiamento stretto tra agenti (condivisione di memoria o stato), A2A non è lo strumento giusto.
AG-UI — Il layer dell’interfaccia utente
Il problema che risolve
I vostri agenti hanno bisogno di comunicare con gli utenti in tempo reale: messaggi incrementali, aggiornamenti di stato, handoff per l’approvazione umana. Prima di AG-UI, ogni team implementava questo in modo proprietario — WebSocket custom, polling, SSE artigianali.
Come funziona
AG-UI è un protocollo a eventi strutturati che collega il backend dell’agente con il frontend. Definisce un insieme standard di eventi (message chunks, tool calls, state updates, human-in-the-loop requests) che qualsiasi UI può consumare. È leggero — basato su SSE — e disaccoppiato dal framework dell’agente.
Quando usarlo
Ogni volta che il vostro agente ha una UI interattiva: chatbot, assistenti embedded, dashboard con feedback in tempo reale. Se invece l’agente è un job in background senza interazione utente (elaborazione batch, task schedulati), AG-UI aggiunge complessità inutile.
Come si combinano in pratica
Lo stack completo per un sistema agente enterprise tipico appare così:
┌─────────────────────────────────────┐
│ Interfaccia Utente │
│ (React, Vue, ecc.) │
└─────────────┬───────────────────────┘
│ AG-UI (SSE events)
┌─────────────▼───────────────────────┐
│ Agente Principale │
│ (LangGraph / CrewAI / custom) │
│ │
│ ┌──────────┐ ┌───────────────┐ │
│ │ MCP │ │ A2A │ │
│ │ (tools) │ │ (subagenti) │ │
│ └──────────┘ └───────────────┘ │
└─────────────────────────────────────┘
│ │
DB, API, File Agenti Specializzati
Un agente principale riceve l’input dell’utente via AG-UI, chiama tool esterni tramite MCP (database, API), e se il task è complesso delega a sotto-agenti specializzati tramite A2A — che a loro volta possono usare MCP per i propri tool.
Lo stato dell’ecosistema nel 2026
MCP ha vinto il layer dei tool: è supportato da praticamente tutti i framework principali (LangChain, LlamaIndex, AutoGen, Semantic Kernel) e ha un ecosistema di centinaia di server pre-costruiti. A2A sta emergendo come standard per il layer di coordinamento e la Linux Foundation ne gestisce ora la governance insieme a MCP. AG-UI è più giovane ma sta guadagnando terreno rapidamente grazie all’integrazione con CopilotKit e framework React.
La combinazione dei tre è sempre più considerata il baseline atteso per deployment agente enterprise — come HTTP, TLS e OAuth sono diventati il baseline per i servizi web.
Conclusione
Se state iniziando a costruire agenti AI, ecco un percorso pragmatico:
- Iniziate con MCP — è maturo, ha un ecosistema enorme e copre la maggior parte dei casi d’uso con un singolo agente
- Aggiungete A2A quando avete più agenti specializzati che devono collaborare
- Integrate AG-UI solo se l’agente ha una UI interattiva che richiede aggiornamenti in tempo reale
La buona notizia è che questi protocolli sono progettati per coesistere: adottarli incrementalmente è la strategia giusta.
Fonte originale: The Agent Protocol Stack: MCP vs. A2A vs. AG-UI (DZone) — approfondito con ulteriori riferimenti da Dev.to e subhadipmitra.com.