{"id":1764,"date":"2026-07-13T07:44:19","date_gmt":"2026-07-13T05:44:19","guid":{"rendered":"https:\/\/vittrup-graversen.dk\/?p=1764"},"modified":"2026-07-13T07:44:20","modified_gmt":"2026-07-13T05:44:20","slug":"programmatic-tool-calling-naar-llm-agenten-skriver-sin-egen-orkestrering","status":"publish","type":"post","link":"https:\/\/vittrup-graversen.dk\/index.php\/2026\/07\/13\/programmatic-tool-calling-naar-llm-agenten-skriver-sin-egen-orkestrering\/","title":{"rendered":"Programmatic tool calling: n\u00e5r LLM-agenten skriver sin egen orkestrering"},"content":{"rendered":"\n

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

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\u00f8re tool-tunge workflows billigere og hurtigere. Det kan ogs\u00e5 g\u00f8re d\u00e5rlige tool-kontrakter dyrere, fordi en fejl ikke bare bliver til \u00e9t forkert kald. Den kan blive gentaget i en l\u00f8kke.<\/p>\n\n\n\n

Det gamle agent-loop er dyrt<\/h2>\n\n\n\n

Den klassiske function-calling-model er enkel: modellen beder om et tool call, applikationen udf\u00f8rer kaldet, resultatet sendes tilbage, og modellen beslutter n\u00e6ste trin. Fire opslag giver ofte fire runder. Fyrre opslag kan give fyrre runder.<\/p>\n\n\n\n

Det er ikke kun ventetid. Hver runde tr\u00e6kker tidligere resultater med tilbage i konteksten, og det g\u00f8r is\u00e6r ondt i workflows med mange opslag, filtrering, sammenligning og validering. T\u00e6nk prissammenligning, lagercheck, dokumentklassifikation eller en intern supportagent, der skal sl\u00e5 op i flere systemer f\u00f8r den svarer.<\/p>\n\n\n\n

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 \u00e6ndrer 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.<\/p>\n\n\n\n

Sandboxen er ikke det samme som sikkerhed<\/h2>\n\n\n\n

OpenAI skriver, at programmerne k\u00f8rer i en frisk, isoleret V8-runtime uden Node.js, pakkeinstallation, direkte netv\u00e6rksadgang, generelt filsystem, subprocesser eller persistent JavaScript-state. Det er godt. Det betyder, at modellens kode ikke frit kan hente en URL eller \u00e5bne en socket.<\/p>\n\n\n\n

Men sikkerhedsgr\u00e6nsen er stadig dine tools. Hvis du eksponerer et tool, der kan l\u00e6se kundedata, \u00e6ndre ordrestatus eller sende mails, s\u00e5 er det stadig et privilegeret interface. Forskellen er, at tool’et nu kan blive kaldt fra modelskrevet kode med l\u00f8kker og betingelser. Det kr\u00e6ver mere pr\u00e6cise JSON-skemaer, tydelige fejlformater og h\u00e5rde gr\u00e6nser for rate, idempotens og sideeffekter.<\/p>\n\n\n\n

Det matcher den bredere driftspointe fra tidligere indl\u00e6g om prompt injection som kontrolplansproblem<\/a>. Agentens tool-lag er ikke bare en convenience-feature. Det er en produktionsgr\u00e6nse. N\u00e5r en model kan komponere mange kald selv, bliver auditloggen og approval-boundary’en vigtigere end den p\u00e6ne demo.<\/p>\n\n\n\n

Hvorn\u00e5r giver programmatic tool calling mening?<\/h2>\n\n\n\n

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\u00e6nsning.<\/p>\n\n\n\n

Brug det til opslag, join, deduplikering, rangering og simpel validering. Brug direkte tool calling, n\u00e5r hvert resultat kr\u00e6ver ny semantisk vurdering, n\u00e5r der er brugerapproval, eller n\u00e5r du skal bevare citater og originale artefakter. Det sidste punkt er vigtigt. Hvis en agent skal dokumentere, hvorfor den traf en beslutning, m\u00e5 programmet ikke bare returnere en glat opsummering og smide beviserne v\u00e6k.<\/p>\n\n\n\n

For danske teams, der bygger interne agenter, er den praktiske konsekvens ret jordn\u00e6r: begynd ikke med at sl\u00e5 funktionen til overalt. Start med en baseline. M\u00e5l direkte tool calling mod programmatic tool calling p\u00e5 20-30 repr\u00e6sentative opgaver. Kig ikke kun p\u00e5 tokenforbrug og latency. M\u00e5l ogs\u00e5 korrekthed, manglende evidens, fejl ved tomme svar og om agenten overholder godkendelsesgr\u00e6nserne.<\/p>\n\n\n\n

Agentarkitektur bliver mere API-arkitektur<\/h2>\n\n\n\n

Den vigtigste design\u00e6ndring 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\u00e6nset rettighedsmodel.<\/p>\n\n\n\n

Det h\u00e6nger 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<\/a>, bliver tool-orkestreringen endnu et styringspunkt. Du skal kunne svare p\u00e5 tre sp\u00f8rgsm\u00e5l: hvilken model m\u00e5 kalde hvilke tools, i hvilken mode, og med hvilken budgetramme?<\/p>\n\n\n\n

Her er min anbefaling: lad programmatic tool calling starte i l\u00e6se- og analyseflows. Giv det adgang til tools uden sideeffekter f\u00f8rst. Tilf\u00f8j derefter tools med begr\u00e6nsede writes, men kun med idempotente operationer, dry-run-mulighed og approval ved f\u00f8lsomme handlinger. Hvis du ikke kan forklare, hvad der sker ved retry, timeout eller delvist output, er tool’et ikke klar til modelskrevet orkestrering.<\/p>\n\n\n\n

GPT-5.6 g\u00f8r ikke agentarkitektur magisk. Det fjerner noget af den kedelige plumbing. Til geng\u00e6ld 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.<\/p>\n\n\n\n

Kilder<\/h2>\n\n\n\n