Protocolli Agent-to-Agent: come MCP e A2A stanno ridefinendo l'interoperabilità multi-agente

Sei mesi fa, 'sistema multi-agente' significava una mesh artigianale di endpoint HTTP tenuta insieme da adattatori, logica di retry e speranza. Oggi, due protocolli stanno cambiando tutto: Model Context Protocol (MCP) e Agent-to-Agent (A2A). Risolvono problemi diversi, si compongono in modo elegante e la maggior parte dei team li sta implementando male.

Il problema di interoperabilità che nessuno voleva risolvere

Negli ultimi due anni, ogni team serio di IA ha riscoperto lo stesso dolore: gli agenti non parlano con nulla in modo standard. Ogni framework — LangChain, LlamaIndex, AutoGen, CrewAI — ha inventato la propria convenzione di tool calling. Ogni vendor ha rilasciato il proprio schema JSON di 'function calling'. Risultato: ogni integrazione era su misura, ogni migrazione era una riscrittura, e ogni 'sistema multi-agente' era in realtà un singolo framework che fingeva di essere molti agenti.

Il settore ha già vissuto tutto questo. Avevamo SOAP finché REST non ha standardizzato la comunicazione servizio-a-servizio. Avevamo formati di container proprietari finché OCI non ha standardizzato il runtime. Avevamo orchestrazione vendor-locked fino a Kubernetes. Il layer agentico era il prossimo posto in attesa del suo protocollo — e ora ne ha due.

MCP: l'USB-C del tooling per agenti

Model Context Protocol (MCP) risponde a una domanda circoscritta: come scopre e invoca un agente gli strumenti, le risorse e i prompt disponibili? L'analogia che è rimasta — ed è rimasta per una buona ragione — è USB-C. Qualsiasi client MCP-compatibile può connettersi a qualsiasi server MCP-compatibile senza codice di collante su misura.

Un server MCP espone tre primitive: tools (funzioni che l'agente può chiamare), resources (dati che l'agente può leggere) e prompts (istruzioni templated che il server può iniettare). Il trasporto è JSON-RPC 2.0, solitamente su stdio per server locali o HTTP con Server-Sent Events per quelli remoti. Nient'altro. La semplicità è il punto.

• Un agente, molti server MCP: il tuo agente di coding basato su Claude può connettersi simultaneamente a un server MCP per GitHub, uno per Postgres, uno per il filesystem e uno interno per Jira — senza una sola riga di adapter custom.
• Controllo delle capacità lato server: il server MCP definisce cosa l'agente può vedere e fare. Non consegni credenziali all'agente; esegui il server con quelle credenziali ed esponi una superficie di strumenti circoscritta.
• Contesto componibile: le resources MCP permettono a un agente di portare contesto fresco (file, righe di database, risposte API) al momento del reasoning, invece di caricare tutto nel system prompt.
• Nessun lock-in di SDK: MCP è un protocollo di rete. Puoi scrivere un server in Python, Rust, TypeScript, Go o qualsiasi linguaggio che parli JSON-RPC.

In Xcapit costruiamo agenti di IA dove ogni capacità esterna vive dietro un server MCP. Non è una scelta stilistica — è di governance. Quando uno strumento vive dietro un server MCP, hai un singolo choke point auditabile per autorizzazione, rate limiting e logging. Quando vive dentro il codice dell'agente, non hai nulla di tutto ciò.

A2A: il protocollo per quando un agente solo non basta

Agent-to-Agent (A2A) risolve un problema che MCP non è mai stato pensato per risolvere: come due agenti — possibilmente di vendor diversi, costruiti su framework diversi, con modelli diversi — negoziano, delegano e collaborano su un task? A2A tratta ogni agente come un servizio peer con una 'agent card' scopribile (capacità, requisiti di autenticazione, skill) e definisce le forme dei messaggi per il ciclo di vita di un task: submitted → working → input-required → completed → failed.

Il protocollo è deliberatamente conservativo su ciò che standardizza. Non prescrive come un agente ragiona, che modello usa o come pianifica. Standardizza solo i bordi dove gli agenti si incontrano: identità, handoff di task, streaming di stato, scambio di artifact. Tutto ciò che è interno all'agente rimane la tua scelta implementativa. Ed è esattamente così che deve essere.

• Agent Card: un documento JSON pubblico su /.well-known/agent.json che dichiara cosa un agente può fare, come autenticarsi e quali skill espone. La discovery diventa banale.
• Ciclo di vita dei task tipizzato: ogni scambio A2A è un Task con una state machine definita. Fine dei loop di polling ad-hoc e dei retry webhook non documentati.
• Streaming di default: il lavoro agentico long-running emette aggiornamenti di stato e artifact parziali via SSE. La tua UI non finge che l'agente sia una funzione sincrona.
• Cross-vendor by design: un agente basato su Claude può invocare un agente basato su Gemini, che a sua volta invoca uno basato su un modello open — senza che nessuno conosca gli interni degli altri.

La composizione: MCP dentro, A2A fuori

Il modello mentale che scatta per ogni team con cui abbiamo lavorato: MCP è come un agente raggiunge le sue capacità. A2A è come un agente raggiunge altri agenti. Vivono su piani diversi dell'architettura, e un sistema maturo usa entrambi.

Concretamente, in un progetto recente abbiamo rilasciato un sistema di revisione di documenti legali con quattro agenti: un agente di Intake (Python, Claude Sonnet), un Clause Analyzer (Rust, Claude Opus), un Compliance Checker (TypeScript, modello open fine-tuned) e un Summarizer (Python, Gemini). Ogni agente espone le sue skill via A2A. Ogni agente internamente raggiunge i suoi strumenti — ricerca vettoriale, OCR, registri di compliance, document storage — via MCP. L'orchestratore non sa come funziona nessun agente; invia solo task e riceve risultati in streaming. Gli agenti non sanno su cosa girano i loro peer; si chiamano tra loro tramite agent card.

Quel disaccoppiamento è ciò che fa sopravvivere l'architettura ai prossimi due anni. Quando uscirà Gemini 3 o DeepSeek R2 batterà tutti sull'estrazione di clausole, scambi gli interni del Clause Analyzer. Nient'altro cambia. Nessuna riscrittura dell'orchestratore, nessuna migrazione di database, nessuno sprint del 'platform team'.

Errori che abbiamo imparato a caro prezzo

• Non mettere logica di business nel server MCP. È un bordo di protocollo, non un layer di dominio. Le regole di dominio vanno nel servizio dietro il server MCP, non nelle definizioni degli strumenti.
• Non saltare l'identità dell'agente. Un caller A2A deve autenticarsi, e l'autenticazione deve essere servizio-a-servizio (mTLS, OIDC client credentials, JWT firmati), non 'una API key nell'header' riciclata dai tuoi giorni REST.
• Non loggare solo la risposta finale. Per ogni task A2A, logga la storia completa delle transizioni di stato e ogni chiamata a strumento MCP con i suoi argomenti. Quando un agente allucina una decisione, devi poter ricostruire il percorso di ragionamento — e puoi farlo solo se l'hai catturato.
• Non mischiare layer di trasporto arbitrariamente. I server MCP su stdio vanno bene per il tooling di sviluppo; quelli di produzione dovrebbero essere HTTP+SSE con auth appropriata. A2A deve sempre essere HTTPS con agent card firmate.
• Non esporre tutto. Che un agente possa chiamare qualsiasi strumento MCP non significa che debba. Applica il principio del minimo privilegio sul server: un Clause Analyzer non ha bisogno di accesso in scrittura al tuo CRM.
• Non costruire un 'orchestratore' custom prima di aver provato A2A. Il primo istinto è scrivere un agente supervisore con logica di delega hardcoded. Il task model A2A, con agent card appropriate, solitamente rimpiazza l'80% di quel codice.

Cosa arriva dopo

Tre spostamenti sono già visibili nell'ecosistema. Primo, MCP sta assorbendo primitive di governance — metadata di autorizzazione, dichiarazioni di rate limit, stime di costo — che lo rendono un backbone valido per settori regolamentati, non solo per tooling di sviluppatori. Secondo, A2A sta sviluppando un modello di delega di autorità in modo che l'agente B possa agire per conto dell'agente A con ambito circoscritto, che è il pezzo mancante per workflow agentici cross-organizzazione. Terzo, il layer di verifica: agent card firmate, artifact di task firmati e attestazioni on-chain delle azioni degli agenti — che è il ponte verso gli agenti di IA verificabili e la conversazione sulla governance di cui José Trajtenberg scrive separatamente.

La verità scomoda è che la maggior parte delle aziende che costruiscono sistemi di agenti oggi sta scrivendo codice che sarà obsoleto tra diciotto mesi. Non perché gli agenti siano sbagliati — perché il collante tra loro è su misura. Se stai architettando un sistema multi-agente nel 2026, la domanda non è più 'quale framework?' — è 'quali protocolli, e come li governo?'.

Se il tuo team sta valutando MCP, A2A o come avvolgere entrambi in un layer di governance production-grade, parliamone. Abbiamo fatto gli errori così il tuo team non deve.