Infrastrutture più snelle e agenti in grado di eseguire codice sono più adatti alle attività aperte, in cui un'orchestrazione troppo rigida può limitare le prestazioni del modello.
Di conseguenza, l'esecuzione di codice e il sandboxing sono ormai aspetti architetturali fondamentali per i sistemi basati su agenti.
Agents SDK riduce la complessità e il codice necessari per creare agenti in grado di eseguire codice: nei nostri test, fino a 6 volte.
Per molto tempo, i progressi nei sistemi basati su agenti sono derivati dal miglioramento dell'orchestrazione: prompt più efficaci, interfacce degli strumenti migliori, gestione del contesto e flussi di controllo più rigorosi. Ma con l'aumentare delle capacità degli agenti di programmazione, questo equilibrio sta iniziando a cambiare.
In molti flussi di lavoro aperti, il collo di bottiglia non è più il ciclo dell'agente, ma il livello di esecuzione: la sandbox in cui il modello scrive codice, esegue comandi, esamina i risultati e procede per iterazioni. Man mano che una parte maggiore del ragionamento relativo all'attività si sposta in quell'ambiente, l'orchestrazione circostante deve semplificarsi per consentire al modello di esprimere tutte le sue capacità.
È proprio questo cambiamento che rende possibile la nuova versione di Agents SDK. Nei test svolti durante l'accesso anticipato, abbiamo riscontrato che, anziché aggiungere un ulteriore livello di logica del framework, rende il livello di esecuzione più modulare e componibile, permettendo al resto del sistema di rimanere snello.
Nell'ingegneria dell'infrastruttura è diventato comune ridurre l'infrastruttura alla sua forma minima efficace. In termini generali, l'infrastruttura è il software che circonda il modello: il livello che gestisce contesto, strumenti, flusso di controllo e cicli di feedback affinché il modello possa operare in modo affidabile.
Negli ultimi anni, molti miglioramenti nelle prestazioni degli agenti sono derivati dal potenziamento di questo livello. Strumenti, memoria e recupero delle informazioni migliori, una scomposizione più esplicita e un'orchestrazione più rigorosa hanno spesso reso i sistemi più affidabili e capaci. In questo paradigma, progredire significava soprattutto integrare una parte maggiore della logica dell'attività nel software che circonda il modello.
Ora questo schema sta perdendo forza, almeno per una categoria di attività aperte. Un numero crescente di progetti e studi indica che le prestazioni non migliorano necessariamente quando l'infrastruttura diventa più prescrittiva. Nella programmazione assistita, nelle attività di lunga durata, nell'uso del browser e nelle attività con contesti estesi, emerge ripetutamente lo stesso schema: quando il modello è abbastanza intelligente, imporre una struttura eccessiva all'attività tramite il software circostante può trasformarsi in un vincolo anziché in un vantaggio.
Il ruolo dell'infrastruttura sta quindi cambiando. Anziché cercare di prevedere in anticipo l'attività tramite un'orchestrazione rigida, l'infrastruttura serve sempre più a fornire un ambiente di esecuzione essenziale: una sandbox in cui il modello può esaminare lo stato, eseguire codice, correggere gli errori e adattare il proprio approccio, pur restando entro i limiti delle interfacce e delle misure di sicurezza del sistema. Questo cambiamento è simile a quello descritto da Andrej Karpathy in Software Engineer 3.0: parte della logica che prima risiedeva nel software si sposta a un livello superiore, nel «prompt».
Ciò non significa che i sistemi basati su agenti debbano eliminare ogni struttura. Molte attività continuano a beneficiare di flussi di lavoro espliciti, euristiche e vincoli deterministici, soprattutto quando sono circoscritte, eseguite su larga scala o hanno un chiaro criterio di successo. Come abbiamo sostenuto nel precedente articolo sulle euristiche per la progettazione di sistemi basati su agenti, un'orchestrazione solida resta importante quando un flusso logico affidabile è possibile e auspicabile.
Per le attività aperte, l'attenzione si sta spostando. La sfida non consiste più tanto nel progettare livelli di orchestrazione sempre più elaborati, quanto nel creare ambienti di esecuzione semplici, osservabili e abbastanza modulari da consentire al modello di operarvi in modo efficace.
Quando un agente è in grado di leggere file, scrivere codice, eseguire comandi shell e avviare attività di lunga durata, la sfida ingegneristica cambia. La difficoltà non risiede più soltanto nell'ottimizzazione dei prompt o nell'instradamento degli strumenti. Il fatto che l'agente operi ora su un sistema reale rende questi agenti molto più potenti, ma anche più delicati, perché amplia la superficie esposta a rischi di sicurezza e protezione. Ad esempio, un agente in grado di eseguire codice può compiere azioni dannose se il suo ambiente non è adeguatamente isolato (si veda Sandbox Bench dell'AISI).
Il sandboxing sta quindi diventando un aspetto cruciale nei framework per agenti. Nei sistemi precedenti, l'esecuzione era spesso considerata un componente aggiuntivo: uno strumento innestato sull'infrastruttura. Ma quando l'esecuzione diventa persistente, di lunga durata o remota, questo approccio inizia a mostrare i suoi limiti. Gestire la sandbox, il suo ciclo di vita, lo stato, le interfacce e l'integrazione con il ciclo dell'agente diventa rapidamente un problema autonomo di progettazione del sistema. È uno dei motivi per cui un numero crescente di provider offre ambienti gestiti per l'esecuzione di codice, tra cui Container API e lo strumento shell di OpenAI, Modal, Cloudflare, Daytona, E2B e altri.
Questa separazione è importante perché l'esecuzione di codice richiede un isolamento più robusto e un controllo del runtime più rigoroso rispetto al resto dell'infrastruttura. In pratica, agenti che eseguono codice e sono implementati male possono introdurre tre rischi critici per l'azienda: costi di elaborazione incontrollati, azioni distruttive sui sistemi interni ed esposizione di informazioni sensibili. Con un'adeguata containerizzazione, isolamento e protezioni del runtime, questi rischi possono essere contenuti a un livello accettabile per le implementazioni nel mondo reale.
Un modo per comprenderlo è immaginare di assegnare all'agente uno spazio di lavoro isolato anziché consegnargli le chiavi dell'intero ufficio. Può comunque svolgere attività utili al suo interno, ma solo entro limiti chiaramente definiti. È possibile limitare le risorse di elaborazione che utilizza, i sistemi e i file a cui può accedere e le informazioni messe a sua disposizione fin dall'inizio.
Questo non elimina completamente il rischio, ma trasforma il problema da «un agente libero di agire nella tua infrastruttura» a «un agente che opera in un ambiente controllato». Se questo livello è destinato a diventare un componente standard dei sistemi basati su agenti, deve ricevere un supporto nativo nel framework stesso. La sandbox diventa così un livello di esecuzione modulare con primitive portabili, che gli sviluppatori possono adottare rapidamente, trasferire tra provider e scalare senza dover rielaborare continuamente la logica degli agenti.
Quando un agente esegue codice, anche la sandbox deve essere orchestrata. Passare da una prova di fattibilità locale all'esecuzione remota, a più backend o a sessioni di lunga durata aumenta esponenzialmente l'onere operativo. Serve un metodo uniforme per creare e arrestare gli ambienti, sospenderli e riprenderli, acquisire istantanee dello stato, riconnettersi in seguito e gestire tutto questo tra diversi provider.
Nulla di tutto ciò è particolarmente affascinante sul piano concettuale, ma nella pratica è importante. È proprio il tipo di infrastruttura che diventa onerosa quando ogni team ricostruisce da zero una pipeline basata su agenti, soprattutto se non è integrata nel relativo framework…
È qui che diventa importante un supporto migliore da parte del framework. Abbiamo avuto accesso anticipato alla nuova versione di OpenAI Agents SDK e l'abbiamo usata per creare agenti in ambienti sandbox. Ciò che ci ha colpito è stato il cambiamento delle priorità architetturali: l'SDK considera l'esecuzione un livello fondamentale anziché uno strumento periferico. In pratica, è possibile avviare un agente in una sandbox, acquisire un'istantanea della sandbox o riprendere l'esecuzione con meno codice (circa 6 volte meno in alcuni dei nostri test), per poi cambiare backend senza riscrivere la logica circostante dell'agente.
Questa separazione più netta delle responsabilità consente all'infrastruttura di concentrarsi su ragionamento, contesto e flusso di lavoro. Il livello di esecuzione può concentrarsi su isolamento, portabilità e stato del runtime. Questa astrazione semplifica la creazione di agenti di programmazione più capaci e facili da evolvere, in grado di passare dall'esecuzione locale a quella remota, supportare attività più lunghe e cambiare backend di esecuzione senza dover riprogettare l'intero sistema.
Man mano che una parte maggiore della logica dell'attività passa dall'infrastruttura al modello, anche parte della complessità del sistema si sposta con essa, verso il livello di esecuzione. L'esecuzione di codice e il sandboxing sono ormai aspetti architetturali fondamentali per i sistemi basati su agenti, soprattutto nelle attività aperte e ad alta intensità di programmazione. Progettare l'ambiente in cui l'agente può operare in modo sicuro, affidabile e continuativo è ormai importante quanto progettare la pipeline basata su agenti.
Per questo sono importanti le astrazioni di livello superiore per l'esecuzione in sandbox. La nuova versione di OpenAI Agents SDK procede in questa direzione, trattando l'esecuzione come un livello modulare del sistema: portabile tra backend, capace di conservare lo stato durante le attività di lunga durata e abbastanza semplice da usare senza ricostruire la stessa infrastruttura per ogni nuova configurazione.
In termini più generali, la prossima generazione di framework per agenti sarà probabilmente definita non tanto dalla quantità di logica di orchestrazione aggiunta, quanto dalla capacità di strutturare gli ambienti di esecuzione da cui gli agenti dipendono sempre più.