OpenAI lancerede 15. april en større opdatering af Agents SDK, og det er faktisk en vigtigere nyhed end endnu en benchmark-sejr eller modelversion med lidt højere score. Den nye version gør det muligt at bygge AI-agenter, som ikke bare svarer i en chatboks, men arbejder i en isoleret arbejdsflade med filer, kommandoer, artefakter og mulighed for at genoptage arbejdet senere. Det lyder teknisk, og det er det også. Men for udviklere og arkitekter er pointen enkel: OpenAI forsøger at flytte agent-byggeri fra demoer til drift.
Det interessante er ikke kun, at en agent nu kan få adgang til et sandbox-miljø. Det interessante er kombinationen af orkestrering og eksekvering. Ifølge OpenAI Developer Community får modellen et “harness” med instruktioner, tools, approvals, tracing, handoffs og resume-logik, mens selve sandkassen leverer compute, filer og isolation. Den opdeling er vigtig, fordi den gør det lettere at holde credentials, governance og overvågning adskilt fra det miljø, hvor modelgenereret kode faktisk kører.
Agents SDK er ikke bare endnu en agent-demo
Vi har efterhånden set mange agent-lanceringer, hvor AI må browse lidt, kalde et værktøj eller skrive en fil. Problemet kommer først, når løsningen skal bruges i virkeligheden. Hvad sker der, når en opgave varer længere end én request? Hvad sker der, hvis containeren dør undervejs? Og hvordan håndterer man, at agenten bør kunne læse noget, men ikke nødvendigvis skrive det tilbage?
Det er her, den nye Agents SDK bliver interessant. I dokumentationen beskriver OpenAI, at sandkasse-agenter især giver mening, når man har brug for workspace isolation, valg af sandbox-provider eller resumable filesystem state. Oversat til almindeligt dansk betyder det, at agenten kan arbejde i et kontrolleret miljø, hvor dens filer og mellemresultater bevares, selv hvis arbejdsgangen strækker sig over længere tid.
Det placerer OpenAI tættere på den type workflow, man normalt forbinder med udviklerværktøjer som CI/CD-pipelines, jobkøer og midlertidige build-miljøer. Hvis du allerede har læst mit indlæg om Cursor 3.1 og parallelle AI-agenter, er forskellen her, at OpenAI går ned i selve runtime-laget. Hvor Cursor primært handler om produktivitet i IDE’en, handler Agents SDK om infrastrukturen under agenten.
Det mest interessante er sikkerhed og drift, ikke bare features
OpenAI fremhæver, at orkestrering kan holdes uden for det miljø, hvor modelgenereret kode kører. Det er mere end et teknisk nicety. Det er et svar på et af de største problemer ved agent-baserede systemer: at vi ofte blander beslutningslogik, dataadgang og eksekvering sammen i én stor, sværkontrolleret bunke.
Når permissions kan knyttes til bestemte stier i et manifest, og når agenten kan få skriveadgang til output/ uden at få samme adgang til et følsomt datarum, bliver det pludselig mere realistisk at bruge agentteknologi i enterprise-scenarier. Det betyder ikke, at sikkerhedsproblemerne er løst. Det betyder, at OpenAI tager fat i de rigtige problemer.
Derudover er listen over understøttede sandbox-partnere bemærkelsesværdig. OpenAI nævner blandt andet Blaxel, Cloudflare, Daytona, E2B, Modal, Runloop og Vercel i dokumentationen. Det signalerer, at virksomheden ikke kun vil sælge én hosted oplevelse, men også gøre det lettere at koble agent-orkestrering sammen med eksisterende udviklerplatforme. Det minder på nogle måder om den platformisering, vi også ser hos Anthropic, som jeg tidligere har skrevet om i Claude Managed Agents. Forskellen er, at OpenAI her lægger ekstra vægt på sandkassen som et separat, flytbart lag.
Hvad betyder det for udviklere og IT-folk?
Hvis du bygger interne værktøjer, supportflows, kodeagenter eller automatisering i et driftssat miljø, er den nye Agents SDK interessant af tre grunde.
- Bedre robusthed: Snapshotting og rehydrering betyder, at længere forløb ikke nødvendigvis skal begynde forfra ved fejl eller timeout.
- Mere styrbar sikkerhed: Manifest, brugere og filrettigheder giver et mere præcist kontrolniveau end den klassiske “giv agenten adgang til det hele”.
- Mindre platform-lock-in på runtime-niveau: Når OpenAI understøtter flere sandbox-providers, bliver det lettere at tilpasse agenten til den infrastruktur, man allerede driver.
Det ændrer dog ikke ved, at agent-systemer stadig er svære at teste. Et mere avanceret runtime-lag kan gøre løsningen mere driftsegnet, men det kan også øge kompleksiteten. Flere moving parts betyder mere observability, mere policy-arbejde og flere steder, hvor ting kan fejle. Derfor bør man se OpenAIs Agents SDK som et modent byggesæt, ikke som en genvej til autonome systemer, der bare virker.
Min vurdering er, at dette er en mere strategisk lancering, end den umiddelbart ser ud til. Vi er ved at bevæge os fra “LLM som API-kald” til “agent som driftsenhed”. Når det sker, bliver sandboxing, resume-funktioner, tilladelser og sporbarhed vigtigere end endnu 5 point på en benchmark. Det er præcis derfor, at Agents SDK er værd at holde øje med lige nu.
Kilder
- The next evolution of the Agents SDK — OpenAI, 15. april 2026
- Sandbox Agents — OpenAI API documentation, april 2026
- The next evolution of the Agents SDK — OpenAI Developer Community, 15. april 2026
Denne artikel er skrevet i samarbejde med AI, og efterfølgende redigeret af et rigtigt menneske 🙂
