Italiano

A2A vs MCP: Due protocolli complementari per l'ecosistema emergente degli agenti

Questo articolo introduce A2A e MCP — due protocolli emergenti che stanno plasmando il futuro dei sistemi di agenti AI. Spiega come funzionano, in cosa differiscono e perché comprendere questa architettura è importante per sviluppatori, designer e costruttori di prodotti AI.

Guamian

Product & Design

4/11/2025

Smetti di sprecare settimane sull'autenticazione degli utenti

Lancia app sicure più velocemente con Logto. Integra l'autenticazione degli utenti in pochi minuti e concentrati sul tuo prodotto principale.

Inizia ora

L'adozione crescente degli agenti AI — entità software autonome o semi-autonome che svolgono ragionamenti e azioni per conto degli utenti — sta dando origine a un nuovo livello nell'architettura delle applicazioni.

All'inizio del 2025, sono emersi due protocolli distinti per affrontare questo problema — A2A (Agent-to-Agent) e MCP (Model Context Protocol). Un modo semplice per comprendere i loro ruoli è:

A2A: Come gli agenti interagiscono tra loro

MCP: Come gli agenti interagiscono con gli strumenti o il contesto esterno

reference: https://google.github.io/A2A/#/topics/a2a_and_mcp

Affrontano la sfida principale di costruire sistemi con molti agenti, molti LLM e molte fonti di contesto — tutto dovendo collaborare.

Un modo per definirlo è: “MCP fornisce un'integrazione verticale (applicazione-modello), mentre A2A fornisce un'integrazione orizzontale (agente-agente)

Che tu sia uno sviluppatore o meno, chiunque costruisca prodotti AI o sistemi agentici dovrebbe comprendere l'architettura di base — perché modella come progettiamo i prodotti, le interazioni utente, gli ecosistemi e la crescita a lungo termine.

Questo articolo introduce entrambi i protocolli in modo semplice e facile da capire e evidenzia i punti chiave per sviluppatori e costruttori di prodotti AI.

Cos'è A2A (Agent-to-Agent)?

A2A (Agent-to-Agent) è un protocollo aperto sviluppato da Google e oltre 50 partner del settore. Il suo scopo è consentire l'interoperabilità tra agenti — indipendentemente da chi li ha costruiti, dove sono ospitati o quale framework usano.

Meccanismo del protocollo A2A

A2A utilizza JSON-RPC 2.0 su HTTP(S) come meccanismo di comunicazione, con supporto per Server-Sent Events (SSE) per trasmettere aggiornamenti.

Modelli di comunicazione A2A

A2A definisce un modello strutturato per l'interazione di due agenti. Un agente assume il ruolo di agente “client”, che avvia una richiesta o un compito, e un altro agisce come agente “remoto”, che riceve la richiesta e tenta di soddisfarla. L'agente client potrebbe prima eseguire la scoperta delle capacità per determinare quale agente è più adatto per un determinato lavoro.

Ci si chiede quindi come gli agenti si scoprano tra loro. Ogni agente può pubblicare una Carta dell'Agente (un documento di metadati JSON, spesso ospitato a un URL standard come /.well-known/agent.json) descrivendo le sue capacità, competenze, endpoint API e requisiti di autenticazione.

Leggendo una Carta dell'Agente, un agente client può identificare un agente partner adatto per il compito specifico — essenzialmente una directory di ciò che l'agente sa o può fare. Una volta scelto l'agente target, l'agente client formula un oggetto Task da inviare.

reference: https://google.github.io/A2A/#/

Gestione dei task

Tutte le interazioni in A2A sono orientate all'esecuzione dei task. Un task è un oggetto strutturato (definito dallo schema del protocollo) che include i dettagli della richiesta e ne traccia lo stato.

In A2A, ciascun agente ha uno dei due ruoli:

Agente Client: avvia un task
Agente Remoto: riceve ed elabora il task

I task possono includere qualsiasi tipo di lavoro: generare un rapporto, recuperare dati, avviare un flusso di lavoro. I risultati sono restituiti come artefatti e gli agenti possono inviare messaggi strutturati durante l'esecuzione per coordinarsi o chiarire.

Collaborazione e negoziazione dei contenuti

A2A supporta più delle semplici richieste di task — gli agenti possono scambiarsi messaggi ricchi e multi-parte che includono testo, JSON, immagini, video o contenuti interattivi. Ciò abilita la negoziazione del formato in base a ciò che ciascun agente può gestire o visualizzare.

Ad esempio, un agente remoto potrebbe restituire un grafico come dati grezzi o come immagine, o richiedere di aprire un modulo interattivo. Questo design supporta una comunicazione flessibile e modalità-agnostica, senza richiedere agli agenti di condividere strumenti interni o memoria.

Esempio di caso d'uso

Ecco un esempio del mondo reale di come A2A potrebbe essere utilizzato in uno scenario aziendale:

Un nuovo dipendente viene assunto in una grande azienda. Molti sistemi e dipartimenti sono coinvolti nell'onboarding:

L'HR deve creare un record e inviare un'email di benvenuto
L'IT deve fornire un laptop e account aziendali
Il Servizio Centrali deve preparare una scrivania e un badge di accesso

Tradizionalmente, questi passaggi vengono gestiti manualmente o attraverso integrazioni strettamente accoppiate tra sistemi interni.

Invece di API personalizzate tra ogni sistema, ciascun dipartimento espone il proprio agente utilizzando il protocollo A2A:

Agente	Responsabilità
hr-agent.company.com	Creare il record del dipendente, inviare documenti
it-agent.company.com	Creare account email, ordinare laptop
facilities-agent.company.com	Assegnare scrivania, stampare badge di accesso

Un sistema multi-agente — chiamiamolo OnboardingPro (es. onboarding-agent.company.com) — coordina l'intero flusso di lavoro dell'onboarding.

Scoperta: Legge ciascun agente .well-known/agent.json per comprendere capacità e autenticazione.
Delegazione dei task:
- Invia un task createEmployee all'agente HR.
- Invia i task setupEmailAccount e orderHardware all'agente IT.
- Invia assignDesk e generateBadge all'agente Servizio Centrali.
Aggiornamenti in streaming: Gli agenti trasmettono il progresso indietro usando Server-Sent Events (es. “laptop spedito”, “scrivania assegnata”).
Raccolta di artefatti: I risultati finali (es. badge PDF, email di conferma, credenziali dell'account) sono restituiti come artefatti A2A.
Completamento: L'OnboardingPro notifica il responsabile delle assunzioni quando l'onboarding è completato.

Cos'è MCP (Model Context Protocol)?

MCP (Model Context Protocol), sviluppato da Anthropic, affronta un problema diverso: come le applicazioni esterne possano fornire contesto strutturato e strumenti a un agente basato su modello linguistico al runtime.

Piuttosto che abilitare la comunicazione inter-agente, MCP si concentra sulla finestra di contesto — la memoria di lavoro di un LLM. Il suo obiettivo è:

Iniettare dinamicamente strumenti pertinenti, documenti, funzioni API o stato utente in una sessione di inferenza del modello
Lasciare che i modelli chiamino funzioni o recuperino documenti senza bisogno di codificare il prompt o la logica

Architettura chiave di MCP

Per comprendere MCP, devi prima comprendere l'architettura complessiva — come tutte le parti funzionano insieme.

Host MCP: “L'AI con cui stai parlando”

Pensa all'Host MCP come all'app AI stessa — come Claude Desktop o il tuo assistente di codifica.

È l'interfaccia che stai utilizzando — il luogo dove digiti o parli.

Vuole richiamare strumenti e dati che aiutano il modello a fornire risposte migliori.

Cliente MCP: “Il connettore”

Il Cliente MCP è il pezzo di software che connette il tuo host AI (come Claude) al mondo esterno. È come una centralina — gestisce connessioni sicure, uno a uno, con diversi server MCP. Quando l'AI desidera accedere a qualcosa, passa attraverso il cliente.

È utile pensare a strumenti come ChatGPT, Claude chat o Cursor IDE come host MCP — forniscono l'interfaccia con cui interagisci. Dietro le quinte, usano un cliente MCP per connettersi a diversi strumenti e fonti di dati attraverso i server MCP.

refrence: https://modelcontextprotocol.io/introduction

Server MCP: “Il fornitore di strumenti”

Un Server MCP è un piccolo programma focalizzato che espone uno specifico strumento o capacità — come:

Cercare file sul tuo computer
Cercare dati in un database locale
Chiamare un'API esterna (come meteo, finanza, calendario)

Ogni server segue il protocollo MCP, così l'AI può capire cosa può fare e come chiamarlo.

Fonti di dati locali: “I tuoi file e servizi”

Alcuni server MCP si collegano a cose sul tuo stesso dispositivo — come:

Documenti e cartelle
Progetti di codice
Database o app locali

Questo consente all'AI di cercare, recuperare o calcolare cose senza caricare i tuoi dati sul cloud.

Servizi remoti: “API e strumenti online”

Altri server MCP sono collegati a Internet — parlano con:

API (es. Stripe, Notion, GitHub)
Strumenti SaaS
Database aziendali nel cloud

Così l'AI può dire, ad esempio: “Chiama il server GitHub e recupera l'elenco di PR aperti.”

MCP supporta ora la connessione a server MCP remoti. Ciò significa che un cliente MCP può acquisire capacità più potenti. In teoria,

Con il giusto set di server MCP, gli utenti possono trasformare ogni cliente MCP in un “app per tutto”.

reference: https://a16z.com/a-deep-dive-into-mcp-and-the-future-of-ai-tooling/

Mettere tutto insieme

Ora usiamo un diagramma per vedere come tutto funziona insieme.

Chiedi qualcosa di complesso all'AI
L'AI (l'host) chiede al cliente aiuto
Il cliente chiama il giusto server MCP — forse uno che controlla file o accede a un'API
Il server invia indietro dati o esegue una funzione
Il risultato ritorna al modello per aiutarlo a completare il compito

A2A vs MCP — Confronto

Categoria	A2A (Agent-to-Agent)	MCP (Model Context Protocol)
Obiettivo Primario	Abilitare lo scambio di task inter-agente	Permettere agli LLM di accedere a strumenti esterni o contesto
Progettato Per	Comunicazione tra agenti autonomi	Miglioramento delle capacità di un singolo agente durante l'inferenza
Focus	Flussi di lavoro multi-agente, coordinamento, delega	Uso dinamico degli strumenti, aumento del contesto
Modello di Esecuzione	Gli agenti inviano/ricevono task e artefatti	LLM seleziona ed esegue strumenti in linea durante il ragionamento
Sicurezza	OAuth 2.0, chiavi API, ambiti dichiarativi	Gestito al livello dell'integrazione applicativa
Ruolo dello Sviluppatore	Costruire agenti che espongono task e artefatti tramite endpoint	Definire strumenti strutturati e contesto che il modello può usare
Partner dell'Ecosistema	Google, Salesforce, SAP, LangChain, ecc.	Anthropic, con adozione emergente nelle UI LLM basate su strumenti

Come lavorano insieme

Piuttosto che essere alternative, A2A e MCP sono complementari. In molti sistemi, entrambi verranno utilizzati insieme.

Esempio di flusso di lavoro

Un utente invia una richiesta complessa in un'interfaccia di agente aziendale.
L'agente orchestrante utilizza A2A per delegare sottotask ad agenti specializzati (es. analisi, HR, finanza).
Uno di questi agenti usa MCP internamente per invocare una funzione di ricerca, recuperare un documento o calcolare qualcosa usando un modello.
Il risultato è restituito come artefatto tramite A2A, abilitando la collaborazione end-to-end tra agenti con accesso modulare agli strumenti.

Questa architettura separa la comunicazione inter-agente (A2A) dall’invocazione delle capacità intra-agente (MCP) — rendendo il sistema più facile da comporre, scalare e proteggere.

Conclusione

A2A riguarda gli agenti che parlano con altri agenti su una rete — in modo sicuro, asincrono e orientato ai task.

MCP riguarda l'iniezione di capacità strutturate in una sessione di modello, consentendo agli LLM di ragionare su strumenti e dati contestualmente.

Utilizzati insieme, supportano sistemi multi-agente componibili che sono sia estensibili che interoperabili.

Come l'infrastruttura di base MCP + A2A potrebbe plasmare il futuro dei marketplace di prodotti per agenti

Infine, voglio parlare di come questo nucleo tecnico potrebbe plasmare il futuro del marketplace AI — e cosa significa per le persone che costruiscono prodotti AI.

Il cambiamento dell'interazione uomo-computer

Un chiaro esempio di questo cambiamento può essere visto nei flussi di lavoro degli sviluppatori e dei servizi. Con i server MCP ora integrati negli IDE e negli agenti di codifica, il modo in cui gli sviluppatori interagiscono con gli strumenti sta cambiando radicalmente.

In precedenza, un tipico flusso di lavoro prevedeva la ricerca del giusto servizio, l'impostazione dell'hosting, la lettura della documentazione, l'integrazione delle API manualmente, la scrittura del codice nell'IDE e la configurazione delle funzionalità tramite un dashboard low-code. Era un'esperienza frammentata, che richiedeva il cambio di contesto e un sovraccarico tecnico a ogni passo.

Ora, con gli agenti di codifica connessi a MCP, gran parte di quella complessità può essere astratta. Gli sviluppatori possono scoprire e utilizzare strumenti in modo più naturale attraverso prompt conversazionali. L'integrazione delle API sta diventando parte del flusso di codifica stesso — spesso senza la necessità di un'interfaccia utente separata o di impostazioni manuali. (Basta pensare a quanto complesse possono essere le dashboard di AWS o Microsoft). L'interazione diventa più fluida — più sull'orientare il comportamento che assemblare le funzionalità.

In questo modello, l'interazione dell'utente o dello sviluppatore passa da configurare funzionalità a orchestrare comportamenti. Ciò cambia anche il ruolo del design del prodotto.

Invece di usare interfacce utente per “tappare” le sfide tecniche (es. “questo è troppo difficile da codificare, facciamo un pannello di configurazione”), ora dobbiamo:

Pensare all'esperienza end-to-end
Progettare come e quando AI + interazioni utente dovrebbero unirsi
Lasciare che l'AI gestisca la logica e guidare gli utenti attraverso intenti e flussi

La sfida diventa decidere quando e come AI e input dell'utente dovrebbero unirsi, lasciare che l'AI gestisca la logica e guidare gli utenti attraverso intenti e flussi e come inserire le giuste interazioni al momento giusto.

Ho usato un servizio per sviluppatori e un prodotto API come esempio per mostrare come l'interazione con l'utente potrebbe cambiare — ma lo stesso vale per il software aziendale. Per lungo tempo, gli strumenti aziendali sono stati complessi e difficili da usare. L'interazione in linguaggio naturale ha il potenziale per semplificare molti di questi flussi di lavoro.

Paradigmi di prodotti agentici e il loro impatto sul SaaS

Stiamo iniziando a vedere emergere un numero crescente di server MCP. Immagina Airbnb offrire un server MCP di prenotazione, o Google Maps esporre un server MCP di mappe. Un agente (come un cliente MCP) potrebbe connettersi a molti di questi server contemporaneamente — sbloccando flussi di lavoro che fino a ora richiedevano integrazioni personalizzate o app strettamente legate.

Rispetto all'era del SaaS, dove le integrazioni erano spesso manuali e rigide, questo modello abilita flussi di lavoro più autonomi e connessioni fluide tra i servizi. Ecco due esempi:

Progettazione dai documenti

Scrivi un PRD in Notion. Un agente Figma legge il documento e crea automaticamente un wireframe che compone i concetti principali — senza bisogno di trasferimenti manuali.
Ricerca dei concorrenti, end-to-end

Richiedi un'analisi dei concorrenti. Un gruppo di agenti cerca sul web, si iscrive ai servizi pertinenti per tuo conto (con autenticazione sicura), raccoglie i risultati e consegna gli artefatti — già organizzati nel tuo spazio di lavoro Notion.

Sfide con i confini di autenticazione e autorizzazione

Con l'ascesa delle connessioni agente a agente e delle connessioni cliente MCP a server MCP, ci sono molte esigenze sottostanti riguardo l'autenticazione e l'autorizzazione poiché l'agente agirà per conto delle persone e degli utenti e le credenziali devono essere sicure in questo viaggio.

Fino a ora ci sono diversi scenari specifici per la nuova ascesa di agente a agente e MCP.

Agente vs SaaS & Sito WebApp
Cliente MCP (Agente) vs Server MCP
Utente vs Agente
Agente vs Agente

Un altro caso d'uso interessante è la federazione multi-identità che ha menzionato Google:

Ad esempio, l'Utente U sta lavorando con l'Agente A che richiede l'identificatore del sistema A. Se l'Agente A dipende poi dallo Strumento B o dall'Agente B che richiede l'identificatore del sistema B, l'utente potrebbe dover fornire le identità per entrambi i sistemi A e B in una singola richiesta. (Supponiamo che il sistema A sia un'identità LDAP aziendale e il sistema B sia un'identità del fornitore SaaS).

Logto è un fornitore di OIDC e OAuth, ben adattato per il futuro delle integrazioni AI.

Con la sua infrastruttura flessibile, stiamo espandendo attivamente le sue capacità e abbiamo pubblicato una serie di tutorial per aiutare gli sviluppatori a iniziare rapidamente.

Hai domande?

Mettiti in contatto con noi — o immergiti ed esplora cosa puoi costruire con Logto oggi.

Prova Logto Cloud gratuitamente

Cos'è A2A (Agent-to-Agent)?#

Meccanismo del protocollo A2A#

Modelli di comunicazione A2A#

Gestione dei task#

Collaborazione e negoziazione dei contenuti#

Esempio di caso d'uso#

Cos'è MCP (Model Context Protocol)?#

Architettura chiave di MCP#

Host MCP: “L'AI con cui stai parlando”#

Cliente MCP: “Il connettore”#

Server MCP: “Il fornitore di strumenti”#

Fonti di dati locali: “I tuoi file e servizi”#

Servizi remoti: “API e strumenti online”#

Mettere tutto insieme#

A2A vs MCP — Confronto#

Come lavorano insieme#

Esempio di flusso di lavoro#

Conclusione#

Come l'infrastruttura di base MCP + A2A potrebbe plasmare il futuro dei marketplace di prodotti per agenti#

Il cambiamento dell'interazione uomo-computer#

Paradigmi di prodotti agentici e il loro impatto sul SaaS#

Sfide con i confini di autenticazione e autorizzazione#