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

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:

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

1. Scoperta: Legge ciascun agente .well-known/agent.json per comprendere capacità e autenticazione.
2. 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.
3. Aggiornamenti in streaming: Gli agenti trasmettono il progresso indietro usando Server-Sent Events (es. “laptop spedito”, “scrivania assegnata”).
4. Raccolta di artefatti: I risultati finali (es. badge PDF, email di conferma, credenziali dell'account) sono restituiti come artefatti A2A.
5. 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.

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

A2A vs MCP — Confronto#

Come lavorano insieme#

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

Esempio di flusso di lavoro#

1. Un utente invia una richiesta complessa in un'interfaccia di agente aziendale.
2. L'agente orchestrante utilizza A2A per delegare sottotask ad agenti specializzati (es. analisi, HR, finanza).
3. Uno di questi agenti usa MCP internamente per invocare una funzione di ricerca, recuperare un documento o calcolare qualcosa usando un modello.
4. 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:

1. 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.

2. 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.

1. Agente vs SaaS & Sito WebApp
2. Cliente MCP (Agente) vs Server MCP
3. Utente vs Agente
4. 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.