Agent Plugins: il formato portabile per componenti AI agentici

Amazon Web Services, Cursor, GitHub, Microsoft, OpenAI e Vercel hanno pubblicato il 6 agosto 2026 Agent Plugins 1.0.0: un formato aperto e vendor-neutral per impacchettare componenti agentici e installarli su client diversi senza riscriverli. È una notizia tecnica che sembra riguardare solo chi sviluppa estensioni, ma tocca una domanda molto più concreta: l’interoperabilità degli agenti AI per le aziende, cioè quanto costa cambiare fornitore dopo aver costruito mezzo processo interno sopra un assistente. Vale la pena capire cosa risolve davvero questo standard, e soprattutto cosa non risolve.

In questo articolo scoprirai:

• Agent Plugins 1.0.0: cosa è stato annunciato il 6 agosto 2026
• Come funziona il formato Agent Plugins: plugin.json, skills e mcp.json
• Il parallelo con le estensioni browser: perché l'interoperabilità degli agenti AI arriva adesso
• Cosa cambia per l'interoperabilità degli agenti AI in azienda: portabilità e lock-in
• Standard emergenti e onboarding: come li valutiamo nelle scelte architetturali

Agent Plugins 1.0.0: cosa è stato annunciato il 6 agosto 2026

Fino a ieri chi costruiva un’estensione per agenti doveva rifarla per ogni client: stessa logica, ma metadati, percorsi di discovery e configurazione MCP diversi. L’annuncio di Vercel lo dice senza giri di parole: «clients often expect different top-level metadata, discovery paths, or MCP configuration». Agent Plugins elimina quella ripetizione definendo un unico pacchetto portabile.

Al lancio il formato è letto da sei client: ChatGPT, Codex, Cursor, GitHub Copilot, Kiro e VS Code. Non è un nuovo protocollo che compete con quelli esistenti: è il livello di packaging e distribuzione che sta sopra Agent Skills e MCP. Se ti servono le fondamenta, le abbiamo già coperte nella guida al Model Context Protocol e nell’analisi di MCP e A2A.

Il dettaglio che sposta l’ago non è il numero dei firmatari, ma quali prodotti leggono già il formato. Che ChatGPT e Codex accettino lo stesso pacchetto di Cursor e VS Code significa che una competenza scritta per un assistente di sviluppo può finire davanti a un utente non tecnico senza essere riscritta: come osserva The Next Web, per OpenAI aderire a uno standard aperto sulle skill è anche un modo per spostare la competizione dal formato al prodotto. Per un’azienda la conseguenza pratica è meno astratta di quanto sembri: l’investimento fatto una volta su una skill interna ha più superfici su cui atterrare, e quindi si ammortizza su più anni.

Chi c’è (e chi manca) nel consorzio Agent Plugins

Attorno alla specifica ci sono Amazon Web Services, Anysphere (Cursor), GitHub, Microsoft, OpenAI e Vercel, con un Technical Steering Committee che riunisce i maintainer di AWS, Cursor, Microsoft, OpenAI e Vercel. L’assenza pesante è quella di Anthropic, che ha creato sia MCP sia le Agent Skills su cui il formato si appoggia, come nota The Decoder. Uno standard di interoperabilità senza uno degli autori delle tecnologie che impacchetta è un fatto da tenere presente, non un dettaglio politico: chi costruisce oggi sopra lo stack Anthropic, il perimetro di cui parliamo in Claude Agent SDK per PMI, deve mettere in conto che la portabilità dichiarata potrebbe non coprire tutto ciò che usa. In pratica, prima di considerare Agent Plugins una garanzia anti-lock-in, conviene fare l’inventario: quali skill e quali server MCP già in uso rientrano davvero nel pacchetto portabile e quali restano fuori, legati alle estensioni proprietarie del client.

Come funziona il formato Agent Plugins: plugin.json, skills e mcp.json

La specifica pubblicata su agent-plugins.org è deliberatamente minima. Un plugin è una directory che contiene tre elementi: un manifest plugin.json obbligatorio, che dichiara nome e versione della specifica; una cartella skills/ con le Agent Skills; un file mcp.json opzionale che descrive i server MCP, in modalità stdio, Streamable HTTP o il vecchio HTTP+SSE. Le cartelle con namespace reverse-domain (tipo com.example.client/) permettono a ogni client di aggiungere comportamenti proprietari senza contaminare il nucleo portabile.

Due scelte tecniche meritano attenzione. La prima è l’isolamento dei guasti: un componente non valido non disabilita gli altri. La seconda sono le regole di path containment contro il directory traversal. Sono garanzie modeste ma reali.

Il changelog di Vercel chiarisce anche il punto di ingresso: la specifica nasce già come 1.0.0, con il numero di versione dichiarato dentro il manifest. Sembra una formalità e non lo è: è il versionamento nel manifest che permette a un client di rifiutare in modo pulito un pacchetto che non sa leggere, invece di caricarlo a metà e fallire a runtime dentro una conversazione con l’utente.

Perché un plugin è solo una cartella (e perché conta per l’IT aziendale)

«A plugin is a directory», recita la specifica: non un archivio proprietario. Significa che il pacchetto si ispeziona con ls e si versiona con git, senza tool dedicati. Per un reparto IT che deve approvare cosa gira sui dati interni è una differenza enorme rispetto a un blob opaco: si può leggere prima di installare. È lo stesso criterio di trasparenza che raccomandiamo quando si collegano agenti ai sistemi gestionali, un tema che approfondiamo in integrare agenti AI con ERP e CRM, e che vale a maggior ragione quando un server MCP porta l’agente dentro la knowledge base aziendale con approcci come il RAG.

Il parallelo con le estensioni browser: perché l’interoperabilità degli agenti AI arriva adesso

La storia è già andata così una volta. Per anni ogni browser ha avuto il proprio formato di estensione, e chi sviluppava doveva mantenere versioni parallele dello stesso add-on. Quando il modello WebExtensions è diventato il denominatore comune, il costo di pubblicare per più browser è crollato e l’ecosistema è esploso. La lezione, però, ha una seconda parte spesso dimenticata: la convergenza sul formato non ha eliminato le differenze di permessi, review e store, che sono rimaste il vero terreno di competizione. Agent Plugins è oggi esattamente al primo tempo di quella partita.

MCP, A2A e Agent Plugins: tre livelli diversi di interoperabilità

Confondere i tre livelli è l’errore più comune. MCP collega un agente a strumenti e dati. A2A, l’open standard lanciato da Google nell’aprile 2025 con oltre 50 partner tecnologici, fa parlare gli agenti tra loro tramite le Agent Card. Agent Plugins non fa né l’una né l’altra cosa: impacchetta e rende installabile ciò che gli altri due protocolli fanno funzionare. Sono strati complementari, e chi progetta sistemi con più agenti che cooperano, il tema della multi-agent orchestration, deve ragionare su tutti e tre insieme, non sceglierne uno.

La tassonomia, del resto, è ancora in movimento, e tenerla a mente serve a non fare confronti sbagliati in fase di scelta. La rassegna di IBM sugli agent protocols distingue le famiglie context-oriented, che regolano l’accesso di un agente a strumenti e dati, da quelle inter-agent, che governano comunicazione e delega tra agenti autonomi. Agent Plugins non appartiene a nessuna delle due: sta un piano sopra. Ed è la ragione per cui adottarlo non risponde alla domanda «quale protocollo usiamo», ma solo a «come lo distribuiamo».

Cosa cambia per l’interoperabilità degli agenti AI in azienda: portabilità e lock-in

Per un’azienda che sta integrando un agente custom, il beneficio immediato è di natura contrattuale prima ancora che tecnica. Se le competenze e le connessioni ai sistemi interni vivono in un pacchetto portabile, cambiare client costa meno. Il lavoro di modellazione dei processi resta patrimonio dell’azienda, non del fornitore dell’assistente. È una leva reale nella scelta tra soluzioni custom e off-the-shelf.

Attenzione però a non sopravvalutare la portata. I formati proprietari restano first-class: Cursor mantiene .cursor-plugin/, OpenAI .codex-plugin/, Anthropic .claude-plugin/. Il formato portabile ha aggiunto un’opzione, non sostituito le altre. È uno standard sottile per costruzione, e questo lascia aperta la possibilità che la frammentazione si sposti semplicemente un livello più in là, dentro le implementazioni di piattaforma.

Cosa lo standard NON copre: sicurezza, provenance e audit

Qui sta il punto per chi decide. La versione 1.0.0 lascia fuori sette aree esplicitamente: verifica di provenienza e firme, UX di permessi e approvazione, gestione dei segreti, controlli enterprise e audit trail, meccanismo di distribuzione, risoluzione delle dipendenze e strumenti di validazione. Tradotto: portabilità non significa sicurezza. L’analisi di Digital Applied segnala un’asimmetria scomoda, in VS Code i server MCP di un plugin risultano implicitamente fidati all’installazione, e raccomanda alle imprese di costruirsi da sé i gate di approvazione, trattando l’installazione di un plugin come l’aggiunta di una dipendenza di codice. È lo stesso perimetro della governance degli agenti AI, dove il formato aiuta ma non decide.

Standard emergenti e onboarding: come li valutiamo nelle scelte architetturali

Il segnale che uno standard non è un fuoco di paglia arriva anche dal regolatore: il 17 febbraio 2026 il Center for AI Standards and Innovation del NIST ha lanciato la AI Agent Standards Initiative, costruita su tre pilastri, standard guidati dall’industria, sviluppo open source dei protocolli e ricerca su identità e sicurezza degli agenti. Interoperabilità e identità degli agenti sono diventate materia di politica industriale, non solo di ingegneria.

Dal prodotto al servizio: valutare uno standard prima di adottarlo

In MIMIR usiamo questi segnali in modo pratico: uno standard entra in un’architettura cliente quando riduce il costo di uscita e non introduce fiducia implicita. Agent Plugins oggi supera il primo test e non il secondo, quindi lo trattiamo come formato di packaging da affiancare a policy di approvazione interne. Ma nessuno standard, da solo, fa adottare un agente alle persone che devono usarlo: quello resta un lavoro di onboarding, di mappatura dei processi e di affiancamento, la ragione per cui, come argomentiamo in questo approfondimento, il servizio conta più del modello.

Se stai partendo da zero, conviene guardare prima il quadro generale e poi la direzione in cui si sta muovendo il mercato. Gli standard di packaging come Agent Plugins diventano rilevanti dopo, quando c’è già un processo da automatizzare e una decisione da prendere su chi lo ospita.

Se la tua azienda sta valutando come portare un agente AI dentro processi reali senza legarsi mani e piedi a un singolo fornitore, questa è esattamente la conversazione che facciamo ogni giorno: puoi scoprire come lavoriamo con Mimír AI Agent oppure scriverci su mimir.bot per una consulenza dedicata, dall’analisi dei processi all’affiancamento durante l’onboarding.

Fonti:

• Vercel — Introducing Agent Plugins
• Vercel Changelog — Agent Plugins 1.0.0
• agent-plugins.org — Specifica Agent Plugins 1.0.0
• The Decoder — Il consorzio dietro lo standard
• The Next Web — OpenAI e lo standard aperto su skill e MCP
• Digital Applied — Analisi di sicurezza di Agent Plugins 1.0
• IBM Think — AI agent protocols
• Google Developers Blog — A2A, agent interoperability
• NIST — AI Agent Standards Initiative