Agent Plugins, lo standard aperto che rende portabili le estensioni degli agenti AI

OpenAI non ha annunciato un nuovo modello, ma qualcosa che sul lavoro di chi costruisce agenti AI potrebbe pesare altrettanto. Il 6 agosto 2026 è arrivato Agent Plugins 1.0.0, uno standard aperto e neutrale rispetto ai fornitori per impacchettare competenze e connettori degli agenti in un unico formato portabile. L’idea è tanto semplice quanto ambiziosa: scrivi un’estensione una volta sola e falla funzionare su tutti i client compatibili, senza doverla riscrivere per ognuno.

Dietro il progetto non c’è una sola azienda. C’è un fronte insolitamente largo che mette allo stesso tavolo concorrenti diretti, e questo è forse l’aspetto più significativo dell’intera vicenda.

Cosa ha annunciato OpenAI con Agent Plugins

Agent Plugins è uno standard di impacchettamento, non un nuovo motore di esecuzione né un nuovo linguaggio per scrivere istruzioni. In pratica definisce una scatola comune in cui riporre due componenti che nel frattempo sono già diventati mattoni familiari dell’ecosistema: le competenze degli agenti, ossia le istruzioni e le risorse riutilizzabili che dicono a un modello come svolgere un compito, e i server basati sul protocollo che collega gli agenti a strumenti, API e fonti di dati esterne.

La specifica è stata pubblicata da un comitato tecnico di manutentori che riunisce Amazon, Cursor, Microsoft, OpenAI e Vercel, con Google che si è aggiunta come manutentore principale rappresentata dall’ingegnere Kevin Hou di DeepMind. Il documento è disponibile pubblicamente sul sito ufficiale del progetto, che ne raccoglie la specifica completa e l’elenco dei client compatibili.

La promessa che accompagna il lancio si riassume in una frase: costruisci un plugin una volta e usalo su tutti i client compatibili. Sembra un dettaglio da addetti ai lavori, ma tocca un punto dolente che chiunque abbia provato a distribuire un’estensione conosce bene.

Il problema del fork and drift e perché serviva uno standard

Immagina di aver scritto una competenza che interroga il database dei report della tua azienda e trasforma i risultati nel riepilogo settimanale che il team legge davvero. Le hai affiancato uno script o un piccolo server per farla funzionare. Sul primo client tutto gira alla perfezione.

Poi provi a portarla su un secondo client, e qui iniziano i guai.

La competenza va bene, il server va bene. Quello che non va è l’involucro attorno a loro: la disposizione delle cartelle è diversa, il file che descrive il pacchetto vuole metadati differenti, la configurazione del connettore usa una forma diversa e interpreta i trasporti in un altro modo. Così sei costretto a duplicare il pacchetto, a mantenere due copie di componenti che in origine erano identici e a guardarli lentamente divergere. È il fenomeno che gli stessi autori chiamano fork and drift, la biforcazione seguita dalla deriva.

Il nodo, spiegano, non sono i componenti. È il manifesto che li descrive, quella scatola che ogni client finora ha dovuto inventarsi per conto proprio. Le competenze erano già portabili, i connettori pure, ma la confezione no. Agent Plugins nasce esattamente per standardizzare quella confezione e lasciare intatto tutto il resto.

Come funziona un Agent Plugin

La scelta di fondo è la sobrietà, e la sobrietà è il punto. Un plugin è semplicemente una cartella con una struttura prevedibile, in cui ogni cosa sta in una posizione fissa e nota in anticipo.

Una cartella, poche regole chiare

Alla radice trovi un file manifesto chiamato plugin.json che, nella sua forma minima, contiene appena due righe di sostanza: il riferimento allo schema e il nome del plugin. Nient’altro è obbligatorio. Le competenze vivono in una cartella dedicata, una sottocartella ciascuna, nel formato che la specifica delle competenze già definisce. I connettori vengono dichiarati in un file separato, con un tipo esplicito per ogni voce, così il client non deve mai indovinare il trasporto dalla forma della configurazione e funziona indistintamente su stdio, su HTTP in streaming o sul vecchio HTTP con eventi.

C’è poi una cartella con un nome a dominio rovesciato che fa da via di fuga: è uno spazio riservato interamente a un singolo client per aggiungere ganci, agenti, comandi o qualsiasi altra cosa gli serva. I client che non la riconoscono la ignorano e vanno avanti. In questo modo il nucleo portabile resta piccolo, perché le parti non portabili hanno finalmente un posto legittimo dove stare.

Interessante è anche ciò che il manifesto volutamente non può fare. Non può spostare i componenti altrove né dichiararli in linea. Non esiste un percorso di scoperta da configurare né un ordine di precedenza da imparare. E se un connettore dichiarato non parte, non trascina con sé le competenze del plugin: il client salta quella voce, continua a caricare il resto e segnala l’errore. I componenti indipendenti falliscono in modo indipendente, che è una garanzia di robustezza tutt’altro che scontata.

Cosa lo standard lascia volutamente fuori

La versione 1.0 è un formato di pacchetto e nulla di più. Non definisce un meccanismo di installazione, non un protocollo di distribuzione, non un modello di permessi, non requisiti di isolamento, non un sistema per verificare la provenienza o l’affidabilità del codice, e nemmeno un’esperienza d’uso. Sono assenze dichiarate apertamente, non omesse in silenzio, e finiscono in un documento pubblico dedicato agli sviluppi futuri.

La scelta ha una logica precisa. Installazione, politiche di sicurezza, controlli aziendali e schermate di approvazione sono profondamente diversi tra un ambiente di sviluppo integrato, uno strumento a riga di comando e una piattaforma enterprise gestita. Ogni applicazione agentica ha obblighi reali e distinti verso i propri utenti, e imporre dall’alto un’unica soluzione avrebbe soffocato proprio quella libertà di innovare che lo standard vuole preservare.

Attorno al pacchetto, comunque, si sta già formando un ecosistema a strati. C’è un livello che serve a trovare le risorse disponibili per un certo compito, uno che le descrive in un catalogo, il pacchetto vero e proprio di Agent Plugins e infine i contratti di esecuzione, cioè le competenze e i connettori che erano già portabili. Ogni strato è adottabile per conto suo: puoi pubblicare un plugin senza catalogarlo, catalogare una risorsa che non è un plugin, o eseguire competenze senza alcun plugin.

Perché rivali come Google, Microsoft e Amazon hanno firmato insieme

Il dettaglio politicamente più rilevante è la composizione del gruppo. Amazon, Cursor, Microsoft, OpenAI e Vercel siedono nello stesso comitato tecnico, con Google che si aggiunge come manutentore principale. Lo statuto del progetto vieta esplicitamente a un singolo fornitore di detenere la maggioranza dei seggi, una clausola pensata per impedire che lo standard venga catturato da un solo attore.

Che aziende in feroce competizione sul mercato dei modelli scelgano di convergere su un’infrastruttura condivisa non è banale. Ricorda da vicino quanto accaduto con il protocollo che collega gli agenti agli strumenti, diventato di fatto lo standard di settore per la connettività e nelle scorse settimane approdato a una versione stateless con la specifica del 28 luglio. Là si trattava di uniformare il modo in cui gli agenti raggiungono i dati; qui si tratta di uniformare il modo in cui le loro estensioni vengono confezionate e spostate.

C’è anche un contrasto storico che vale la pena notare. I primi plugin di ChatGPT, nel 2023, erano un giardino recintato legato a un solo prodotto e furono presto accantonati. Questa volta l’impostazione è opposta, aperta e collaborativa fin dalla nascita.

Non stupisce che la lista dei client compatibili al lancio attraversi i confini aziendali: ci sono Codex e ChatGPT di OpenAI, Cursor, GitHub Copilot, Kiro di Amazon e l’ambiente di sviluppo di Microsoft. Google, dal canto suo, ha già portato il supporto in due dei suoi prodotti, uno strumento a riga di comando per costruire agenti e un kit che collega gli agenti ai suoi servizi dati come BigQuery, Spanner e Cloud SQL.

Cosa cambia adesso per chi costruisce agenti

Per lo sviluppatore che crea estensioni, il beneficio immediato è concreto: meno tempo perso a reimpacchettare gli stessi componenti per client diversi e meno copie da tenere allineate. Chi pubblica una competenza o un connettore può ragionevolmente aspettarsi che, rispettando il formato, il suo lavoro giri ovunque senza adattamenti su misura.

Per l’ecosistema, il segnale è di maturità. Dopo la stagione della corsa ai modelli sempre più grandi, l’attenzione si sposta sull’infrastruttura poco appariscente che rende gli agenti davvero utilizzabili nel lavoro quotidiano, e proprio questo tipo di impianto conviene condividerlo invece di reinventarlo cinque volte. Non a caso la settimana di OpenAI è stata intensa anche sul fronte prodotto, tra i nuovi plugin educativi per ChatGPT e gli aggiornamenti ai modelli, ma è su questi standard condivisi che si gioca la partita di lungo periodo.

Vale la pena ricordare i limiti. Agent Plugins non risolve la sicurezza, la distribuzione o la fiducia nel codice di terze parti: quei problemi restano aperti e demandati ai singoli client, dagli assistenti come ChatGPT fino agli agenti di coding da terminale che negli ultimi mesi si stanno moltiplicando. È un tassello, importante ma parziale, di un puzzle molto più grande.

Se sviluppi agenti o stai valutando come distribuire le tue competenze, questo è il momento giusto per leggere la specifica, provare a costruire un plugin minimo e capire se il formato fa al caso tuo. Continua a seguirci su intelligenzaartificiale.net per gli aggiornamenti su come lo standard verrà adottato dai principali client nelle prossime settimane, perché è lì che si vedrà se la promessa della portabilità reggerà alla prova dei fatti.