Hvorfor AI-agenter trenger belegg før de prøver på nytt

Slik hindrer du at et tapt svar fører til en duplisert handling

En kundestøtteagent som har tillatelse til å utstede én refusjon, sender forespørselen, men mister forbindelsen. Agenten får ingen bekreftelse på at refusjonen er gjennomført, og prøver å sende forespørselen på nytt. Hvis den opprinnelige forespørselen ble gjennomført, kan det nye forsøket føre til en ekstra refusjon.

Dette er rent hypotetisk. Eksempelet illustrerer et problem som ikke kan løses med bedre modellnøyaktighet alene. Hva bør en agent gjøre hvis den ikke kan fastslå om den forrige handlingen endret tilstanden i omgivelsene?

Unite.AI har undersøkt agenters pålitelighet utover modellene. Gjenopprettingsproblemer fortjener egne regler i slike diskusjoner. Før en agent utfører en handling med betydelige konsekvenser for andre gang, bør den bekrefte hva som skjedde eller ha en gyldig garanti mot dupliserte virkninger.

Et manglende svar betyr ikke at handlingen mislyktes

Et manglende svar fastslår ikke at en handling har mislyktes. Det sier ikke om det oppsto en feil før handlingen ble utført, om handlingen ble fullført uten bekreftelse, eller om prosessen fortsatt pågår.

Dette er et vanlig problem i distribuerte systemer, slik det beskrives av Amazon. Amazon forklarer hvorfor mekanismer for nye forsøk trenger særskilte sikkerhetstiltak mot gjentatte bieffekter. Agenter tilfører systemets gjenopprettingsløp en ny beslutningstaker. De kan ta ytterligere beslutninger om hvordan de skal håndtere feil.

Disse beslutningene kan endre måten virksomheten drives på. Hvis man for eksempel prøver å gjennomføre en refusjon på nytt med et annet beløp, er det ikke bare enda et forsøk på den samme forespørselen. På samme måte er det ikke bare enda et forsøk på den samme forespørselen å velge en annen betalingstjeneste når den første sluttet å svare.

Team må skille mellom å gi tillatelse til å utføre en handling og å gi tillatelse til å håndtere et ukjent utfall. Den opprinnelige godkjenningen innebærer ikke at det er trygt å utføre handlingen på nytt.

Nyere forskning måler risikoen

Et forhåndstrykk fra september 2026 med tittelen «Where Does Exactly-Once Live?» introduserte LIMBO-benchmarken og testet 25 930 episoder på ni modeller. De simulerte tjenestene ble testet med tapte bekreftelser, forsinket behandling og dupliserte leveranser.

I forfatternes hovedtest rapporterte agentene at oppgaven var fullført i 90 % av de 1 279 episodene der det oppsto en duplisert virkning. En agent kan altså rapportere at oppgaven er fullført selv om behandlingen har gått galt.

Disse resultatene bygger på kontrollerte referansetester og sier ikke noe om feilrater i produksjon. Tjenestene var simulerte, og flere av analysene var utforskende. Team bør vurdere resultatene av agentenes handlinger separat fra agentenes rapporter om vellykket utførelse.

Artikkelen tar også for seg hvorfor det kan være utilstrekkelig å kontrollere den aktuelle tilstanden. En forespørsel som fortsatt behandles, kan få virkning etter at kontrollen er utført. Selv et tomt statussvar betyr ikke at forespørselen aldri vil få virkning.

Gjentatte forsøk gjelder samme hensikt

En mottakende tjeneste kan gjenkjenne gjentatte forsøk på én operasjon ved hjelp av en idempotensnøkkel. Hvis denne metoden støttes på riktig måte, sikrer den at gjentatte forsøk ikke skaper flere virkninger. Idempotensnøkkelen må være den samme ved alle nye forsøk.

Stripes API-dokumentasjon gir eksempler på både hvordan idempotensnøkler fungerer, og hvilke begrensninger de har. For API v1 kan nøkler slettes etter minst 24 timer. Hvis en slettet nøkkel brukes på nytt, sendes det en ny forespørsel. Stripe kontrollerer også at parameterne forespørreren oppgir, samsvarer med parameterne i den opprinnelige forespørselen.

I praksis betyr idempotens at funksjonaliteten må finnes i integrasjonslaget, ikke bare i en ledetekst. Før du sender en operasjon videre, må du registrere den godkjente operasjonen. Lagre identifikatoren, de nøyaktige parameterne, leverandørreferansen hvis det er relevant, og operasjonens status.

For en refusjon bør du lagre koblingen mellom godkjenningen og den opprinnelige transaksjonen, samt eventuelle refusjonsidentifikatorer som leverandøren returnerer. Det er mindre overbevisende bevis å søke etter en refusjon på samme beløp, ettersom to legitime forespørsler kan gjelde samme beløp. Det kan også gå noe tid fra en refusjonsforespørsel sendes til den vises i søkeresultatene. Den opprinnelige forespørselen kan fortsatt være under behandling.

Når en agent eller arbeider starter på nytt, bør utførelseslaget beholde identiteten til operasjonen. Det bør avvise en endret forespørsel som sendes inn som om den var den samme operasjonen. En slik endring utgjør en ny handling som krever en ny godkjenningsbeslutning i henhold til arbeidsflytreglene.

Beskrivelser av verktøy er ikke nok

I tillegg til verktøybeskrivelser bør du kontrollere om den mottakende tjenestens kontrakt garanterer støtte for idempotens. Test implementeringen for å bekrefte hvilke garantier som faktisk oppfylles.

Behandle usikkerhet som en driftstilstand

Figur 1. Et foreslått gjenopprettingsløp for handlinger med betydelige konsekvenser. Hvert nytt forsøk krever også en gjeldende autorisasjon.

Bekreftet fullføring betyr at arbeidsflyten dokumenterer resultatet og fortsetter uten å gjenta handlingen. Bekreftet at handlingen ikke ble utført, tillater et nytt forsøk bare hvis ingen opprinnelig forespørsel fortsatt venter, og autorisasjonen fortsatt gjelder.

Det er mye mer å ta hensyn til når utfallet er uavklart. Hvis det finnes en gyldig garanti fra leverandøren mot dupliserte virkninger, kan du tillate at den opprinnelige forespørselen prøves på nytt med samme nøkkel. Ellers må du stanse skrivingen og avklare situasjonen gjennom et statusoppslag, leverandørens kundestøtte eller en autorisert operatør. En uavklart kontroll gir ikke tilstrekkelig grunnlag for å godkjenne et nytt forsøk.

Det kan også være grunn til å sette arbeidet på pause når leverandøren dokumenterer tidsgrenser for behandling og synlighet. Uten slike grenser vil tiden som har gått, alene ikke bekrefte at handlingen ikke ble utført. Du må definere hvem som har ansvaret for saker som ikke blir løst, og når de ansvarlige skal gjennomgå dem.

Feilhåndtering kan kreve en annen forretningsprosess

Hvis en refusjon gjennomføres, men den påfølgende varslingen til kunden mislykkes, kan det å gjenta hele arbeidsflyten føre til at refusjonen utbetales på nytt. Gjenopprettingen bør rette seg mot å fullføre det uferdige trinnet, samtidig som dokumentasjonen av det som allerede er utført, bevares.

Hvis det er behov for korrigerende tiltak for handlinger som allerede er fullført, gir Microsoft veiledning om kompenserende transaksjoner. Hver applikasjon avgjør hvordan feil skal kompenseres. Kompensering setter ikke nødvendigvis alt tilbake slik det var, og selve kompenseringen kan også mislykkes.

I tillegg kan det å kansellere en transaksjon føre til en belastning. Å rette en melding kan ikke garantere at noen ikke har sett en tidligere versjon. Derfor må alle gjenopprettingstiltak uttrykkelig begrense hva agenten kan angre, endre eller forplikte seg til. Beslutninger som faller utenfor disse begrensningene, må henvises til en person med nødvendig myndighet.

Test det andre forsøket før produksjonssetting

Velg ett verktøy med betydelige konsekvenser, og gjennomfør grundige tester av gjenoppretting i et testmiljø. Etter vellykket kjøring forkaster du svaret på den opprinnelige forespørselen. Utsett utførelsen av den første forespørselen til etter en statussjekk. Start arbeiderprosessen på nytt under gjenopprettingen. Vent til oppbevaringstiden for nøkkelen utløper før du prøver på nytt. Endre én parameter i løpet av gjentatte forsøk.

Vurder forretningsoppføringene som oppstår, i stedet for bare å stole på svarene fra verktøyene. Registrer dupliserte virkninger, uavklarte operasjoner, arbeid som ikke ble utført, gjenopprettingstid og behov for ytterligere manuelle inngrep. Beregn kostnaden per korrekt fullførte oppgave ut fra de samlede kostnadene for arbeidsflyten, inkludert reverseringer av transaksjoner og tiltak for å rette opp overfor kunder.

Test også en reell, ny forespørsel som ligner på den opprinnelige. Sørg for at systemet unngår å opprette duplikater uten å hindre nytt arbeid. Vurder forebygging av duplikater og fullføring av oppgaver over tid hver for seg. Ellers kan en agent som avslutter alle oppgaver, virke trygg samtidig som den skaper liten eller ingen verdi.

Evalueringsspørsmålet bør være tydelig formulert. Klarte systemet å forklare:

• Hvilken operasjon var autorisert?
• Hvilke bevis forelå for å dokumentere utfallet?
• Hvorfor var det tillatt å gjøre et nytt forsøk?

En agent som setter arbeidet på pause fordi usikkerheten ikke er avklart, kan virke mindre effektiv under demonstrasjoner. I produksjonsmiljøer kan en pause imidlertid bidra til å bevare kundens opprinnelige hensikt. Nyttig utholdenhet innebærer at systemet fullfører autoriserte oppgaver uten i det skjulte å utføre dem flere ganger.