Una spiegazione chiara di come gli agenti IA passano dal rispondere alle domande al consegnare applicazioni funzionanti: cosa fa davvero il Model Context Protocol, come i token con permessi limitati tengono gli agenti sotto controllo, il ciclo esatto che un agente esegue per creare, validare e pubblicare un'app, e cosa distingue le piattaforme agent-native dagli adattamenti a posteriori.
Founder, sviluppatori e figure operative che vogliono capire o usare agenti capaci di costruire e mantenere software vero, non solo di chattare.
- Un modello mentale semplice di MCP e il motivo per cui ogni grande laboratorio di IA lo ha adottato
- Un quadro onesto del modello di sicurezza: cosa consente e cosa non consente un token con permessi limitati
- Il ciclo in sei passi che un agente esegue dal brief all'applicazione pubblicata
Un agente IA che risponde alle domande è utile. Un agente che costruisce un'applicazione funzionante, la collega a un database e la pubblica su un dominio vero è uno strumento di tutt'altra natura. Il ponte tra i due è un piccolo standard volutamente noioso chiamato MCP, più un modello di permessi che rende il tutto abbastanza sicuro da poter essere usato. Ecco come funziona davvero, senza parole di moda.
MCP, il Model Context Protocol, è uno standard aperto che permette a un agente IA di usare strumenti esterni. Un servizio pubblica un menù di azioni che sa eseguire (creare un'app, modificare un file, lanciare una validazione) e qualsiasi agente compatibile con MCP può leggere quel menù e chiamare quelle azioni. Viene spesso descritto come l'USB-C dell'IA: un connettore unico che funziona con tutti i modelli e i servizi, invece di un cavo su misura per ogni coppia.
Un modello linguistico da solo può soltanto produrre testo. Non ha mani: non può toccare un database, chiamare una API né pubblicare un sito. Anthropic ha rilasciato MCP come standard aperto a fine 2024 per dargli mani in modo standardizzato, e l'adozione è stata insolitamente rapida. Nel giro di due anni ogni grande laboratorio di IA lo supportava, il registro pubblico superava diverse migliaia di server e gli SDK venivano scaricati decine di milioni di volte al mese.
Il motivo della diffusione è economico, non tecnico. Prima di un protocollo condiviso, collegare N modelli a M servizi significava costruire e mantenere N per M integrazioni su misura. Con uno standard unico, un servizio rilascia un solo server MCP e funziona subito con ogni agente capace, e un agente guadagna tutti i servizi il giorno in cui parla il protocollo. Lo stesso calcolo ha spinto l'USB, ed è finita allo stesso modo: ha vinto il connettore.
La prima reazione sensata davanti a una macchina capace di creare e pubblicare software è la preoccupazione, e la risposta onesta è che la sicurezza dipende interamente dal modello di permessi. Il meccanismo che rende tutto controllabile è il token con permessi limitati, e vale la pena capirlo con precisione, perché è la differenza tra delegare ed essere imprudenti.
Quando colleghi un agente a una piattaforma, non gli consegni il tuo account. Crei un token, una chiave con permessi specifici e limitati, e l'agente opera rigorosamente dentro quel recinto. Tutto ciò che fa è attribuibile a quel token, e il recinto lo disegni tu.
Un founder vuole che un agente sistemi il modulo di registrazione della sua app di prenotazioni. Genera un token limitato a quella singola app, con permessi di modifica e validazione ma senza pubblicazione. L'agente fa la modifica ed esegue la validazione; il founder rivede il diff, pubblica di persona e poi revoca il token. Esposizione totale: una app, due permessi, venti minuti. Ecco come appare una delega con il recinto.
Un agente che costruisce software vero non produce tutto in un'unica generazione eroica. Esegue un ciclo che assomiglia molto al modo di lavorare di un ingegnere scrupoloso, solo compresso da giorni a minuti.
Un modello può sempre produrre codice che sembra corretto. Ciò che rende affidabile il software costruito da un agente è il controllo dopo ogni modifica: un vero cancello che dice o che funziona o esattamente cosa si è rotto. Senza quel controllo, gli agenti derivano con piena sicurezza verso stati rotti. Con quel controllo, gli errori vengono intercettati dentro il ciclo, proprio come i bravi ingegneri umani evitano di mandarli in produzione.
Molti prodotti hanno avvitato un server MCP su un'interfaccia pensata per persone che cliccano pulsanti. Tecnicamente funziona, ma non è la stessa cosa di una piattaforma costruita per gli agenti. Tre segnali li distinguono.
Il test di simmetria è il filtro più rapido: su una piattaforma agent-native, un agente con un token ben delimitato può fare praticamente tutto ciò che una persona può fare dall'interfaccia, cioè creare un'applicazione, cambiarne i file, validare, versionare e pubblicare. Se il percorso dell'agente è una porta laterale stretta con metà delle capacità, la piattaforma tratta l'automazione come una funzione dimostrativa, e sentirai quel soffitto entro un mese di uso reale.
Quando trasformare un bisogno descritto in software funzionante smette di richiedere un umano che clicca dentro un builder, l'economia del software su misura cambia. Un team operativo può avere il suo strumento interno il giorno stesso in cui riesce a descriverlo, invece del trimestre successivo a una battaglia di priorità vinta. Un founder può affidare un brief approssimativo a un agente la sera e rivedere una prima versione funzionante la mattina. Un'azienda può permettersi software modellato esattamente su un flusso di lavoro, perché modellarlo non costa più di quanto quel flusso valga.
Niente di tutto questo elimina il giudizio umano. Qualcuno decide ancora cosa vale la pena costruire, rivede ciò che torna indietro e risponde del risultato. Ciò che cambia è il costo della distanza tra una descrizione chiara e un prodotto funzionante. Quella distanza si misurava in settimane e fatture. Ora si misura in minuti e in una revisione, e le aziende che lo capiranno presto avranno semplicemente più software, più adatto al loro modo di lavorare, rispetto a quelle che aspettano.
Il Model Context Protocol è uno standard aperto che permette agli agenti IA di scoprire e chiamare gli strumenti offerti da un servizio (creare un'app, modificare un file, eseguire un controllo), così qualsiasi agente capace può lavorare con qualsiasi servizio che pubblica un server MCP.
Sì, quando la piattaforma gli dà strumenti veri con un cancello di validazione: l'agente crea il progetto, costruisce modello dati e pagine, valida dopo ogni modifica, corregge ciò che il controllo trova e pubblica. La parte affidabile è il ciclo con verifica, non una singola generazione gigante.
Il token con permessi limitati sotto cui opera. Lo restringi ad applicazioni e azioni specifiche, ogni chiamata viene registrata e puoi revocarlo all'istante. Un agente con un token di modifica e validazione per una app non può eliminare altri progetti né pubblicare senza di te.
Applica il test di simmetria: con un token ben delimitato, l'agente può fare praticamente tutto ciò che fa una persona, cioè creare, modificare, validare, versionare, pubblicare? Se il percorso dell'agente è un sottoinsieme stretto dell'interfaccia umana, l'automazione era un ripensamento e ne toccherai presto il soffitto.