Parliamo del progetto
Protocolli agentici

MCP, A2A e AGNTCY: comprendere l'interoperabilità degli agenti IA nel 2026

Tutti i protocolli agentici non risolvono lo stesso problema. Impilarli senza un bisogno chiaro aumenta la superficie di attacco e la complessità operativa.

MCP, A2A e AGNTCY: comprendere l'interoperabilità degli agenti IA nel 2026

L'ecosistema agentico si dota di protocolli aperti per evitare che ogni framework e fornitore inventi i propri connettori. MCP, A2A e AGNTCY sono spesso citati insieme, ma non risolvono lo stesso problema. MCP collega principalmente un'applicazione IA a strumenti e dati. A2A organizza gli scambi tra applicazioni agentiche. AGNTCY sviluppa componenti di infrastruttura per la scoperta, l'identità, la messaggistica e l'osservabilità degli ecosistemi di agenti.

Combinarli può essere pertinente su larga scala. Impilarli su un semplice assistente interno crea una complessità e una superficie di sicurezza inutili.

A2A v1.0 è presentato dal suo progetto come una versione stabile pronta per la produzione; MCP ha pubblicato la specifica il 28-07-2026. La maturità e le interfacce AGNTCY devono essere verificate per ogni componente.

Perché l'interoperabilità sta diventando un argomento

Un'azienda può utilizzare diversi modelli, framework e prodotti. Un agente commerciale potrebbe dover richiedere un'analisi a un agente documentale, quindi utilizzare uno strumento di CRM. Senza un contratto comune, ogni interazione è un'integrazione specifica.

L'interoperabilità mira a:

  • scoperta di capacità ;
  • descrizione delle mansioni ;
  • scambio di messaggi e artefatti;
  • gestione di lavori lunghi;
  • identità ;
  • sicurezza;
  • osservabilità ;
  • portabilità tra fornitori.

Non sostituisce il modello di dominio, le regole di autorizzazione o la governance dei dati.

MCP: connettere un'applicazione IA a delle capacità

MCP standardizza il modo in cui un cliente scopre e utilizza strumenti, risorse ed estensioni esposte da un server. È adatto quando un'applicazione agentica deve consultare un repository, chiamare un'API di business o avviare una capacità regolamentata.

Il server può rimanere una facciata sopra un servizio esistente. Gli strumenti devono essere stretti, autorizzati e osservabili. MCP non trasforma un servizio in un agente autonomo; rende le sue capacità consumabili in modo standardizzato.

La specifica 2026-07-28 adotta un core stateless e un framework di estensioni, il che facilita alcuni deployment su scala.

A2A : collaborare tra agenti

A2A mira allo scambio tra applicazioni agentiche che possono essere costruite con framework diversi e mantenere opaco il loro funzionamento interno. Un agente pubblica una mappa delle capacità, riceve un compito, scambia messaggi e restituisce artefatti o uno stato.

Il protocollo è pertinente quando un agente delega un compito a un altro attore che possiede la propria autonomia, il proprio ciclo di vita ed eventualmente la propria organizzazione. Gestisce meglio i lavori lunghi e le interazioni rispetto alla chiamata di un semplice strumento.

A2A v1.0 segna una stabilizzazione del contratto. L'adozione non esonera dal verificare identità, inquilino, autorizzazione, riservatezza e risultato.

AGNTCY : infrastruttura aperta per un Internet degli agenti

Il progetto AGNTCY, ospitato dalla Linux Foundation, sviluppa componenti intorno alla scoperta, all'identità, alla messaggistica e all'osservabilità. Il suo Open Agentic Schema Framework propone una tassonomia per descrivere capacità, domini e relazioni.

Questo livello diventa interessante quando molti agenti devono essere trovati, qualificati e operati attraverso squadre o organizzazioni. Non è un obbligo per utilizzare MCP o A2A. I componenti e la loro maturità devono essere valutati individualmente.

Quale protocollo per quale problema?

Bisogno Opzione minima probabile
Chiamare una funzione di business stabile API classica
Esporre strumenti a diversi clienti IA MCP
Delegare un compito a un'applicazione agentica A2A
Scoprire e governare molti agenti registro/infrastruttura dedicata
Orchestrare alcuni componenti interni framework o workflow interno
Scambiare con un partner API o A2A a seconda dell'autonomia e della durata

Confronto dei ruoli di MCP, A2A e di un'infrastruttura agentica di scoperta e osservabilità.

API classico o protocollo agentico

Un'API rimane preferibile quando l'operazione è deterministica, il contratto stabile e gli attori conosciuti. È più semplice da testare, proteggere e sfruttare.

Un protocollo agentico apporta un valore quando le capacità vengono scoperte, i compiti evolvono, gli scambi sono lunghi o più fornitori devono collaborare. Il criterio non è l'uso di un LLM, ma la natura del contratto.

Un'architettura combinata

Uno scenario possibile:

  1. un agente coordinatore riceve un obiettivo;
  2. scopre un agente specializzato tramite un registro ;
  3. gli delega un compito con A2A ;
  4. l'agente specializzato utilizza MCP per accedere a strumenti interni;
  5. l'infrastruttura raccoglie identità, tracce e stati;
  6. Una politica convalida il risultato prima dell'azione.

Ogni livello deve avere una responsabilità. Lo stesso bisogno non deve essere incapsulato in più protocolli senza motivo.

Scoperta e fiducia

Scoprire una scheda agente o un server non significa fidarsi di esso. Il registro conserva il proprietario, la versione, la provenienza, eventuali certificazioni, capacità, politiche e stato di approvazione.

L'identità deve funzionare attraverso le frontiere. Un'organizzazione può richiedere un contratto, una lista autorizzata e un'autenticazione reciproca prima di qualsiasi scambio.

Le capacità dichiarate sono verificate. Un agente non riceve più dati perché afferma di possedere una competenza.

Autorizzazione e delega

Quando un agente delega, non deve trasmettere un token generale. La delega precisa:

  • committente;
  • beneficiario ;
  • compito;
  • risorse ;
  • durata;
  • bilancio ;
  • azioni ;
  • possibilità di sotto-delega.

Il servizio finale ricontrolla i diritti. La catena di delega è visibile nell’audit.

Compiti, messaggi e artefatti

Un compito lungo possiede uno stato, degli aggiornamenti, una cancellazione e un risultato. I messaggi non devono essere confusi con comandi autorizzati. Gli artefatti — documento, rapporto, codice o dati — hanno un tipo, una provenienza e dei diritti.

L'orchestratore deve essere in grado di gestire un agente indisponibile, un risultato parziale o un ritardo. Non presume che una risposta conversazionale equivalga a un successo aziendale.

Semantica delle capacità

Due agenti possono entrambi dichiarare "ricerca" pur producendo risultati incompatibili. Schemi, tassonomie e contratti aziendali rimangono necessari. OASF può aiutare a descrivere le capacità, ma l'azienda deve definire i propri requisiti di qualità e dati.

Le versioni e le estensioni sono negoziate. Un cambiamento di capacità provoca una nuova qualificazione.

Osservabilità distribuita

Un compito attraversa diversi agenti, protocolli e strumenti. L'identificativo di correlazione, i timestamp e gli stati devono seguire il percorso senza esporre i prompt sensibili.

Le metriche includono:

  • tempo totale e per attore;
  • delegazioni;
  • errori;
  • riprese ;
  • costi;
  • approvazioni ;
  • risultati respinti;
  • politiche applicate.

Un sistema multi-agente senza tracciamento end-to-end è difficile da diagnosticare e fatturare.

Sicurezza

I principali rischi sono:

  • agente o server dannoso;
  • carta di capacità ingannevole;
  • delegazione eccessiva;
  • iniezione nei messaggi;
  • esfiltrazione tramite uno strumento;
  • artefatto pericoloso;
  • ciclo di delega;
  • consumo incontrollato;
  • confusione di titolare.

I controlli includono elenchi consentiti, budget, profondità massima, convalida degli schemi, sandbox, approvazioni, limiti di rete e meccanismo di interruzione.

Evitare cicli e esplosioni di costo

Un agente può delegare a un altro che a sua volta delega. L'orchestratore fissa profondità, numero di compiti, durata, token, strumenti e budget. Le sotto-deleghe sono autorizzate esplicitamente.

Un compito deve poter essere annullato e le risorse liberate. I tentativi sono idempotenti e limitati.

Governance delle versioni

MCP, A2A e i componenti AGNTCY evolvono. L’organizzazione mantiene una matrice di compatibilità, ambienti di test e una politica di aggiornamento. Le deprecazioni sono trattate come cambiamenti di API.

Gli SDK semplificano l’implementazione ma non devono nascondere la versione effettivamente supportata.

Iniziare con l’architettura minimale

Un primo agente interno può utilizzare API esistenti e alcuni strumenti MCP. A2A diventa rilevante quando un altro agente autonomo, eventualmente esterno, deve collaborare. Un'infrastruttura di scoperta distribuita arriva quando il numero di attori e i confini lo richiedono.

Questa progressione evita di costruire un « Internet degli agenti » per automatizzare un solo flusso di lavoro.

Standard al servizio di una governance

I protocolli aperti migliorano la portabilità e riducono le integrazioni specifiche. Non sostituiscono le scelte di fiducia, di qualità e di responsabilità.

Partitech può concepire un'architettura minima, sviluppare server MCP, integrare A2A e valutare i mattoni dell'infrastruttura agentica. L'obiettivo è un'interoperabilità utile, testabile e sicura, non un cumulo di standard.

Parliamo del tuo progetto

Definire un'architettura agentica interoperabile e governata con Partitech. Contatta Partitech.

Condividi questo articolo