De fleste agent‑projekter snubler ikke på idéen, men på driften. Towards AI’s vejledning, opdateret 3. august 2026, rammer hovedet på sømmet: tool calling og struktureret output er blevet fundamentet for produktionsklare AI‑agenter. Ikke pænere prompts. Ikke længere kæder af tanker. Værktøjer, kontrakter og disciplineret fejlhåndtering.
Kernen er enkel og lidt ubekvem: Agenten skal ikke gætte parametre eller opfinde formater; den skal kalde rigtige værktøjer via præcise skemaer og holde sig inden for aftalte rammer. Vejledningen viser, hvordan streng struktur skærer ned på parsingfejl, mindsker skrøbelighed i flertrinsopgaver og stabiliserer eksterne API‑kald. Tørt på papiret – afgørende i praksis. Det er forskellen på demo og drift.
Hvorfor det her er nyt og vigtigt
Tidlige agenter byggede på prompts og chain‑of‑thought. Det gav hurtige demoer – og klassiske faldgruber: hallucinerede parametre, varierende outputformater, ustabile eksterne kald og brud i flertrinsforløb. 2026‑mønstrene vender det om: design værktøjerne, fastsæt kontrakterne, orkestrér bevidst – og lad modellen operere inden for stregerne.
Fejlbilledet bliver dermed målbart. Når et schema brydes, kan man logge, alarmere og rette. Når output “bare” ændrer formulering, smuldrer integrationen uset. Gevinsten mærkes i responser – men især i MTTR: færre natlige udkald.
Hvad tool calling er i praksis
Vejledningen anbefaler eksplicitte tool‑schemas (typisk Pydantic) eksponeret via et agent‑framework som LangChain. Modellens svar holdes i strukturerede formater (JSON, Pydantic‑modeller), så parsing ikke bliver et lotteri. Orkestrering af beslutninger og loops kan bygges med LangGraph, som giver kontrol over noder, tilstand og overgange uden at drukne i limkode.
Rollerne er klare: Schemaet er kontrakten (felter, typer, tilladte værdier). Frameworket ensarter og sikrer tool calls. Struktureret output gør nedstrøms systemer trygge ved formatet. Orkestreringen binder det til et styrbart forløb med tydelige kanter. Mindre magi, mere mekanik.
Fejlhåndtering og robusthed i drift
Når et værktøj fejler midt i en kundesag kl. 15.42 en mandag, skal der være mønstre – ikke håb. Brug retries med backoff. Fallback til sekundært værktøj eller reduceret svar. Timeouts med partial output, hvor agenten tydeligt angiver, hvad der lykkedes, og hvad der blev skippet. Og vigtigst: audit‑egnede fejlobjekter, ikke en pæn undskyldning i naturligt sprog.
Skeln mellem fejltyper: inputvalidering (schema‑brud), driftsfejl (500’ere, rate‑limits) og logiske fejl (gyldigt, men ubrugeligt svar). Strategierne følger: omformater og prøv igen, vent og retry, eller eskalér til menneskelig verifikation. Kedeligt? Ja. Nødvendigt for at overleve virkeligheden.
Observability og drift
Uden indsigt, ingen kontrol. De metrikker, der går igen i stabile opsætninger, er konkrete: schema‑valideringsfejl, parsing‑exceptions, latensfordelinger på tool calls, retry‑rater samt cost‑per‑call og cost pr. fuldført job. Dertil kommer traces, så hele agentforløbet kan rekonstrueres uden gætværk.
En praktisk liste, der sjældent står ét sted:
- API‑fejlrate pr. værktøj samt p95\/p99‑latens
- Andel svar der bryder output‑schema vs. total
- Retry‑rate og succes efter 1., 2. og 3. forsøg
- Tokenforbrug, cost‑per‑call og cost pr. workflow
- Andel sager eskaleret til menneske og MTTR per kategori
Arkitekturvalg og tradeoffs
Den anbefalede stak i vejledningen tegner en klar linje: orkestrering, værktøjsdefinitioner, strukturerede outputmodeller, modelvalg og observability. Intet er gratis. Stram struktur koster lidt latens og fleksibilitet – til gengæld vinder man stabilitet og sporbarhed. Mere orkestrering øger kompleksiteten, men gør adfærd forståelig og reviderbar.
Modelvalget er klassisk: Hurtigere, billigere modeller med stærk tool‑følsomhed kan slå de største i drift, fordi kontrakterne bærer en del af byrden. Hosted vs. on‑prem er den anden akse: Hosted sparer tid og giver skalering; on‑prem giver kontrol og compliance‑komfort, men kræver solid infrastruktur og stram kapacitetsplanlægning. Man vælger, hvor risici og omkostninger skal ligge.
Modelnyhedens betydning: Qwen3.8‑Max
Sideløbende kom nyheden om Alibaba Qwen3.8‑Max, en 2,4 billioners MoE‑model, der tager tekst, billede og video ind og svarer med tekst. Ifølge MarkTechPost er den bredt tilgængelig via hosted API nu, mens open weights ruller ud i næste uge sammen med Qwen3.8‑27B som mere håndterbart checkpoint. Det påvirker agentdesign på to fronter: integrationshastighed og hostingvalg.
Hosted API kan i praksis tages i brug med få konfigurationsskift. Open‑weights‑sporet er tungere: Et 2,4T‑checkpoint kræver multi‑node datacenter, ikke et standard on‑prem rack. Alibaba har ikke oplyst activated‑parameter‑tallet, så serving‑omkostninger kan ikke estimeres præcist endnu. Indregn usikkerheden i business casen.
Fra teori til implementering
Start ved kontrakten. Definér værktøjer som Pydantic‑modeller med klare typer, begrænsninger og beskrivelser. Eksponér dem via et framework, hvor agenten eksplicit vælger værktøj og argumenter. Kræv struktureret output, valider det, og stop flowet ved formatbrud. Så giver orkestrering mening.
Test efter virkelige fejl: unit‑tests for tool contracts. Integrationstests hvor API’er svarer langsomt, forkert eller med manglende felter. Loadtests på rate‑limits. Og en dosis chaos‑testing for timeouts og delvise nedbrud. Agenter fejler sjældent pænt af sig selv – de skal læres det.
30, 90 og 180 dage
En enkel prioritering hjælper med at holde kursen:
- 30 dage: Definér 3–5 kritiske tool contracts i Pydantic. Indfør struktureret output og schema‑validering. Log alle schema‑ og parsingfejl.
- 90 dage: Byg integrationer gennem LangChain med eksplicit tool calling. Indfør LangGraph‑orkestrering for to nøgleworkflows. Etabler integrationstests og basale chaos‑scenarier.
- 180 dage: Fuld observability med metrikker og traces. Cost‑styring pr. workflow. Governance med adgangsstyring, audit‑logs og change‑kontrol på værktøjs‑API’er.
Sikkerhed, compliance og ansvarlighed
Stramme schemas og audit‑logs skaber sporbarhed: Hvem kaldte hvad, med hvilke argumenter, og hvilket svar kom tilbage. Det forenkler intern revision og eksterne krav. Men risici består: følsomme data til eksterne værktøjer, svigt i adgangsstyring og modeldrift over tid.
Tre lavpraktiske råd: maskér og minimér input til værktøjer, brug kortlivede tokens og mindst mulige privilegier, og isolér agent‑identiteter fra brugeridentiteter. Resten handler om alarmer og runbooks – nødvendigt mere end elegant.
Forretningsmæssige konsekvenser
ROI flytter sig, når agenten kalder værktøjer pålideligt. I regnskabsmatching kan et stramt schema for posteringer, beløb og bilag være forskellen på “nær” automatisk og faktisk automatisk afstemning: færre undtagelser, hurtigere afslutning.
I juridisk dokumentgennemgang betyder struktureret ekstraktion, at referencer, paragraffer og tidslinjer ender i felter – ikke i fritekst. Det accelererer kvalitetssikring og søgbarhed. Og i enterprise‑kodeassistenter muliggør tool calling sikre kald til CI, issue‑tracker og søgning i kodebasen uden gæt på syntaks eller API‑formater.
Modargumenter og begrænsninger
Det her er ikke en sølvkugle. Arkitekturen bliver mere kompleks, opstarten dyrere, og organisationen skal forstå kontrakterne for at høste gevinsterne. Nogle prototyper går hurtigere med rene prompts – fint til en demo eller en snæver intern opgave.
Men når kravene er drift, revision og skalering, vinder værktøjsarkitektur over prompt‑kunst. Kald det kedeligt – det er netop pointen.
Konkurrenceblik og vinkel
Meget dækning vil hænge sig i modelhype: parametre, reasoning‑længder, nye benchmarks. Det har sin plads. For beslutningstagere, der skal i gang nu, er integrationsarkitektur vigtigere. Tool contracts, strukturerede svar og målelig drift er dér, risiko og værdi flytter sig.
Derfor er vinklen jordnær: strukturer og governance slår kreative prompts, når softwaren skal holde til hverdagen.
Hvad CTO’er bør gøre nu
Tre skridt gør en synlig forskel: udpeg en ejer for agent‑kontrakter og schemaer, sæt målepunkter for parsing‑ og valideringsfejl, og læg en hostingbeslutning for næste halvår – med plan B, hvis open weights viser sig driftsmæssigt urealistiske. Involver sikkerhed, SRE og produkt tidligt. Og beslut hvor meget frihed agenten egentlig skal have.
Sidste råd er banalt – og effektivt: Start med værktøjet, ikke prompten.
