OpenAI lancia l’Agents API in beta pubblica: agenti a lunga durata, sandbox a scelta tua

Il 10 settembre 2026 OpenAI ha aperto in beta pubblica l’Agents API, e la notizia non è “un’altra API per fare agenti”. È che l’harness, il pezzo di software che tiene in piedi il ciclo ragiona-chiama-strumento-riprova, smette di essere un problema da risolvere in casa e diventa un servizio che si compra. Parlare di OpenAI Agents API in azienda significa però riaprire una domanda che le aziende italiane si erano già poste con ChatGPT Work e con i primi agenti custom: cosa conviene costruire, cosa conviene comprare, e soprattutto cosa resta scoperto in mezzo.

In questo articolo scoprirai:

• Cosa ha lanciato OpenAI: l'harness di Codex diventa un servizio gestito
• Quanto costa l'Agents API e cosa si paga davvero
• Il problema che l'Agents API risolve davvero: il loop
• Cosa l'Agents API non risolve quando la porti in azienda
• Build vs buy: perché anche comprare dall'hyperscaler resta a metà strada

Cosa ha lanciato OpenAI: l’harness di Codex diventa un servizio gestito

La documentazione ufficiale è esplicita sulla divisione del lavoro: OpenAI gestisce «sessioni, orchestrazione, compattazione del contesto e recupero», mentre l’applicazione fornisce gli strumenti custom, le istruzioni e sceglie dove girare il codice. È lo stesso harness che alimenta Codex e ChatGPT for Work, impacchettato dietro una singola chiamata API, come conferma l’annuncio di OpenAI.

L’ambiente di esecuzione è la vera novità di governance: si può usare la sandbox ospitata da OpenAI, la propria infrastruttura, oppure uno dei nove partner certificati, Blaxel, Cloudflare, Daytona, DigitalOcean, E2B, Modal, Oracle, Runloop e Vercel, elencati nella rassegna di VKTR. Chi ha vincoli di VPC non è costretto a spostare l’esecuzione fuori dal proprio perimetro. La sandbox ospitata da OpenAI, secondo l’annuncio del 10 settembre sul forum sviluppatori, supporta esecuzione di codice, manipolazione file e generazione di artefatti, con CPU, GPU e memoria configurabili.

Agents API o Agents SDK: qual è la differenza

La confusione è legittima, perché fino a ieri la risposta standard nel forum OpenAI era che «Agents non è un’API, è un SDK». Oggi convivono due cose diverse: l’Agents SDK è una libreria open source che gira sui tuoi server, l’Agents API è un runtime gestito che gira sui server di OpenAI. Con l’SDK il loop lo mantieni tu; con l’API lo mantiene OpenAI e tu ne consumi il risultato. La documentazione dell’API menziona gpt-6-astra come modello di riferimento per gli agenti, e supporta la connessione a server esterni via Model Context Protocol, indicando server_label e server_url nella configurazione dei tool.

Quanto costa l’Agents API e cosa si paga davvero

Sul prezzo di listino la risposta è semplice: non c’è una fee per l’API in sé, si pagano solo token e strumenti consumati, mentre le sandbox ospitate seguono le tariffe standard dei container con l’addebito dei modelli separato. È la stessa logica commerciale delle altre API di OpenAI: nessun canone, consumo puro.

Il costo vero è un altro, ed è quello che sorprende i team alla seconda settimana di produzione. Un agente che lavora in loop accumula contesto a ogni turno, e il conto cresce in modo non lineare: un team citato da eesel AI raccontava di spendere «200 dollari al giorno» e di pagare «oltre 100.000 token a ogni chiamata al modello» al decimo turno. La context compaction automatica dell’Agents API attenua il problema, è esattamente il pezzo di ingegneria che prima scrivevi a mano, ma non lo cancella: sposta la variabile dalla tua codebase alla tua bolletta.

Su questo punto deepsense.ai, che ha avuto accesso anticipato, è netto: «Gli agenti rendono i confronti a livello di token sempre più incompleti». Tradotto per un CFO: il costo per task diventa più difficile da preventivare, non più facile, e va misurato per processo, non per chiamata. Chi arriva da un budget AI costruito sul costo-per-token si trova a rifare il modello economico da capo.

Il problema che l’Agents API risolve davvero: il loop

Vale la pena riconoscere cosa OpenAI ha tolto dal tavolo, perché non è poco. La sintesi migliore è quella dell’analista Amit Kumar Jena, citato da InfoWorld: «Un agente a lunga durata costruito a mano ha bisogno di una coda di job, un database di stato, una flotta di sandbox, una routine di compattazione e una politica di retry». Sono cinque componenti infrastrutturali che ogni team che ha provato a mettere un agente in produzione ha dovuto costruire, testare e mantenere, e che ora arrivano gestiti.

Il secondo guadagno è la persistenza, ed è il pezzo che rende credibile la formula «agente a lunga durata». Quello che sopravvive fra un turno e l’altro è la sessione: secondo la documentazione ufficiale è OpenAI a farsi carico di «sessioni, orchestrazione, compattazione del contesto e recupero», cioè della cronologia dei messaggi, delle chiamate agli strumenti e dei loro risultati, che vengono compattati quando la finestra si riempie invece di essere buttati. Sul lato esecuzione, la sandbox ospitata conserva i file e gli artefatti prodotti dall’agente (forum sviluppatori), perciò alla ripresa l’agente ritrova il lavoro dove l’aveva lasciato invece di ripartire da zero. È la differenza fra un processo che dura giorni e uno che dura finché regge una singola chiamata. Come osserva Analytics Insight, su questa base gli agenti possono delegare attività specializzate a sotto-agenti e consolidarne i risultati: l’orchestrazione multi-agente, che nei framework DIY è la parte più fragile, qui è nativa.

C’è anche un vantaggio meno visibile e più strategico, segnalato da CellCog: chi mantiene un harness proprio deve rimetterci mano a ogni nuova release di modello, «sottraendo tempo prezioso al miglioramento della propria applicazione». Con un harness gestito, i miglioramenti del modello arrivano senza riscrivere l’orchestrazione. Per chi lavora con gli agenti AI da più di un anno, questo è il costo nascosto che pesa di più.

Cosa l’Agents API non risolve quando la porti in azienda

Qui finisce la parte facile. L’Agents API risolve il problema tecnico del loop, non il problema operativo dell’azienda. La formulazione più chiara è ancora di eesel AI: «L’Agents API di OpenAI è infrastruttura: la materia prima con cui assembli un agente, più il loop, le valutazioni e il monitoraggio che costruisci e mantieni da solo». Materiale grezzo, non soluzione chiavi in mano.

Quello che resta scoperto è esattamente ciò che distingue un prototipo da un agente che lavora: l’accesso ai dati aziendali (chi glieli espone, in che formato, con quale freschezza), i permessi (un agente che legge il CRM deve vedere quello che vede il commerciale o quello che vede il direttore?), l’integrazione con ERP e gestionali che parlano protocolli di vent’anni fa, il monitoraggio e il reporting. La knowledge base va configurata a mano; le integrazioni verticali restano a carico di chi costruisce. E i guardrail in ingresso e in uscita, controlli su jailbreak, su temi fuori perimetro, su allucinazioni prima della risposta, vanno progettati, non arrivano di default.

Human in the loop: chi approva e quando

Il punto più sottovalutato riguarda l’handover a una persona. deepsense.ai lo dice senza giri di parole: «L’human in the loop ha bisogno di un modello operativo». Non è una funzione da attivare, è una procedura da scrivere: chi approva, entro quanto, cosa succede se non risponde. E c’è una domanda ancora più scomoda, sempre dal loro test: «Se l’esecuzione si interrompe dopo un’azione esterna, il sistema è in grado di stabilire se quell’azione è andata a termine?». Se l’agente ha emesso un ordine e poi si è fermato, l’ordine è partito o no? La risposta non sta nell’API: sta nel modo in cui hai disegnato il processo, cioè in chi scrive quel modello operativo. Ed è la stessa scelta che separa un agente chiavi in mano da uno self-service: nel primo caso le procedure di approvazione e di recupero arrivano già scritte e presidiate da chi te lo consegna, nel secondo tocca a te definirle e mantenerle.

Build vs buy: perché anche comprare dall’hyperscaler resta a metà strada

Il segnale di mercato è chiaro e va letto per quello che è: OpenAI scommette che il layer infrastrutturale dell’agente diventi un servizio gestito, come è successo ai database e alle code di messaggi. Ma “comprare dall’hyperscaler” non chiude la partita, per tre ragioni concrete.

La prima è il lock-in. Sempre su InfoWorld, lo stesso analista avverte: «Se OpenAI fornisce il modello, la gestione del contesto, gli strumenti, l’orchestrazione e l’ambiente di esecuzione, passare a un’altra piattaforma diventa più difficile», con la conseguenza che la dipendenza «può anche indebolire la posizione negoziale dell’azienda sui prezzi». Non è un argomento per non adottarla: è un argomento per sapere in anticipo quali pezzi vuoi tenere portabili. La seconda è un vincolo duro e verificabile: nella beta la residenza dei dati è solo USA e non c’è supporto Zero Data Retention, nemmeno usando una sandbox propria. Per sanità, banche e assicurazioni in Europa questo, oggi, è un fermo.

La terza è competitiva: lo spazio è già affollato, Claude Managed Agents di Anthropic, Amazon Bedrock AgentCore, Microsoft Foundry Agent Service, LangGraph, e la piattaforma API di Perplexity, e chi ha una strategia multi-modello tende a preferire architetture ibride.

È il motivo per cui, come abbiamo argomentato altrove, nell’agente enterprise il servizio conta più del modello: il modello lo cambi in sei mesi, il processo che gli hai costruito intorno no. Vale soprattutto per chi sta valutando ChatGPT Work contro un agente custom, che è poi la stessa scelta vista dal lato dell’acquirente.

Cosa fare adesso se la tua azienda vuole provarci

Il consiglio operativo è banale e per questo viene ignorato: scegli un processo solo, misurabile, con un proprietario umano, e portalo fino in fondo. Non un pilota generico, ma un caso dove sai già dire quanto costa oggi in ore e in errori. L’Agents API ti risparmia la coda dei job, il database di stato e la politica di retry; non ti risparmia la decisione su chi può leggere cosa, né la scrittura delle procedure di approvazione. Chi ha seguito gli annunci dal DevDay di OpenAI sa che la parte difficile non è mai stata la tecnologia.

È esattamente qui che in MIMIR lavoriamo: non vendiamo solo l’agente, accompagniamo l’onboarding: mappare il processo, collegare i dati e i permessi che l’agente deve rispettare, definire dove interviene una persona e come si misura il risultato. Se hai un’esigenza aziendale su AI e agenti e vuoi capire se il tuo caso regge il passaggio dal prototipo alla produzione, parliamone: una valutazione onesta di fattibilità vale più di sei mesi di sperimentazione a vuoto.

Fonti:

• OpenAI, Introducing the Agents API
• OpenAI Developers, Agents API, overview della documentazione
• OpenAI Community, Introducing the Agents API and hosted sandboxes
• InfoWorld, OpenAI launches managed Agents API for enterprise AI agent development
• deepsense.ai, Early access to OpenAI’s Agents API: test su workflow enterprise
• VKTR, OpenAI launches managed Agents API for cloud-based agents
• Analytics Insight, OpenAI Agents API: features, architecture, use cases
• eesel AI, Cosa è davvero l’OpenAI Agents API
• CellCog, OpenAI Agents API, analisi