#AI #LLM #Development

Agentic AI Foundation: OpenAI co-fonda lo standard aperto per gli agenti

L’industria si è mossa: la Linux Foundation ha annunciato la Agentic AI Foundation (AAIF) per costruire uno spazio neutrale e aperto attorno agli agenti. Non è solo governance: arrivano asset concreti. Anthropic dona il Model Context Protocol (MCP), Block porta Goose (framework open per agenti scalabili) e OpenAI contribuisce con AGENTS.md, un file di istruzioni che aiuta i tool di sviluppo a capire come interagire con un repository. Tra i fondatori compaiono anche AWS, Bloomberg, Cloudflare e Google. Tradotto: si prova a evitare un futuro di agenti chiusi e incompatibili.

Perché è una notizia che cambia i piani di progetto

In questi mesi ho visto tanti team impantanarsi in integrazioni ad hoc: plugin proprietari, gateway fatti in casa, policy replicate in modo incoerente. L’AAIF nasce per ribaltare la dinamica: protocolli per negoziare capacità, contesto e permessi, e framework che parlano la stessa lingua. Come ha notato Nick Cooper (OpenAI), non esisterà mai “un solo provider”: standard aperti sono l’unico modo per collaborare senza riscrivere colla ogni trimestre.

Schema concettuale di uno stack agentico aperto con protocolli e documenti condivisi come MCP, Goose e AGENTS.md

OpenAI non porta solo AGENTS.md. Nell’ultimo anno ha spinto su infrastruttura agentica aperta: Agents SDK, Apps SDK, Agentic Commerce Protocol, modelli open come gpt-oss e la Codex CLI (impiegata per supportare il merge di milioni di PR pubbliche). È anche tra i primi adottanti di MCP, che ha integrato come base per connettori e app in ChatGPT. In parallelo, Block dona Goose per dimostrare che si può scalare con un framework open; Anthropic punta a fare di MCP lo standard de facto per collegare modelli, strumenti e app senza adattatori infiniti.

Cosa significa, in pratica, per chi costruisce agenti

Tre impatti immediati:

Meno connettori su misura: MCP fornisce un “bus” coerente per strumenti e dati, locale o remoto.
Comportamento più prevedibile: AGENTS.md rende esplicite regole, confini e capacità per i tool che toccano un repo.
Deploy più semplice in ambienti con forti requisiti di sicurezza: standard aperti facilitano audit e segregazione.

Nel medio periodo, se gli standard prendono piede, potremo combinare agenti, tool e orchestration layer come pezzi LEGO: spostare un agente da un provider all’altro, collegarlo a un MCP server aziendale, farlo operare su repo istruiti da AGENTS.md e orchestrarlo con un framework come Goose. Il tutto senza ricablare tutto ogni volta.

AGENTS.md: un piccolo file che cambia il flusso

AGENTS.md è l’equivalente, nell’era degli agenti, di un README operativo: definisce cosa un tool può fare nel repository, con quali limiti e su quali processi. Ecco un esempio sintetico e realistico che uso come traccia mentale quando penso a repo “agent-ready”:

# AGENTS.md (esempio)
name: platform-repo
purpose: Linee guida per agenti e tool di coding che interagiscono con questo repository

capabilities:
  - open_issues
  - propose_changes
  - run_tests

boundaries:
  - non committare su main: apri sempre una PR
  - rispetta CODEOWNERS per le directory /infra e /security
  - non toccare i segreti: usa i placeholder documentati

governance:
  - conventional commits obbligatori
  - PR auto-merge solo se tutti i check passano e c'è almeno 1 approval umano

workflows:
  - test: make test && make lint
  - build: make build

context:
  - architettura: docs/adr/*.md
  - roadmap: docs/roadmap.md
  - policy: docs/security/policy.md

Non è magia: è disciplina. Mettere AGENTS.md accanto a README, CODEOWNERS e pipeline rende gli agenti prevedibili e auditabili. In aziende con compliance stretta, questo è spesso il pezzo mancante per sbloccare sperimentazioni controllate.

Vista di un IDE con un file AGENTS.md aperto e commenti che guidano un agente nelle azioni consentite sul repository

MCP e Goose: dove si innestano nella tua architettura

MCP si comporta come un livello di contesto e strumenti. Puoi esporre in modo omogeneo Jira, GitHub, Postgres on-prem, sistemi IoT o data lake. Gli agenti – che vivano su un SaaS o on-prem – negoziano capacità e API tramite MCP, senza dover scrivere un connettore dedicato per ogni combinazione. Goose, dal canto suo, fornisce un runtime per agenti scalabili, pensato per integrarsi nativamente con MCP e, in prospettiva, rispettare segnali operativi derivati da AGENTS.md.

Nota organizzativa non banale: l’AAIF usa un “fondo diretto”. Le aziende pagano quote, ma non controllano le roadmap dei progetti; a farlo sono comitati tecnici indipendenti. Questo è il tipo di garanzia che gli architetti chiedono prima di investire in uno standard.

Rischi, nodi aperti e come muoversi adesso

Il rischio numero uno è l’adozione: senza implementazioni diffuse, gli standard restano carta. Il numero due è la deriva di complessità: più estensioni, più superfici di attacco. La risposta è pragmatica:

Prototipare subito con un MCP server “thin” davanti a 2–3 sistemi aziendali usati ogni giorno.
Introdurre AGENTS.md nei repository attivi, partendo dai team che hanno già automation matura.
Valutare Goose dove serve orchestrare agenti persistenti o workload ad alto throughput.

Segnali positivi ci sono: AWS chiama MCP “infrastruttura critica” e player come Bloomberg e Cloudflare si stanno muovendo su adozioni reali. Come ricordava Jim Zemlin, però, il vero indicatore sarà vedere questi standard integrati nei prodotti commerciali e negli strumenti che usiamo tutti i giorni. E, soprattutto, la loro capacità di evolvere senza diventare un compromesso per tutti.

La posta in gioco è chiara: o avremo agenti interoperabili, auditabili, componibili – o torneremo a un arcipelago di silos. Con AAIF, MCP, Goose e AGENTS.md, per la prima volta c’è una traiettoria credibile verso il primo scenario. Io, intanto, ho iniziato a mettere AGENTS.md nei repo e a standardizzare i connettori su MCP. Meno colla, più architettura.