Varför AI-agenter behöver belägg innan de försöker igen

Så förhindrar du att ett uteblivet svar leder till en dubblerad åtgärd

En supportagent som har behörighet att utfärda en återbetalning skickar begäran men tappar anslutningen. Agenten får ingen bekräftelse på att åtgärden lyckats och försöker skicka återbetalningen igen. Om den ursprungliga begäran gick igenom kan det upprepade försöket leda till en andra återbetalning.

Det här är en rent hypotetisk situation. Exemplet illustrerar ett problem som inte kan lösas enbart genom högre träffsäkerhet hos modellen. Vad bör en agent göra om den inte kan avgöra om den föregående åtgärden förändrade miljöns tillstånd?

Unite.AI har undersökt agenters tillförlitlighet utöver modellerna. Återställningsproblem förtjänar egna regler i sådana diskussioner. Innan en agent utför en konsekvensrik åtgärd en andra gång bör den bekräfta vad som hänt eller ha en giltig garanti för att åtgärden inte får dubbla effekter.

Ett uteblivet svar visar inte att åtgärden misslyckats

Ett uteblivet svar visar inte att en åtgärd har misslyckats. Det säger inte om ett fel uppstod före genomförandet, om åtgärden slutfördes utan bekräftelse eller om processen fortfarande pågår.

Det här är ett vanligt problem i distribuerade system, som Amazon beskriver. Amazon förklarar varför mekanismer för nya försök behöver särskilda skydd mot upprepade bieffekter. Agenter tillför en ny beslutsfattande aktör i systemets återställningsförlopp. De kan fatta ytterligare beslut om hur fel ska hanteras.

Sådana beslut kan förändra hur verksamheten bedrivs. Om en återbetalning till exempel görs på nytt med ett annat belopp är det inte bara ännu ett försök med samma begäran. På samma sätt är det inte bara ännu ett försök med samma begäran att välja en annan betaltjänst när den första slutat svara.

Team måste skilja mellan att ge tillstånd att utföra en åtgärd och att ge tillstånd att hantera ett okänt utfall. Det ursprungliga godkännandet innebär inte att det är säkert att utföra åtgärden igen.

Ny forskning mäter risken

Ett förtryck från september 2026, ”Where Does Exactly-Once Live?”, introducerade LIMBO-benchmarken och testade 25 930 episoder med nio modeller. De simulerade tjänsterna testades med uteblivna bekräftelser, fördröjd hantering och dubbla leveranser.

Av de 1 279 episoder i författarnas huvudtest där en dubblerad effekt uppstod rapporterade agenterna att åtgärden slutförts framgångsrikt i 90 procent av fallen. En agent kan alltså rapportera framgång även när hanteringen blivit felaktig.

Resultaten bygger på kontrollerade benchmarktester och uppskattar inte felfrekvenser i produktionsmiljöer. Tjänsterna var simulerade, och flera analyser var explorativa. Team bör utvärdera resultatet av agenternas åtgärder separat från deras rapporter om att åtgärderna har genomförts.

Artikeln tar också upp varför det kan vara otillräckligt att kontrollera det aktuella tillståndet. En begäran som fortfarande behandlas kan få effekt efter kontrollen. Inte ens ett tomt statussvar innebär att begäran aldrig kommer att få effekt.

Upprepade försök avser samma avsikt

En mottagande tjänst kan känna igen upprepade försök att utföra en och samma åtgärd med hjälp av en idempotensnyckel. Om metoden stöds korrekt säkerställer den att upprepade försök inte skapar ytterligare effekter. Idempotensnyckeln måste förbli oförändrad vid alla nya försök.

Stripes API-dokumentation innehåller exempel på både idempotensnycklarnas funktion och deras begränsningar. För API v1 kan nycklar raderas efter minst 24 timmar. Om en rensad nyckel används igen skapas en ny begäran. Stripe kontrollerar också att parametrarna i begäran stämmer överens med dem i den ursprungliga begäran.

Den praktiska slutsatsen av idempotens är att den måste finnas i integrationslagret, inte bara i en prompt. Registrera den godkända åtgärden innan du skickar iväg den. Spara dess identifierare, de exakta parametrarna, leverantörens referens om en sådan finns och åtgärdens status.

Vid en återbetalning bör du spara kopplingen mellan godkännandet och den ursprungliga transaktionen samt eventuella identifierare för återbetalningen som leverantören returnerar. Att söka efter en återbetalning med samma belopp är ett mindre övertygande bevis, eftersom två legitima begäranden kan gälla samma belopp. Det kan också dröja innan en begäran om återbetalning syns i sökresultaten. Den ursprungliga begäran kan fortfarande behandlas.

När en agent eller arbetare startas om bör exekveringslagret behålla den identiteten. Det bör avvisa en ändrad begäran som skickas in som samma åtgärd. En sådan ändring utgör en ny åtgärd som kräver ett nytt godkännandebeslut enligt arbetsflödets regler.

Verktygsbeskrivningar räcker inte

Kontrollera, utöver verktygsbeskrivningarna, den mottagande tjänstens specifikation för stöd för idempotens. Testa implementeringen för att bekräfta vilka garantier som faktiskt uppfylls.

Hantera osäkerhet som ett driftläge

Figur 1. Ett föreslaget återställningsförlopp för konsekvensrika åtgärder. Varje nytt försök kräver också ett aktuellt godkännande.

Bekräftat slutförande innebär att arbetsflödet dokumenterar resultatet och fortsätter utan att upprepa åtgärden. Bekräftad utebliven exekvering tillåter ett nytt försök endast om ingen ursprunglig begäran fortfarande väntar och behörigheten fortfarande gäller.

Det finns mycket mer att ta hänsyn till när utfallet är oklart. Om det finns en giltig garanti från leverantören som skyddar mot dubbla effekter får du låta det ursprungliga anropet göras om med samma nyckel. I annat fall ska skrivåtgärder pausas och situationen redas ut genom en statusförfrågan, med hjälp av leverantörens support eller av en behörig operatör. En kontroll som inte ger något entydigt svar är inte tillräckligt skäl för att godkänna ett nytt försök.

Det kan också vara motiverat att pausa när leverantören dokumenterar gränser för behandling och synlighet. Utan sådana gränser bekräftar inte enbart den tid som gått att åtgärden inte har utförts. Du måste fastställa vem som ansvarar för ärenden som förblir olösta och när de ansvariga ska granska dem.

Återhämtning efter ett fel kan kräva en annan affärsprocess

Om en återbetalning genomförs, men den efterföljande kundaviseringen misslyckas, kan en upprepning av hela arbetsflödet leda till att återbetalningen görs en gång till. Återställningen bör inriktas på att slutföra det steg som återstår och samtidigt bevara belägg för det arbete som redan har utförts.

Om korrigerande åtgärder behövs för åtgärder som redan har slutförts ger Microsoft vägledning om kompenserande transaktioner. Varje applikation avgör hur fel ska kompenseras på rätt sätt. En kompensation återställer inte nödvändigtvis läget till hur det var från början, och även själva kompensationen kan misslyckas.

Dessutom kan en transaktion medföra en avgift om den avbryts. Att korrigera ett meddelande kan inte garantera att någon inte har sett en tidigare version. Därför måste varje återställningsåtgärd uttryckligen begränsa vad agenten får ångra, ändra eller förplikta sig till. Beslut utanför dessa begränsningar måste hänskjutas till en person med nödvändiga befogenheter.

Testa det andra försöket före driftsättning

Välj ett verktyg med betydande konsekvenser och genomför noggranna återställningstester i en testmiljö. Släpp svaret på den ursprungliga begäran efter att åtgärden har genomförts. Fördröj den första begäran så att den utförs först efter en statuskontroll. Starta om arbetaren under återställningen. Vänta tills nyckelns lagringstid har löpt ut innan du försöker igen. Ändra en parameter under upprepade försök.

Utvärdera de affärsposter som skapas i stället för att enbart förlita dig på verktygens svar. Registrera dubbla effekter, olösta åtgärder, missat arbete, återställningstid och ytterligare manuella insatser. Beräkna kostnaden per korrekt slutförd uppgift utifrån de totala kostnaderna för arbetsflödet, inklusive återföringar av transaktioner och kompensation till kunder.

Testa dessutom en verklig andra begäran som liknar den ursprungliga. Säkerställ att systemet undviker att skapa dubbletter utan att hindra nytt arbete. Bedöm separat hur väl systemet undviker dubbletter och slutför uppgifter i slutändan. Annars kan en agent som avbryter varje uppgift verka säker samtidigt som den levererar litet eller inget värde.

Frågan i utvärderingen bör vara tydligt formulerad. Kunde systemet förklara:

• Vilken åtgärd var godkänd?
• Vilka belägg fanns för att visa utfallet?
• Varför var det tillåtet att göra ett nytt försök?

En agent som pausar när osäkerheten inte kan redas ut kan verka mindre effektiv i demonstrationer. I produktionsmiljöer kan en paus dock bidra till att bevara kundens ursprungliga avsikt. Användbar uthållighet innebär att systemet slutför godkända uppgifter utan att i tysthet utföra dem flera gånger.