OpenAI Agents SDK voegt native sandboxen, geheugen en harnasbesturingselementen toe voor productieagenten
OpenAI's Agents SDK-release van 15 april is niet zomaar een SDK-update. Het is een stap hogerop: van modeltoegang en toolaanroepen naar de runtimelaag die feitelijk bepaalt of een agent veilig, duurzaam en betaalbaar is om te gebruiken.
Wat OpenAI daadwerkelijk heeft verzonden
OpenAI zegt dat de bijgewerkte SDK ontwikkelaars nu een model-native harnas biedt waarmee ze bestanden kunnen inspecteren, opdrachten kunnen uitvoeren, code kunnen bewerken en taken over een lange horizon kunnen uitvoeren. De release voegt configureerbaar geheugen, shell- en patch-primitieven toe, ondersteuning voor MCP en progressieve openbaarmaking in skills-stijl, plus native sandbox-uitvoering met een draagbaar manifestmodel voor het vormgeven van de werkruimte.
De praktische verschuiving is dat OpenAI meer van het saaie maar dure deel van agent-engineering inpakt: hoe bestanden moeten worden aangekoppeld, waar de uitvoer naartoe gaat, hoe runs worden hersteld nadat een container is uitgevallen, en hoe inloggegevens uit door modellen gegenereerde uitvoeringsomgevingen kunnen worden geweerd.
Waarom dit belangrijker is dan een andere toollijst
De meeste agentdemo's mislukken in productie om dezelfde redenen: sandboxes worden pas laat aan elkaar geplakt, de promptstatus wordt vermengd met de runtimestatus en elke nieuwe poging begint helemaal opnieuw. Dat verandert een slim prototype in een tokenlek. OpenAI probeert duidelijk het standaardpad eigenzinniger te maken: een gecontroleerde werkruimte, een duidelijkere harnasgrens en duurzame uitvoering via snapshotting en rehydratatie.
Dat is van belang voor teams die codeeragenten, onderzoeksagenten, QA-agenten en interne workflowautomatiseringen bouwen. De SDK lijkt nu minder op een verpakking rond modelaanroepen en meer op een referentiearchitectuur voor hoe OpenAI denkt dat productieagenten moeten worden gebouwd.
De TRH-invalshoek: runtime-fouten zijn symbolische verspilling
Bouwers concentreren zich vaak op modelkeuze en negeren de runtime-vorm. Dat is achteruit. Een sterk model in een luidruchtig harnas verspilt nog steeds tokens. Grote geheugenopslagplaatsen, te tolerante tools en hergebruikte sandboxes zorgen ervoor dat agenten meer status verzamelen dan de taak vereist. Het resultaat is herhaalde bestandsinspectie, verouderde aannames en extra redeneerlussen die het uiteindelijke artefact nooit veranderen.
Als je meer verzonden werk per betaald abonnement wilt, ontwerp dan het harnas zoals je infra ontwerpt. Bepaal wat de agent kan lezen, waar hij kan schrijven, welke tools hij kan aanroepen, welke status een checkpoint heeft en wanneer een run moet stoppen in plaats van naar meer context te zoeken.
Wat bouwers vervolgens moeten doen
Voor net nieuwe agenten begint u met de kleinste sandbox en het kleinste geheugenoppervlak waarmee de taak nog steeds kan slagen. Bewaar referenties buiten door agenten uitgevoerde berekeningen. Registreer de verhouding tussen de verzamelde context, de aangeroepen tools en de daadwerkelijk gewijzigde bestanden. Als die verhouding blijft stijgen, leert uw agent de verkeerde gewoonte aan.
Voor bestaande automatiseringen is deze release een goede forceerfunctie om te controleren of uw huidige harnas te veel maatwerk doet dat de SDK nu veiliger kan bezitten.