Il collo di bottiglia non è mai stato il modello
Chiedete alle aziende perché il loro progetto pilota di AI si è arenato: la risposta riguarda raramente il modello.
Il modello ragionava abbastanza bene. Ciò che non sapeva fare era leggere il contratto nel sistema di gestione documentale, verificare le giacenze nell'ERP, consultare lo storico del cliente nel CRM e riscrivere il risultato — in modo affidabile, con i permessi intatti, ogni volta.
Il ragionamento è diventato in larga misura una commodity. L'accesso è il vincolo. Ed è sull'accesso che i progetti di agenti si trasformano silenziosamente in progetti di integrazione.
Il problema N×M
Prima che esistesse uno standard, ogni collegamento tra agente e sistema era su misura.
Con quattro agenti e sei sistemi interni, mantenevate fino a ventiquattro integrazioni proprietarie. Ognuna con la propria gestione dell'autenticazione, la propria semantica degli errori, la propria idea di come descrivere ciò che sapeva fare. Cambiava l'API dell'ERP e dovevate correggere ogni agente che la utilizzava.
Il settore ha già risolto questo problema più volte in altri ambiti — driver di periferica, connettività ai database, language server negli editor di codice. La soluzione ha sempre la stessa forma: smettere di costruire collegamenti punto a punto e concordare un protocollo nel mezzo. Le N×M integrazioni diventano N+M.
Il Model Context Protocol (MCP) è quel protocollo per gli agenti AI. Introdotto da Anthropic come standard aperto e oggi implementato ben oltre, MCP definisce come un'applicazione AI scopre e invoca le capacità esposte dai sistemi esterni.
Cosa standardizza realmente MCP
MCP è un protocollo client-server. La vostra applicazione AI è l'host e contiene uno o più client. Ogni client si collega a un server MCP — un adattatore leggero posto davanti a un sistema, che descrive in modo leggibile dalla macchina ciò che quel sistema sa fare.
Il server espone tre tipi di primitive:
- Tool — le azioni che l'agente può invocare: creare una fattura, cercare contratti, verificare le giacenze. Ognuno porta con sé uno schema dei propri parametri, così l'agente sa come chiamarlo correttamente invece di tirare a indovinare.
- Risorse — i dati che l'agente può leggere. Un documento, un record, un albero di file. Indirizzabili e recuperabili senza effetti collaterali.
- Prompt — modelli di istruzioni riutilizzabili che il server offre per le attività ricorrenti su quel sistema, così la conoscenza di dominio risiede nel connettore invece di essere reinventata in ogni agente.
La conseguenza importante è che descrivere le capacità diventa compito del server, non dell'agente. Un server MCP per il vostro ERP si scrive una volta, da chi conosce l'ERP, e ogni agente dell'organizzazione può usarlo.
Perché questo cambia l'architettura aziendale
Lo spostamento architetturale si descrive in fretta e pesa molto nella pratica: l'integrazione diventa un bene riutilizzabile invece di un costo per progetto.
Ne derivano alcune conseguenze.
I connettori sopravvivono agli agenti. Gli agenti costano poco da riscrivere e verranno riscritti spesso, al variare di modelli e requisiti. Un server MCP per il vostro archivio documentale è infrastruttura stabile. Separare i due significa che il ricambio dei modelli non minaccia più il livello di integrazione.
Una sola superficie di integrazione da proteggere. Invece di verificare credenziali sparse nel codice degli agenti, avete un confine definito per ciascun sistema. Autenticazione, perimetro dei permessi, limitazione della frequenza e logging vivono nel server.
Diventa possibile un inventario delle capacità. Quando ogni sistema si espone attraverso lo stesso protocollo, potete finalmente rispondere alla domanda "cosa sanno fare i nostri agenti?" — che è una questione di governance molto prima di essere tecnica.
Il vincolo con il fornitore si riduce. Un connettore scritto contro un protocollo, e non contro un particolare framework di agenti, sopravvive al cambio di framework o di fornitore del modello.
Come si presenta un buon server
L'errore tipico al primo server MCP è rispecchiare l'API sottostante uno a uno — esporre quaranta endpoint come quaranta tool e considerare il lavoro concluso.
Il risultato è un server tecnicamente corretto che gli agenti usano male. Un server migliore è progettato intorno alle attività, non agli endpoint.
Confrontiamo due progettazioni per lo stesso ERP:
| Progettazione a specchio dell'API | Progettazione orientata all'attività |
|---|---|
| Cinque interrogazioni distinte: cliente, ordini, righe d'ordine, spedizioni, fatture | Un tool: recuperare lo storico ordini di un cliente |
| L'agente concatena cinque chiamate e può sbagliare la sequenza | Una chiamata, join corrette garantite lato server |
| Le modalità di guasto si moltiplicano a ogni chiamata | Errore gestito in un solo punto |
Il server orientato all'attività lavora di più internamente e lascia all'agente molte meno occasioni di sbagliare. Alcune linee guida pratiche:
- Nominate i tool per intento, nel vocabolario che la vostra azienda già usa.
- Scrivete le descrizioni per un neoassunto competente. Vengono lette dal modello e determinano in massima parte se un tool sarà usato correttamente.
- Restituite errori che suggeriscono il passo successivo, non stack trace grezzi. "Cliente non trovato — provate la ricerca per nome" è azionabile; un 404 nudo non lo è.
- Mantenete le risposte snelle. Ogni campo superfluo consuma contesto che serve all'agente per ragionare.
- Separate lettura e scrittura. Tool distinti, permessi distinti, trattamento di audit distinto.
Il controllo degli accessi è la parte difficile
MCP standardizza il modo in cui le capacità vengono descritte. Non decide chi è autorizzato a usarle — ed è proprio lì che i deployment aziendali diventano complicati.
Tre domande da risolvere prima che un server tocchi dati di produzione.
Quali permessi si applicano? Un agente che agisce per conto di una persona dovrebbe ereditarne i diritti, non possedere un account di servizio che vede tutto. La comodità dell'account di servizio all'inizio è il modo più comune in cui i progetti di agenti acquisiscono un problema di permessi che poi non riescono più a districare.
Qual è il raggio d'azione di ciascun tool? Un tool di lettura su una replica di reporting e un tool di scrittura che dispone pagamenti appartengono a categorie di rischio diverse, con requisiti di approvazione diversi. Trattarli allo stesso modo significa o limitare troppo l'innocuo o limitare troppo poco il pericoloso.
La tracciabilità è sufficiente? Ogni invocazione deve essere attribuibile — quale agente, per conto di chi, con quali argomenti, con quale risultato. Negli ambienti svizzeri ed europei regolamentati questo non è opzionale, e aggiungerlo a posteriori è considerevolmente più difficile.
Nemmeno la localizzazione dei dati svanisce perché è coinvolto un protocollo. Il server MCP è esattamente il punto in cui imponete che un documento non lasci mai una determinata giurisdizione — un punto di controllo da progettare deliberatamente, non da scoprire dopo.
Dove MCP si ferma
MCP è un protocollo di connessione. Non è un framework di agenti e non è orchestrazione.
Non dice nulla su come scomporre il lavoro fra più agenti, su come mantenere lo stato lungo un processo di lunga durata, su come gestire i tentativi ripetuti e le azioni compensative, né su come valutare se un agente ha svolto bene il proprio compito. Queste restano vostre decisioni di progettazione — la nostra orchestrazione AI affronta il livello che sta sopra quello di connessione.
Nominare chiaramente questo confine è utile. MCP elimina una categoria di lavoro di integrazione senza valore distintivo. Non elimina la necessità di pensare alla progettazione dei processi, e una squadra che si aspetti altro resterà delusa da un protocollo per il resto solido.
Come iniziare
Lo scenario di fallimento qui è un programma di piattaforma di sei mesi che collega tutto e non consegna niente. Ribaltatelo.
- Scegliete un flusso con attrito reale — qualcosa per cui oggi delle persone ricopiano dati fra due sistemi.
- Costruite il server più piccolo che lo supporti. Due o tre tool orientati all'attività, in sola lettura se il flusso lo consente.
- Fatelo girare in modalità shadow. L'agente produce un risultato che una persona confronta con il processo attuale, senza che venga intrapresa alcuna azione.
- Concedete la scrittura a un solo tool quando i risultati shadow sono costantemente corretti, con un'approvazione a monte.
- Solo allora generalizzate. Il vostro secondo server sarà migliore, perché il primo vi avrà insegnato cosa chiedono davvero i vostri agenti.
Ogni passo consegna qualcosa di utilizzabile, e questa sequenza produce integrazioni funzionanti invece di una strategia di integrazione.
Le organizzazioni che trarranno valore durevole dagli agenti non saranno quelle con i modelli più grandi. Saranno quelle i cui sistemi sono raggiungibili in modo pulito, correttamente delimitati e integralmente verificabili — perché la generazione di modelli cambierà ancora l'anno prossimo, il livello di integrazione no.
Collegare gli agenti a sistemi che non sono mai stati progettati per loro è la maggior parte del lavoro reale. Esplorate i nostri deployment in produzione oppure parlate con il nostro team di come sarebbe un'architettura accessibile agli agenti per il vostro stack.