Programmatic tool calling: når LLM-agenten skriver sin egen orkestrering

OpenAI har gjort GPT-5.6 generelt tilgængelig, men den mest praktiske nyhed for udviklere er ikke endnu et benchmark-tal. Det er programmatic tool calling i Responses API: modellen kan skrive JavaScript, der koordinerer flere tool calls i en isoleret V8-runtime.

Det lyder som en detalje i API-dokumentationen. Det er det ikke. Hvis du bygger LLM-agenter, flytter noget af agentens kontrolflow fra din egen applikationskode ind i modellens runtime. Det kan gøre tool-tunge workflows billigere og hurtigere. Det kan også gøre dårlige tool-kontrakter dyrere, fordi en fejl ikke bare bliver til ét forkert kald. Den kan blive gentaget i en løkke.

Det gamle agent-loop er dyrt

Den klassiske function-calling-model er enkel: modellen beder om et tool call, applikationen udfører kaldet, resultatet sendes tilbage, og modellen beslutter næste trin. Fire opslag giver ofte fire runder. Fyrre opslag kan give fyrre runder.

Det er ikke kun ventetid. Hver runde trækker tidligere resultater med tilbage i konteksten, og det gør især ondt i workflows med mange opslag, filtrering, sammenligning og validering. Tænk prissammenligning, lagercheck, dokumentklassifikation eller en intern supportagent, der skal slå op i flere systemer før den svarer.

OpenAI beskriver selv GPT-5.6 som en familie med Sol, Terra og Luna, hvor Sol er topmodellen, Terra er den balancerede model, og Luna er den billige volumenmodel. Men programmatic tool calling er mere interessant end navngivningen, fordi det ændrer hvor orkestreringen ligger. I stedet for at applikationen skal styre hvert lille skridt, kan modellen skrive et lille program, der kalder godkendte tools, samler resultaterne og returnerer en mindre struktureret pakke.

Sandboxen er ikke det samme som sikkerhed

OpenAI skriver, at programmerne kører i en frisk, isoleret V8-runtime uden Node.js, pakkeinstallation, direkte netværksadgang, generelt filsystem, subprocesser eller persistent JavaScript-state. Det er godt. Det betyder, at modellens kode ikke frit kan hente en URL eller åbne en socket.

Men sikkerhedsgrænsen er stadig dine tools. Hvis du eksponerer et tool, der kan læse kundedata, ændre ordrestatus eller sende mails, så er det stadig et privilegeret interface. Forskellen er, at tool’et nu kan blive kaldt fra modelskrevet kode med løkker og betingelser. Det kræver mere præcise JSON-skemaer, tydelige fejlformater og hårde grænser for rate, idempotens og sideeffekter.

Det matcher den bredere driftspointe fra tidligere indlæg om prompt injection som kontrolplansproblem. Agentens tool-lag er ikke bare en convenience-feature. Det er en produktionsgrænse. Når en model kan komponere mange kald selv, bliver auditloggen og approval-boundary’en vigtigere end den pæne demo.

Hvornår giver programmatic tool calling mening?

OpenAI anbefaler selv programmatic tool calling til opgaver med forudsigeligt kontrolflow, hvor kode kan reducere mange mellemresultater til et mindre struktureret svar. Det er en fornuftig afgrænsning.

Brug det til opslag, join, deduplikering, rangering og simpel validering. Brug direkte tool calling, når hvert resultat kræver ny semantisk vurdering, når der er brugerapproval, eller når du skal bevare citater og originale artefakter. Det sidste punkt er vigtigt. Hvis en agent skal dokumentere, hvorfor den traf en beslutning, må programmet ikke bare returnere en glat opsummering og smide beviserne væk.

For danske teams, der bygger interne agenter, er den praktiske konsekvens ret jordnær: begynd ikke med at slå funktionen til overalt. Start med en baseline. Mål direkte tool calling mod programmatic tool calling på 20-30 repræsentative opgaver. Kig ikke kun på tokenforbrug og latency. Mål også korrekthed, manglende evidens, fejl ved tomme svar og om agenten overholder godkendelsesgrænserne.

Agentarkitektur bliver mere API-arkitektur

Den vigtigste designændring er, at tools skal behandles som rigtige API’er. Ikke som tynde wrappers rundt om interne funktioner, der kun kaldes af en venlig chatbot. Et tool skal have et stramt inputskema, et outputskema, klare fejltyper og en begrænset rettighedsmodel.

Det hænger direkte sammen med modelrouting og AI FinOps. I et setup med flere modeller, som jeg skrev om i LLM-routing: modelvalget er blevet et kontrolplan, bliver tool-orkestreringen endnu et styringspunkt. Du skal kunne svare på tre spørgsmål: hvilken model må kalde hvilke tools, i hvilken mode, og med hvilken budgetramme?

Her er min anbefaling: lad programmatic tool calling starte i læse- og analyseflows. Giv det adgang til tools uden sideeffekter først. Tilføj derefter tools med begrænsede writes, men kun med idempotente operationer, dry-run-mulighed og approval ved følsomme handlinger. Hvis du ikke kan forklare, hvad der sker ved retry, timeout eller delvist output, er tool’et ikke klar til modelskrevet orkestrering.

GPT-5.6 gør ikke agentarkitektur magisk. Det fjerner noget af den kedelige plumbing. Til gengæld tvinger det os til at tage tool-kontrakter, audit og permissions mere alvorligt. Det er et fair bytte, hvis man bygger med drift i hovedet fra starten.