Virksomheder er i gang med at genbygge deres første bølge af AI‑agenter. Ikke fordi modellerne er blevet dårligere, men fordi driftssikkerheden halter, når agent‑workflows kører i timer eller dage. Temporal peger på samme tendens offentligt, og vi ser den én til én i vores kundeforløb. Sandheden viser sig i produktion, ikke i demoen.
Det presser sig på nu, fordi piloter bliver til systemer på rigtige SLAer. Når et agentforløb rammer et timeout hos en tredjepart klokken 02.17, falder alt til jorden uden styr på state og genstart. Så bliver omkostningerne højere end forventet, fordi alt kører forfra. Vi har set GPU‑regninger vokse natten over.
Hvad går galt i produktion
Fejlbillederne går igen på tværs af brancher: En container dør midt i et flertrinsforløb, agenten kender ikke sin sidste konsistente position og starter forfra. Et eksternt API svarer 429 eller 503, og uden backoff og idempotente nøgler oprettes dubletter. Værktøjskald mangler transaktionelle grænser, så halvfærdige writes bliver liggende, mens agenten prøver igen. Det bliver hurtigt dyrt i både penge og tillid.
Vi ser også multiplicerede inference‑omkostninger. Uden checkpoints skal en agent genskabe hele konteksten efter et crash og gentager alle promptkald, retrieval‑trin og planlægningsrunder. Svartiden forlænges med minutter – nogle gange timer – og kundeoplevelsen lider. Værst er det i sager med compliance, hvor et uklart auditspor gør fejlretning langsom.
Koordinationen mellem værktøjer er et andet svagt punkt. Agenter kalder ofte flere modeller, interne mikroservices, eksterne APIer og værktøjer. Ét schema‑skift downstream kan vælte hele ruten. Uden tydelig observability ender on‑call med at famle i metrics og sporingslogs, mens køen vokser. Nøglen er netop her: synlighed på tværs af alle trin.
Hvorfor LLM‑performance ikke er nok
Temporal formulerede det klart i New York: modelkvalitet afgør ikke alene, om agenter holder i drift. Mange bygger en version 2.0 af den samme agent, fordi fundamentet manglede i første omgang. Det matcher virkeligheden i enterprise‑projekter, hvor første bølge gik hurtigt, og arkitekturen blev udskudt.
Agentiske systemer forstørrer klassiske ingeniørproblemer. Langkørende flows på tværs af services skaber flere fejlpunkter. LLM‑delen kan være stærk, men uden durable execution, state og genstart vælter dominoerne. Resten er disciplin: idempotens, timeout‑strategier, backoff, kompensationslogik. Det kan ikke benchmarkes væk i et lab på fem minutter.
Vi blev selv ramt af det i foråret: Et robust agentflow kollapsede under weekendvedligehold hos en tredjepart, fordi agenten ikke skelnede mellem midlertidige og varige fejl. To nætter gik med at trace en manglende checkpoint. Den læring glemmer man ikke.
Den tekniske genopbygning i version 2.0
Næste generation af agentarkitektur ligner klassisk workflow‑teknik med en AI‑kerne – ikke omvendt. Brug en orkestrator, der holder state, eksekverer trin som aktiviteter med retries og sikrer, at et crash ikke taber fremdrift. Durable execution er forskellen her: mindre glamour, mere stabilitet.
Gør checkpoints til førsteordensborgere. Gem state og dyre resultater efter hvert meningsfuldt trin, så genstart er kort, og regningen lavere. Kombinér med idempotente grænseflader til systemer, der skrives til: en transaktionsnøgle pr. forretningshændelse og klar commit‑semantik.
Et state‑store må ikke være en fil i en pod. Brug et system bygget til formålet eller et etableret workflowrammeværk med persistens, workflow‑versionering og kompensationer. Læg et observability‑lag ovenpå med tracing på tværs af modelkald, værktøjskald og eksterne APIer. Og implementér en enkel, men ofte overset mekanisme: en kill‑switch, der stopper agenten kontrolleret ved anomali.
Praktiske konsekvenser for drift og organisation
Drift og support får nye roller. On‑call skal kunne se, hvor agenten er, hvad der sidst lykkedes, og hvordan den fortsætter. Det kræver dashboards – ikke kun logs. SRE og ML‑ingeniører skal dele værktøjskasse. Vi ser det fungere bedst, når SRE ejer reliability‑mekanismerne, mens ML ejer modellogik og prompts.
SLAs skal dække både modelafhængighed og integrationer. Hvis en kritisk API sænker rate limits i spidsbelastning, hvad er plan B? Chaos testing er ikke luksus: kør cold‑starts, netværksflaps, throttling og tvungne modelfejl i staging, indtil recovery er rutine. Det er billigere end at lære det i produktion.
Compliance bliver lettere med den rigtige arkitektur. Et tydeligt state‑spor og auditerbar kontekst gør det muligt at forklare beslutninger og rulle korrekt tilbage. Det beroliger både risikofolk og tilsyn – og gør fejlsøgning hurtigere mandag morgen.
Økonomien i genstart og hvorfor governance er nødvendig
Koststyring er også en driftssikkerhedsmekanisme. Uden checkpoints betyder et crash, at alle dyre tokenkald og retrieval‑trin kører igen. Det multiplicerer omkostninger og sniger sig ind som et konstant dryp. I stor skala er det væsentligt.
Sæt cost‑alerts på inference for hvert workflow og håndhæv partial re‑execution: gentag kun det trin, der fejlede. Læg caps på samtidige agentflows i peak og brug intelligent batching, hvor det giver mening. Når det måles, falder regningen typisk – fordi spild forsvinder.
Der er også en menneskelig effekt: Et supportteam, der ved, at en agent kan genoptage præcist, arbejder roligere. Den ro styrker robusthedskulturen.
Modstemmer og kildekritik
Nogle agentrammeværker hævder, at de løser persistens og recovery ud af boksen. Der er fremskridt – især med graf‑baserede orkestratorer med indbygget state og værktøjsintegration. Men læs det med ingeniørøjne: Hvordan versioneres state? Hvordan garanteres idempotens? Er genkørsel delvis eller total? Marketing lover meget; driftsloggen er facit.
Temporal taler naturligvis deres egen bog – som enhver leverandør. Budskabet om durable execution kan dog valideres i klassisk SRE‑litteratur og i andre workflow‑systemer. Pointen er principperne: Kan jeres agent overleve nedetid uden at miste overblik og uden at fordoble forbruget?
Bedre modeller med længere kontekst og stærkere værktøjsbrug reducerer fejl, men fjerner ikke behovet for orkestrering. Vi har ikke set et komplekst enterprise‑flow, hvor det er forsvarligt at lade modellen selv holde styr på state uden et bærende lag omkring den.
Et anonymiseret mini‑case fra Snilld
En finanskunde kørte et langkørende skadesflow mod flere eksterne APIer. Når et deltrin timed out, startede hele forløbet forfra, og omkostningskurven steg de dage, hvor tredjeparten droslede ned. Vi indsatte checkpoints efter hvert forretningsmæssigt atomisk trin, indførte idempotente transaktionsnøgler for eksterne writes og lagde simpel kompensationslogik på ufuldendte opgaver. Estimatet efter fire uger var en reduktion i re‑execution‑omkostninger på cirka 40–45 procent. Vi skriver 42 procent som forsigtigt gennemsnit, da de præcise tal er interne.
Det mest markante var roen: Support gik fra brandbekæmpelse til overvågning. En planlagt nedlukning en lørdag aften gav nul alarmer. Jeg sad selv med dashboardet og aircon i baggrunden. Ingenting skete – præcis som ønsket.
Der var en pris: To sprint gik til at definere idempotente grænser i legacy‑systemer. Det gjorde ondt, men investeringen betalte sig i stabilitet og færre manuelle indgreb. Den forskel vil man ikke tilbage fra.
Tradeoffs og begrænsninger
Mere robusthed betyder mere arkitektur og initial kompleksitet. Det sænker tempoet i starten. Det er fristende at gå efter hurtig effekt – men regningen kommer senere i natlige genstarter og uigennemsigtige fejl.
Lift‑and‑shift kan være fint, hvis agenten kun hjælper i korte, sideeffektfrie flows. Mål og se. Men skriver agenten til systemer, taler med kunder eller koordinerer tværgående processer, kræver det redesign. Sæt hegnspælene først – ikke bagefter.
Valg af orkestrator betyder noget: kompetencer, sprog, hosting, behov for kompensationsmønstre og opgave‑timeouts som førsteklasses funktioner. Forvent stadig at bygge lim – ingen platform kender jeres forretningsregler på forhånd.
Handlingsplan for ledere og teknikere
Står I med en pilot på vej i produktion – eller en skrøbelig v1 – så start her: Kortlæg det længste agentflow og markér trin, der ikke må gentages uden omkostning. Indfør simple checkpoints, og gør alle eksterne writes idempotente med transaktionsnøgler. Sæt alarmer på inference‑omkostninger og latency pr. trin – ikke kun på hele flowet.
- Inden for 30 dage: vælg en orkestreringsstrategi med durable execution. Byg et POC‑flow med retries, backoff og delvis genkørsel.
- Observability: indfør distributed tracing på værktøjs‑ og modelkald. Lav dashboards med statustrin.
- Drift: skriv runbooks for crash, langsomme downstreams, modeltimeouter og cost‑spikes. Aftal on‑call‑ejerskab mellem SRE og ML.
- Test: kør chaos‑scenarier i staging. Simulér 429, 503, netværksflaps, schema‑ændringer og uplanlagte restarts.
- Governance: definér beslutningslog, audit af state og regler for rollback og kill‑switch.
Fra vores side anbefaler vi en arkitekturworkshop, et kort audit af et eksisterende agentflow og en fokuseret implementering af state og idempotens i 2–3 kritiske snit. Ikke reklame – praksis. Når de tre ting er på plads, falder resten som regel på plads. Den opskrift har vist sig robust.
Der vil være uenighed om værktøjsvalg. Fint. Vi har set Temporal, egenudviklede orkestratorer og open source‑rammer fungere, når principperne sad fast, og observability var reel. Omvendt har vi ikke set en ren agent uden orkestrering køre stabilt i et flertrins enterprise‑flow i mere end et par uger. Det er vores observation – vis os gerne en modcase i drift.
Til sidst den jordnære pointe: Forskellen mærkes først i drift. Ikke i demoen. Når en agent vælter klokken 03.12, og I kan trykke genoptag, se præcis hvor den var, og den fortsætter – uden at brænde penge af. Det er version 2.0.
