KI-agenter krasjer sjelden. De svikter i det stille – og forskning viser hvorfor

Store språkmodellagenter besvarer nå supportsaker, søker i databaser og planlegger reiser. Når noe går galt, gir de som regel et selvsikkert svar og en suksesskode. En stadig større mengde forskning forklarer hvorfor slike feil er vanskelige å oppdage, og hvordan ingeniørteam lærer å måle dem.

En feil som ser ut som en suksess

Tradisjonell programvare feiler gjerne på en tydelig måte. En funksjon utløser et unntak, en server returnerer en feilkode, og et overvåkingspanel blir rødt. En KI-agent oppfører seg annerledes. Den arbeider i en løkke: En språkmodell leser en instruks, bestemmer seg for å bruke et verktøy, for eksempel et søke-API eller en database, leser resultatet og bestemmer hva den skal gjøre videre. Hvert trinn kan gå galt, selv om alle nettverksforespørslene i kjeden lykkes.

Tenk på et vanlig tilfelle. Et værverktøy svikter og returnerer teksten «tjenesten er utilgjengelig» i et ellers normalt svar. Modellen leser teksten, beklager høflig eller, enda verre, skriver en plausibel værmelding basert på treningsdataene sine. Brukeren får et velformulert svar. Serverloggene viser en vellykket forespørsel med normal responstid. Ingen ting i et konvensjonelt overvåkingssystem registrerer at noe har gått galt.

Modelltilbydere beskriver det samme problemet i sin egen dokumentasjon. Googles veiledning for Gemini API påpeker at modellen «ikke utfører funksjonen selv». Den foreslår bare et funksjonsnavn og argumenter, mens utviklerens applikasjon utfører kallet. Applikasjonen er derfor den eneste delen av systemet som ser det faktiske resultatet. Anthropics ingeniørveiledning for utvikling av agenter fremhever et beslektet poeng: Agenter trenger «fasit» fra omgivelsene ved hvert trinn, for eksempel resultater fra verktøy, for å kunne vurdere sin egen fremgang. Når et verktøy rapporterer en feil som vanlig tekst, er denne fasiten feil, og agenten har ingen mulighet til å oppdage det.

Dette er ikke en ny type problem, bare en tydeligere variant av et gammelt problem. I 2015 beskrev Google-ingeniører ledet av D. Sculley «skjult teknisk gjeld» i maskinlæringssystemer. De hevdet at mesteparten av risikoen i et maskinlæringssystem i produksjon ligger utenfor modellkoden, i dataavhengigheter, konfigurasjon og limkode. Agenter legger et nytt lag til denne listen. Prompter og verktøybeskrivelser er konfigurasjon som kan endre systemets atferd uten at koden endres.

Små endringer, store utslag

Hvor mye kan en liten endring i en prompt bety? I en artikkel presentert på ICLR 2024 endret Melanie Sclar ved University of Washington og kollegene hennes bare formateringen av prompter med få eksempler: skilletegn, mellomrom og bruk av store og små bokstaver. Betydningen var den samme. Likevel varierte ytelsen på den samme oppgaven med opptil 76 nøyaktighetspoeng på LLaMA-2-13B. Denne følsomheten forsvant ikke med større modeller, flere eksempler eller instruksjonstilpasning.

Forfatterne anbefaler å rapportere et spenn i ytelsen på tvers av plausible promptformater i stedet for ett enkelt tall. For ingeniørteam er den praktiske lærdommen enklere: En promptendring er en kodeendring. Den trenger en versjonshistorikk og må testes før den når brukerne.

Det samme gjelder verktøybeskrivelser, som modellen leser som en del av prompten. Anthropics veiledning anbefaler at verktøydefinisjoner får «like mye oppmerksomhet i promptutformingen» som hovedprompten. Den beskriver en kodeagent som stadig gjorde feil med relative filbaner. Da verktøyet ble endret slik at det krevde absolutte filbaner, brukte modellen det uten feil. Modellen ble ikke endret. Det eneste som ble endret, var beskrivelsen den leste.

Én suksess beviser lite

En annen forskningsretning undersøker hvor konsistente agentene er. Benchmarken τ-bench, publisert av Shunyu Yao og kolleger hos Sierra og presentert på ICLR 2025, simulerer kundeservicesamtaler der en agent må bruke verktøy og følge forretningsregler. Forfatterne innførte et mål kalt pass^k: sannsynligheten for at en agent løser den samme oppgaven riktig i alle k forsøkene.

Resultatene var nedslående. En GPT-4o-agent løste omtrent 61 % av detaljhandelsoppgavene på ett forsøk. Når den måtte lykkes med den samme oppgaven åtte ganger på rad, falt andelen til omtrent 25 %. En demonstrasjon som fungerer én gang, sier lite om hvordan et system oppfører seg på det tusende forsøket.

Slik svikter multiagentsystemer

Mange team kobler nå flere agenter sammen, slik at én planlegger, en annen utfører og en tredje kontrollerer arbeidet. En studie fra UC Berkeley i 2025, «Hvorfor svikter multiagent-LLM-systemer?», analyserte over 1 600 annoterte gjennomføringsspor fra sju populære multiagent-rammeverk. Forfatterne, ledet av Mert Cemri, utviklet en taksonomi kalt MAST med 14 feilmodi fordelt på tre grupper: problemer med systemdesign, manglende samsvar mellom agenter og verifisering av oppgaver.

Hovedfunnet deres er at mange feil skyldes hvordan systemet er utformet, ikke bare begrensningene til den underliggende modellen. Agenter overser den tildelte rollen sin, mister oversikten over samtalen eller erklærer en oppgave fullført uten å kontrollere resultatet. Disse feilene etterlater ingen feilmelding. De blir bare synlige hvis noen kan lese hva hver agent faktisk gjorde. Unite.AIs omtale av multiagentparadokset fremhever et beslektet arkitekturpoeng: Flere agenter kan forsterke en tidlig feil i stedet for å oppveie den.

Slik synliggjør vi det usynlige

Den tekniske løsningen henter inspirasjon fra distribuerte systemer, der man lenge har fulgt forespørsler gjennom mange tjenester ved hjelp av en teknikk som kalles sporing. Brukt på agenter blir hver brukerforespørsel et spor, og hvert modellkall eller verktøykall blir et «span» i sporet. Et span registrerer inndataene, utdataene, tokenene som brukes, og hvor lang tid det tok. OpenTelemetry, bransjeorganet for standardisering på dette området, utarbeider felles konvensjoner for generative KI-spenn. Per 2026 er konvensjonene fortsatt merket som under utvikling, så attributtnavnene kan fortsatt bli endret.

Flere åpen kildekode-prosjekter, som Langfuse, Arize Phoenix og AcruxCore, bruker allerede denne ideen. Kildekoden deres er offentlig, slik at team kan undersøke hvordan et spor lagres, og kjøre programvaren på sine egne servere. De registrerer modellkall og verktøykall som span i ett og samme spor, og lar team knytte kvalitetsskårer til dem. Valget av verktøy er mindre viktig enn én detalj: Et verktøyspan må registrere hva verktøyet faktisk returnerte, ikke bare om nettverksforespørselen ble gjennomført. Uten dette forblir verktøyfeilen med værmeldingen som ble beskrevet ovenfor, usynlig.

Bransjeundersøkelser tyder på at sporing nå er vanlig, men at testing henger etter. LangChains rapport om statusen for agentutvikling kartla 1 340 fagpersoner sent i 2025. Kvalitet var den oftest nevnte hindringen for å ta agenter i bruk i produksjon, oppgitt av 32 % av respondentene. 89 % av organisasjonene rapporterte at de hadde en eller annen form for observerbarhet for agentene sine, og 62 % hadde detaljert sporing av individuelle trinn og verktøykall. Bare 52,4 % gjennomførte offline-evalueringer på testsett, og 37,3 % evaluerte live-trafikk. De fleste team kan se hva agentene deres gjorde. Færre undersøker om det var riktig.

Vurdering av svar i stor skala

Spor viser hva som skjedde. De sier ikke om svaret var godt. Det er ikke skalerbart å lese hver samtale manuelt, så team bruker i stadig større grad en ekstra modell som vurderer, en metode som kalles LLM-som-dommer. En artikkel fra NeurIPS 2023 av Lianmin Zheng og kolleger viste at sterke modeller som GPT-4 var enige med menneskers preferanser i over 80 % av tilfellene, omtrent like ofte som mennesker er enige med hverandre.

Den samme artikkelen dokumenterte metodens svakheter. Modeller som fungerer som dommere, foretrekker svaret som vises først, foretrekker lengre svar og kan favorisere tekst de selv har skrevet. Skårer fra slike dommere er derfor anslag. De er nyttige når man skal vurdere store datamengder, men må kontrolleres mot et lite utvalg eksempler som mennesker har merket, der rekkefølgen på svarene er tilfeldig.

Fra praksis til retningslinjer

Dette målearbeidet blir også i økende grad et krav til styring. US National Institute of Standards and Technology publiserte sitt rammeverk for risikostyring innen KI i januar 2023. En av de fire kjernefunksjonene, «Måle», ber organisasjoner tallfeste, følge opp og dokumentere KI-risiko over tid. For en agent er spor og evalueringsskårer dokumentasjonen denne funksjonen etterspør.

Dette kan team gjøre nå

Dette gjenspeiler argumentet som er fremført på denne plattformen: Pålitelighet er den virkelige prøven på agentisk KI. Forskningen ovenfor utdyper hvordan dette argumentet kan måles: Pålitelighet er ikke en egenskap man observerer én gang, men et spenn man må måle kontinuerlig.

Forskningen peker på noen få vaner, og de store modelltilbyderne anbefaler mange av de samme. OpenAIs praktiske veiledning i å bygge agenter anbefaler team å «sette opp evalueringer for å etablere et utgangspunkt for ytelsen» før de optimaliserer, og å overlate kontrollen til et menneske når en agent overskrider et bestemt antall mislykkede forsøk eller står overfor en handling med høy risiko. Anthropic anbefaler «omfattende testing i sandkassemiljøer» før agenter handler på egen hånd.

I praksis innebærer det noen konkrete tiltak. Bruk versjonskontroll for ledetekster og verktøybeskrivelser, på samme måte som for kode. Test hver endring i en ledetekst mot et fast datasett, og forvent et spenn av resultater i stedet for ett enkelt tall. Kjør hver test flere ganger, fordi én gjennomkjøring skjuler variasjon. Registrer verktøyresultater i sporene, slik at et verktøy som feiler, ikke kan skjule seg bak en suksesskode. Behandle automatiserte dommerskårer som anslag, og kontroller dem mot menneskelige vurderinger.

Ingen av disse vanene krever et gjennombrudd i modellkapasitet. De krever at man behandler en KI-agent som det den er: et probabilistisk system som må måles, fordi det sjelden varsler om sine egne feil.