Ifølge Vinamra Yadavs gennemgang på Towards AI kan en AI‑agent fungere upåklageligt i en demo og alligevel fejle i produktion kort efter udrulning. I den beskrevne case rapporterede brugere forkerte svar i tre døgn, mens logs fortsatte med at vise HTTP 200 og monitorering ingen fejl. Yadav præsenterer det som et arkitekturproblem frem for et snævert modelkvalitetsproblem.
Artiklen underbygger sin pointe med et enkelt regnestykke: hvis hvert af 10 trin i et workflow har ca. 85 procent nøjagtighed, er den samlede succesrate omkring 19,7 procent (0,85^10 ≈ 0,197). Modellen er forsimplet, men den illustrerer, hvordan fejl kan forstærkes, når flere trin kædes sammen uden kontroller.
Fra fejlfri demo til tavs fejl
I Towards AI‑casen var infrastrukturen sund set fra klassiske driftssignaler: tjenester oppe, pæn latenstid, 200‑svar. Alligevel var svarene faktuelt forkerte. Yadav peger på, at traditionelle målinger typisk opfanger protokol og performance – ikke meningsindholdet. Det er derfor muligt for en agent at “hallucinere” stille, uden at de sædvanlige alarmer fanger det.
Yadav rammesætter fejlen som arkitektonisk: uden mellemkontroller kan et multi‑step forløb samle små unøjagtigheder op trin for trin, så slutresultatet skrider. Pointen i artiklen er, at kvaliteten skal måles på indholdsniveau i driften – ikke kun i demoens kontrollerede input.
Den enkle matematik der advarer
Regnestykket 0,85^10 ≈ 0,197 bruges i Towards AI som pejlemærke for, hvorfor end‑to‑end succes kan være lav i længere kæder, selv når enkelttrin ser “gode” ud. Antagelserne er bevidst grove, men de illustrerer arkitekturproblemet: uden indbyggede kontroller og fejlhåndtering i hvert trin vokser risikoen.
Konklusionen i artiklen er ikke at undgå multi‑step helt, men at indbygge fejlhåndtering og kvalitetstjek undervejs. Det flytter fokus fra ren modeltuning til drift og arkitektur.
Seks måder agenten dør i produktion
Yadav opstiller en taksonomi med seks gennemgående svigtpunkter, der sjældent er synlige i en demo. I korte træk:
- Kontekstnedbrydning: Samtale- og delresultathistorik vokser og forvrænger over flere trin. Yadav citerer her Datadogs State of AI Engineering 2026 for et mønster med voksende kontekster i produktion; vi gengiver henvisningen uden at tilføje egne tal.
- Utilstrækkelig observabilitet: Semantiske fejl er usynlige bag 200‑svar og pæn latency; klassiske metrics fanger ikke indhold.
- Input‑distribution drift: Data i demoen ligner ikke driften, især ikke long tail.
- Fragile værktøjsinteraktioner: Tekstlige forventninger mellem trin og tjenester er skrøbelige.
- State‑ og race‑fejl: Asynkrone kald og delvise opdateringer skaber uorden.
- Skrøbelige fallbacks: En simpel “ved ikke”‑gren kan låse brugeren fast.
Kontekstnedbrydning og hvad man kan gøre
I følge Yadav fungerer opsummeringer og lange historikker som “lossy kompression”, der kan fjerne nødvendige detaljer efter flere hop. Det kan skubbe agenten væk fra brugerens intention.
Afhjælpning, med støtte i veletablerede kilder:
- Struktureret output per trin. Kræv JSON og valider mod et schema, før næste step eksekverer. Det flugter med disciplinen consumer‑driven contracts beskrevet hos Martin Fowler.
- Begræns historik. Trim kontekst systematisk og henvis til persisteret state frem for at gensende hele samtalehistorikken hver gang. Denne linje følger Yadavs fokus på at mindske kontekstglidning.
Observabilitet af indhold i stedet for kun protokol
Towards AI‑casen viser en 72‑timers periode med forkerte svar uden infrastrukturelle alarmer. Det peger på behovet for observabilitet, der måler semantik. Generelle praksisser for strukturerede events og tracing er veldokumenteret i observabilitetsmiljøet, herunder hos Honeycomb og Lightstep. Selve definitionen af “korrekthed” forbliver applikationsspecifik.
Praktiske skridt med kildedækning:
- Log beslutninger, værktøjsargumenter og mellemresultater som strukturerede events. Det understøtter reproducerbar fejlfinding, jf. observabilitetspraksis hos bl.a. Honeycomb og Lightstep.
- Etabler evaluering på stikprøver i produktion for at fange semantiske fejl, i forlængelse af Yadavs fokus på operativ kvalitet frem for ren protokol‑sundhed.
Værktøjsinteraktioner og kontrakter
Når ét trin forventer “amount” og et andet “total_amount”, kan rene tekstbeskrivelser være skrøbelige. Martin Fowlers gennemgang af consumer‑driven contracts adresserer netop den fejlklasse ved, at forbrugeren beskriver forventninger, som producenten skal opfylde.
Hvad der kan gøres, med kildestøtte:
- Valider struktureret output ved hvert hop mod et kendt schema. Afvis eller eskalér ved mismatch, i tråd med Fowlers kontraktprincipper.
- Versionér kontrakter mellem services og test dem kontinuerligt. Fowlers materiale beskriver, hvorfor kontrakter bør være en del af det løbende build‑ og testflow.
Input‑distribution drift og shadow testing
Yadav fremhæver, at demo‑data sjældent dækker den lange hale af virkelige forespørgsler. Martin Fowler beskriver shadow testing som et veldokumenteret modgreb: kør systemet parallelt mod real trafik uden at påvirke brugeren og sammenlign mod en reference.
Greb der er direkte dækket i kilderne:
- Brug shadow testing før udrulning og ved større ændringer for at opdage afvigelser tidligt, jf. Fowler.
- Rul ændringer bag feature flags og mål effekt i skyggen, før de får brugerpåvirkning, i tråd med Fowlers anbefalinger om kontrolleret eksponering.
State, race‑conditions og idempotency
Asynkronitet og gentagne kald kan give dubletter og delvise opdateringer. Brandur Leach dokumenterer idempotency‑nøgler som et robust værn i API‑design, der også er relevant i agent‑workflows, når de skriver til eksterne systemer.
Anbefalet praksis fra kilderne:
- Gør skrivninger idempotente og gem udfald, så gentagelser ikke skaber inkonsistens, jf. Leach.
- Etabler tydeligt ejerskab for state og brug gennemprøvede transaktionsmønstre, som Leach beskriver i relation til pålidelige API‑operationer.
Fallbacks der styrer usikkerhed
Yadav argumenterer for, at fallbacks ikke bør være et blindt “ved ikke”, men designes som styrede ramper: smallere scope, klare valg eller menneske‑i‑loop, så brugeren ikke låses fast.
Konsekvensen er praktisk: når usikkerheden stiger, bør agenten have en tydelig nedgraderet sti, som stadig flytter brugeren fremad – eller eskalere til menneskelig behandling, så kvaliteten kan sikres.
Et kort roadmap med verificerede greb
Nedenstående punkter sammenfatter Towards AI’s pointe og kobler den til åbent dokumenterede metoder:
- Etabler struktureret observabilitet af beslutninger og mellemtrin, så semantiske fejl kan spores og reproduceres, jf. Honeycomb og Lightstep.
- Indfør contract‑tests mellem agent‑outputs og værktøjs‑API’er, inspireret af consumer‑driven contracts, jf. Martin Fowler.
- Valider og håndhæv schemas for struktureret output i hvert step, før kæden går videre; afvis eller eskalér ved brud.
- Brug shadow testing for at sammenligne mod real trafik, før cutover, jf. Fowler.
- Gør skriveoperationer idempotente og håndter gentagelser korrekt, jf. Brandur Leach.
Kilder og afgrænsning
Primærkilden er Vinamra Yadavs artikel på Towards AI, som dokumenterer den beskrevne 72‑timers periode med tavse fejl, den arkitektoniske rammesætning og regnestykket om fejlakkumulering. Henvisningen til Datadog’s State of AI Engineering 2026 om voksende kontekster gengives, som Yadav citerer den; vi tilføjer ingen egne tal. De foreslåede modgreb er dokumenteret i de anførte kilder: consumer‑driven contracts og shadow testing hos Martin Fowler, idempotency hos Brandur Leach samt praksisser for observabilitet og tracing hos Honeycomb og Lightstep.
Konklusion
Towards AI gennemgangen understreger, at fejlfri demoer ikke siger meget om drift. Fejlene opstår i kæderne mellem trinene og i fravær af indholdsorienteret observabilitet. De metoder, som kilderne beskriver – kontrakter, schema‑validering, shadow testing, idempotency og struktureret observabilitet – er konkrete skridt, der kan reducere risikoen, så problemer opdages og kan rettes i drift frem for at skjule sig bag 200‑svar.
