Un agente che può eseguire comandi, modificare file e collegarsi a servizi esterni non è soltanto una chiamata API. È un processo con accesso a rete, credenziali e dati. La scelta dell’ambiente in cui farlo lavorare decide quanto tempo serve per partire e quanta superficie tecnica resta da gestire.
Il 10 settembre 2026 OpenAI ha presentato Agents API in public beta. Il servizio gestisce sessioni, orchestrazione, compattazione del contesto e ripresa del lavoro, ma lascia allo sviluppatore la scelta dell’ambiente di esecuzione. Le due opzioni da confrontare sono una sandbox gestita da OpenAI e un ambiente self-hosted. Il criterio non è quale sia più moderno: conta quale riduce il rischio operativo del singolo workflow senza trasformare l’infrastruttura in un progetto a parte.
Cosa resta uguale nelle due opzioni
La distinzione riguarda l’ambiente, non l’intero agente. In entrambi i casi Agents API usa il managed Codex harness per coordinare modello, strumenti, contesto e sessione. L’agente può eseguire codice, lavorare sui file, collegarsi a server MCP e produrre artefatti. Cambia chi prepara e mantiene lo spazio in cui avvengono queste operazioni.
Questa separazione è utile perché evita un confronto falsato. Non stiamo scegliendo tra “AI gestita” e “AI interna”. Il modello e l’orchestrazione restano nel servizio OpenAI; la decisione è dove mettere shell, filesystem, dipendenze e accesso ai sistemi aziendali.
Approccio A: sandbox gestita da OpenAI
La sandbox gestita fornisce un workspace Linux con Python, Node.js e strumenti da riga di comando. OpenAI lo crea e lo collega alla sessione; l’applicazione passa task e file, poi recupera risultati e artefatti. Si possono installare pacchetti, eseguire comandi di setup e caricare skill o plugin.
Il vantaggio principale è il tempo di messa in opera. Non serve costruire un’immagine, mantenere un executor o gestire la riconnessione del processo. Per un prototipo che analizza esportazioni CSV, prepara report o controlla file prima di un import WordPress, è una base sensata. Anche il ciclo di vita è dichiarato: i file restano disponibili tra i turni finché esiste la sandbox, mentre ciò che viene salvato in /workspace/outputs diventa un artefatto scaricabile. Se attività e keep-alive si fermano per un’ora, la sandbox può essere eliminata.
La rete richiede una scelta esplicita. Nella configurazione gestita l’accesso outbound è abilitato per impostazione predefinita, ma può essere disattivato oppure ristretto a un elenco di host. Per una pipeline che deve leggere due endpoint e scrivere su WordPress, lascerei passare soltanto quei domini. Una sandbox veloce da avviare con rete aperta non è una scorciatoia accettabile.
I contro sono il costo del container oltre a token e tool, la durata non pensata come storage permanente e i limiti di un ambiente standardizzato. Se servono un’immagine di sistema particolare, hardware specifico o una rete privata, la documentazione indica di scegliere il self-hosting.
Approccio B: ambiente self-hosted
Nel self-hosting l’ambiente può essere un laptop, un container o una sandbox remota. OpenAI continua a eseguire l’harness, mentre l’azienda avvia codex exec-server nel proprio ambiente. L’executor apre connessioni outbound verso l’API e il servizio WebSocket, riceve i comandi, esegue le operazioni locali e restituisce i risultati.
Qui il vantaggio è il controllo. Si può usare un’immagine già approvata, tenere l’esecuzione vicino a staging, database o storage privati e applicare policy di rete già esistenti. Per un’agenzia che deve lavorare su più installazioni WordPress, un container per cliente permette di montare configurazioni e strumenti senza copiarli in un workspace esterno a ogni sessione.
Quel controllo porta lavoro. Bisogna preparare dipendenze, monitorare l’executor, gestire aggiornamenti e isolare gli ambienti per utente o carico. OpenAI avverte che agenti nello stesso ambiente possono accedere agli stessi file e alle stesse credenziali. Condividere un container tra clienti non è quindi un’ottimizzazione: è un errore di separazione.
L’autenticazione va progettata con la stessa disciplina. L’executor usa una chiave limitata alla connessione dell’ambiente; la chiave API più ampia deve restare fuori. La chiave ristretta non va comunque inserita nel codice, nell’immagine del container o nei log. Il self-hosting dà più leve, ma rende il team responsabile del loro uso corretto.
Il confronto operativo
| Criterio | Sandbox gestita | Self-hosted |
|---|---|---|
| Avvio | Setup dichiarativo nella sessione | Ambiente ed executor da predisporre |
| Rete | Disabled, restricted o enabled | Policy e connettività sotto il proprio controllo |
| Dipendenze | Pacchetti e comandi di setup | Immagine e toolchain personalizzabili |
| Persistenza | Workspace legato alla sandbox, output esportabili | Storage gestito secondo l’architettura interna |
| Carico operativo | Più basso, container fatturato a parte | Più alto, infrastruttura e monitoraggio propri |
Quando cresce il volume, le rotture sono diverse. Nella sandbox gestita pesano setup non riproducibili, domini dimenticati nella allowlist e dipendenze installate senza versione. Nel self-hosting pesano capacità, patch, code bloccate e isolamento insufficiente. In entrambi i casi una sessione completata non prova che ogni tool abbia funzionato: l’applicazione deve leggere eventi e risultati, poi decidere se accettare l’output.
WordPress, automazioni e dati delle PMI
Per WordPress partirei da un task senza effetti irreversibili: audit di plugin, controllo di un export o preparazione di una bozza. La sandbox gestita è adatta se riceve file selezionati e raggiunge soltanto endpoint REST limitati. Le credenziali devono avere permessi minimi, come già vale per la gestione di spesa e permessi degli agenti AI.
Passerei al self-hosting quando l’agente deve accedere spesso a una rete privata, usare tool proprietari o elaborare file che non devono essere copiati in un nuovo ambiente. La scelta non elimina la necessità di una policy dati. Bisogna stabilire cosa entra nella sessione, cosa finisce nei log e quanto viene conservato, lo stesso controllo richiesto quando si confrontano retention del fornitore e log interni.
Per entrambi gli approcci imporrei tre gate: ambiente isolato per workflow, rete chiusa al minimo e approvazione umana prima di pubblicare, cancellare o inviare dati. L’agente può preparare una modifica WordPress; la promozione live resta un’azione separata e verificabile.
Take finale: gestita prima, self-hosted quando serve davvero
Per una PMI sceglierei la sandbox gestita per il primo progetto. Riduce il tempo speso su un executor che non crea valore per il cliente e permette di misurare subito qualità, durata e costo del workflow. La configurerei però con rete restricted, pacchetti versionati e output espliciti.
Il self-hosting diventa la scelta giusta quando esiste un requisito concreto: rete privata, immagine controllata, hardware specifico o integrazione continua con sistemi interni. “Vogliamo più controllo” non basta. Se il team non ha già monitoraggio, patching e isolamento solidi, quel controllo è solo responsabilità non gestita.