Slankere harnesses en agents die code uitvoeren, zijn beter geschikt voor open taken, waarbij te rigide orkestratie de prestaties van het model kan beperken.
Hierdoor zijn code-uitvoering en sandboxing nu belangrijke architectuurvraagstukken voor agentsystemen.
Agents SDK vermindert de complexiteit en hoeveelheid code die nodig zijn om agents te bouwen die code uitvoeren, in onze tests met maximaal een factor zes.
Lange tijd kwam de vooruitgang in agentsystemen voort uit betere orkestratie: betere prompts, toolinterfaces, contextbeheer en een strakkere besturingslogica. Maar nu programmeeragents steeds meer kunnen, begint die balans te verschuiven.
In veel open workflows is niet langer de agentlus zelf de bottleneck, maar de uitvoeringslaag: de sandbox waarin het model code schrijft, opdrachten uitvoert, resultaten inspecteert en iteraties doorvoert. Nu steeds meer redenering op taakniveau naar die omgeving verschuift, moet de omliggende orkestratie eenvoudiger worden, zodat het model zijn volledige potentieel kan benutten.
Precies die verschuiving wordt mogelijk gemaakt door de nieuwe versie van de Agents SDK. Tijdens onze tests in de vroege-toegangsfase bleek dat deze versie geen extra laag met frameworklogica toevoegt, maar de uitvoeringslaag juist modulairder en beter combineerbaar maakt, zodat de rest van het systeem slank kan blijven.
Binnen harness-engineering is het populair geworden om de harness terug te brengen tot zijn minimaal effectieve vorm. In grote lijnen is de harness de software rond het model: de laag die context, tools, besturingslogica en feedbacklussen beheert, zodat het model betrouwbaar werk kan uitvoeren.
De afgelopen jaren kwam een groot deel van de prestatieverbeteringen bij agents voort uit het versterken van die laag. Betere tools, beter geheugen en betere informatieontsluiting, explicietere opsplitsing en strakkere orkestratie maakten systemen vaak betrouwbaarder en krachtiger. Binnen dat paradigma betekende vooruitgang vooral dat meer taaklogica werd vastgelegd in de software rond het model.
Dat patroon wordt nu minder sterk, althans voor een bepaalde categorie open taken. Steeds meer projecten en onderzoeken wijzen erop dat de prestaties niet altijd verbeteren wanneer de harness meer voorschrijft. Bij ondersteund programmeren, langlopende taken, browsergebruik en taken met een lange context zien we steeds hetzelfde patroon: zodra het model intelligent genoeg is, kan te veel taakstructuur in de omliggende software eerder een beperking dan een voordeel worden.
De rol van de harness verandert dus. In plaats van vooraf op de taak te anticiperen met rigide orkestratie, dient de harness steeds vaker als een overzichtelijk uitvoeringsvlak: een sandbox waarin het model de status kan inspecteren, code kan uitvoeren, fouten kan herstellen en zijn aanpak kan aanpassen, binnen de interfaces en beveiligingsmaatregelen van het systeem. Dit sluit nauw aan bij de verschuiving die Andrej Karpathy beschreef in Software Engineer 3.0: een deel van de logica die voorheen in software zat, verschuift naar de "prompt".
De les is niet dat alle structuur uit agentsystemen moet verdwijnen. Veel taken profiteren nog steeds van expliciete workflows, heuristieken en deterministische vangrails, vooral wanneer de taak beperkt of grootschalig is of een duidelijk succescriterium heeft. Zoals we betoogden in ons eerdere artikel over Heuristieken voor het ontwerp van agentsystemen, blijft sterke orkestratie belangrijk wanneer een betrouwbare logische stroom zowel mogelijk als wenselijk is.
Bij open taken verschuift de aandacht. De uitdaging draait minder om het ontwerpen van steeds uitgebreidere orkestratielagen en meer om uitvoeringsomgevingen die eenvoudig, observeerbaar en modulair genoeg zijn om het model er effectief in te laten werken.
Zodra een agent bestanden kan lezen, code kan schrijven, shellopdrachten kan uitvoeren en langlopende taken kan starten, verandert de technische uitdaging. De moeilijkheid zit niet langer alleen in het optimaliseren van prompts of het routeren van tools. Doordat de agent nu op een echt systeem werkt, worden deze agents aanzienlijk krachtiger, maar ook gevoeliger, omdat het veiligheids- en beveiligingsoppervlak groter wordt. Een agent die code kan uitvoeren, kan bijvoorbeeld schadelijke handelingen verrichten als zijn omgeving onvoldoende geïsoleerd is (zie Sandbox Bench van het AISI).
Sandboxing wordt daarom een kritiek aandachtspunt in agentframeworks. In eerdere systemen werd uitvoering vaak als een uitbreiding behandeld: een tool die aan de harness was vastgemaakt. Maar zodra de uitvoering status behoudt, langdurig loopt of op afstand plaatsvindt, begint die aanpak tekort te schieten. Het beheer van de sandbox zelf, de levenscyclus, de status, de interfaces en de koppeling met de agentlus wordt al snel een zelfstandig systeemontwerpprobleem. Dat is een van de redenen waarom steeds meer providers beheerde omgevingen voor code-uitvoering aanbieden, waaronder de Container API en shelltool van OpenAI, Modal, Cloudflare, Daytona en E2B.
Deze scheiding is belangrijk, omdat code-uitvoering sterkere isolatie en strakker runtimebeheer vereist dan de rest van de harness. In de praktijk kunnen slecht geïmplementeerde agents die code uitvoeren drie bedrijfskritieke risico's veroorzaken: onbeheersbare rekenkosten, destructieve handelingen op interne systemen en blootstelling van gevoelige informatie. Met goede containerisatie, isolatie en runtimebeveiliging kunnen deze risico's worden teruggebracht tot een niveau dat aanvaardbaar is voor implementaties in de praktijk.
Je kunt het vergelijken met een agent die een eigen afgesloten werkruimte krijgt, in plaats van de sleutels van het hele kantoor. Binnen die ruimte kan de agent nog steeds nuttig werk verrichten, maar alleen binnen duidelijk vastgelegde grenzen. Je kunt het rekengebruik begrenzen, bepalen welke systemen en bestanden toegankelijk zijn en vooraf regelen welke informatie beschikbaar is.
Daarmee verdwijnt het risico niet volledig, maar verandert het probleem van "een agent die vrij rondgaat in je infrastructuur" in "een agent die binnen een gecontroleerde omgeving werkt". Als deze laag een standaardonderdeel van agentsystemen wordt, moet het framework zelf er volwaardige ondersteuning voor bieden. Zo wordt de sandbox een modulaire uitvoeringslaag met overdraagbare bouwstenen die ontwikkelaars snel kunnen gebruiken, tussen providers kunnen uitwisselen en kunnen opschalen zonder de agentlogica voortdurend te herzien.
Zodra een agent code uitvoert, moet ook de sandbox zelf worden georkestreerd. De stap van een lokaal proof of concept naar uitvoering op afstand, meerdere backends of langlopende sessies vergroot de operationele last exponentieel. Je hebt een consistente manier nodig om omgevingen aan te maken, te stoppen, te pauzeren en te hervatten, snapshots van de status te maken, later opnieuw verbinding te maken en dit alles bij verschillende providers te beheren.
Dit klinkt conceptueel niet bijzonder aantrekkelijk, maar is in de praktijk wel belangrijk. Dit is precies het soort infrastructuur dat problematisch wordt wanneer elk team zelf een agentpipeline vanaf nul opbouwt, vooral als die niet in het agentframework is geïntegreerd…
Hier wordt betere ondersteuning vanuit het framework belangrijk. We kregen vroegtijdig toegang tot de nieuwere OpenAI Agents SDK en gebruikten deze om zelf agents in sandboxes te bouwen. Wat opviel, was de verschuiving in de architectuur: de SDK behandelt uitvoering als een volwaardige laag en niet als een randtool. In de praktijk betekent dit dat je met minder code een agent in een sandbox kunt starten, een snapshot van een sandbox kunt maken of de uitvoering kunt hervatten (in sommige van onze tests met ongeveer zes keer minder code), en vervolgens van backend kunt wisselen zonder de omliggende agentlogica te herschrijven.
Dankzij deze duidelijkere scheiding van verantwoordelijkheden kan de harness gericht blijven op redenering, context en workflow. De uitvoeringslaag kan zich richten op isolatie, overdraagbaarheid en runtimestatus. Deze abstractie maakt het eenvoudiger om programmeeragents te bouwen die zowel krachtiger als makkelijker door te ontwikkelen zijn, tussen lokale uitvoering en uitvoering op afstand kunnen schakelen, langlopende taken ondersteunen en van uitvoeringsbackend kunnen wisselen zonder het hele systeem opnieuw te ontwerpen.
Nu meer taaklogica van de harness naar het model verschuift, verhuist een deel van de systeemcomplexiteit mee naar de uitvoeringslaag. Code-uitvoering en sandboxing zijn nu belangrijke architectuurvraagstukken voor agentsystemen, vooral bij programmeerintensieve en open taken. Het is nu even belangrijk om de agentpipeline te ontwerpen als de omgeving waarin de agent veilig, betrouwbaar en langdurig kan handelen.
Daarom zijn abstracties op hoger niveau voor uitvoering in sandboxes belangrijk. De nieuwere OpenAI Agents SDK zet een stap in die richting door uitvoering te behandelen als een modulaire systeemlaag: overdraagbaar tussen backends, met behoud van status tijdens langlopende taken en eenvoudig genoeg om te gebruiken zonder voor elke nieuwe configuratie dezelfde infrastructuur opnieuw te bouwen.
De bredere les is dat de volgende generatie agentframeworks waarschijnlijk minder wordt bepaald door de hoeveelheid orkestratielogica die ze toevoegen, en meer door hoe goed ze de uitvoeringsomgevingen structureren waarvan agents steeds afhankelijker worden.