Waarom AI-agenten bewijs nodig hebben voordat ze het opnieuw proberen

Hoe voorkom je dat een verloren antwoord leidt tot een dubbele actie

Een supportmedewerker die bevoegd is om één terugbetaling uit te voeren, verstuurt het verzoek maar verliest de verbinding. De medewerker krijgt geen bevestiging dat het verzoek is geslaagd en probeert de terugbetaling opnieuw aan te vragen. Als het oorspronkelijke verzoek is geslaagd, kan de herhaalde actie van de medewerker leiden tot een tweede terugbetaling.

Dit is puur hypothetisch. Het voorbeeld illustreert een probleem dat niet alleen met modelnauwkeurigheid kan worden opgelost. Welke acties moet een agent ondernemen als deze niet kan vaststellen of een eerdere actie de toestand van de omgeving heeft veranderd?

Unite.AI heeft de betrouwbaarheid van agenten ook buiten de modellen om onderzocht. Herstelproblemen verdienen in die discussies eigen regels. Een agent moet eerst bevestigen wat er is gebeurd, of beschikken over een geldige garantie tegen dubbele gevolgen, voordat deze een actie met aanzienlijke gevolgen opnieuw uitvoert.

Een antwoord dat uitblijft, bewijst niet dat een actie is mislukt

Een antwoord dat uitblijft, bewijst niet dat een actie is mislukt. Het zegt niet of er vóór de uitvoering een fout is opgetreden, of de actie zonder bevestiging is voltooid, of dat het proces nog loopt.

Dit is een veelvoorkomend probleem in gedistribueerde systemen, zoals beschreven door Amazon. Amazon legt uit waarom mechanismen voor nieuwe pogingen specifieke waarborgen nodig hebben tegen herhaalde neveneffecten. Agenten voegen een nieuwe besluitvormende entiteit toe aan het herstelpad van je systeem. Ze kunnen aanvullende beslissingen nemen over hoe ze van fouten herstellen.

Deze beslissingen kunnen de manier waarop een bedrijf werkt veranderen. Zo is een terugbetaling opnieuw aanvragen voor een ander bedrag in dollars niet zomaar een nieuwe poging om hetzelfde verzoek uit te voeren. Ook is het kiezen van een tweede betaaldienst nadat de eerste niet meer reageert niet simpelweg een nieuwe poging om hetzelfde verzoek uit te voeren.

Teams moeten onderscheid maken tussen toestemming geven om een actie uit te voeren en toestemming geven om te herstellen van een onbekende uitkomst. De oorspronkelijke goedkeuring betekent niet dat het veilig is om de actie opnieuw uit te voeren.

Recent onderzoek brengt het risico in kaart

Een preprint uit september 2026, “Where Does Exactly-Once Live?”, introduceerde de LIMBO-benchmark en testte 25.930 episodes op negen modellen. De gesimuleerde diensten werden getest met verloren bevestigingen, vertraagde verwerking en dubbele leveringen.

Van de 1.279 episodes in de hoofdtest van de auteurs waarin een dubbel effect ontstond, rapporteerden agenten in 90% van de gevallen dat de taak was geslaagd. Een agent kan dus succes melden, zelfs wanneer de verwerking onjuist is verlopen.

Deze resultaten zijn gebaseerd op gecontroleerde benchmarks en geven geen schatting van de uitvalpercentages in productieomgevingen. De diensten waren gesimuleerd en verschillende analyses waren verkennend. Teams moeten de resultaten van de acties van agenten afzonderlijk beoordelen van hun meldingen dat de uitvoering is geslaagd.

In het artikel wordt ook uitgelegd waarom het controleren van de huidige status onvoldoende kan zijn. Een verzoek dat nog wordt verwerkt, kan pas na de controle effect hebben. Zelfs een lege statusreactie betekent niet dat het verzoek uiteindelijk geen effect zal hebben.

Herhaalde pogingen hebben betrekking op dezelfde intentie

Een ontvangende dienst kan herhaalde pogingen voor één bewerking herkennen met behulp van een idempotentiesleutel. Als deze methode goed wordt ondersteund, voorkomt ze dat herhaalde pogingen extra effecten veroorzaken. De idempotentiesleutel moet bij alle nieuwe pogingen hetzelfde blijven.

De API-documentatie van Stripe geeft voorbeelden van zowel de werking als de beperkingen van idempotentiesleutels. Voor API v1 kunnen sleutels na minimaal 24 uur worden verwijderd. Als je een verwijderde sleutel opnieuw gebruikt, wordt er een nieuw verzoek aangemaakt. Stripe controleert ook of de door de aanvrager opgegeven parameters overeenkomen met die van het oorspronkelijke verzoek.

De praktische toepassing van idempotentie is dat deze in je integratielaag moet zijn ingebouwd, en niet alleen in een prompt. Leg de goedgekeurde bewerking vast voordat je deze verstuurt. Sla de identificatie ervan op, evenals de exacte parameters, indien van toepassing de verwijzing naar de provider en de status van de bewerking.

Leg bij een terugbetaling de koppeling vast tussen de goedkeuring en de oorspronkelijke transactie, evenals eventuele identificatiegegevens van de terugbetaling die de provider terugstuurt. Zoeken naar een terugbetaling met hetzelfde bedrag is minder overtuigend bewijs, omdat twee legitieme verzoeken hetzelfde bedrag kunnen hebben. Er kan ook vertraging zitten tussen een verzoek om terugbetaling en het moment waarop dit in de zoekresultaten verschijnt. Het oorspronkelijke verzoek kan nog steeds in behandeling zijn.

Wanneer een agent of worker opnieuw wordt gestart, moet de uitvoeringslaag die identiteit behouden. De laag moet een aangepast verzoek afwijzen als dat als dezelfde bewerking wordt ingediend. Zo’n wijziging is een nieuwe actie waarvoor volgens de workflowregels een nieuwe goedkeuringsbeslissing nodig is.

Beschrijvingen van tools zijn niet voldoende

Controleer naast beschrijvingen van tools ook de overeenkomst van de ontvangende dienst voor ondersteuning van idempotentie. Test de implementatie om na te gaan welke garanties daadwerkelijk worden geboden.

Behandel onzekerheid als een operationele toestand

Figuur 1. Een voorgesteld herstelpad voor acties met aanzienlijke gevolgen. Voor elke nieuwe poging is ook actuele toestemming nodig.

Bij bevestigde voltooiing documenteert de workflow het resultaat en gaat deze verder zonder de actie te herhalen. Bevestigde niet-uitvoering staat een nieuwe poging alleen toe als er geen oorspronkelijk verzoek meer in behandeling is en de autorisatie nog steeds van kracht is.

Bij een onduidelijke uitkomst moet nog veel meer worden overwogen. Als de provider een geldige garantie biedt dat er geen dubbele effecten optreden, mag je toestaan dat het oorspronkelijke verzoek met dezelfde sleutel opnieuw wordt geprobeerd. Zo niet, schort dan verdere schrijfacties op en stel de status vast via een statusaanvraag, ondersteuning van de provider of een bevoegde medewerker. Een niet-sluitende controle biedt onvoldoende reden om een nieuwe poging toe te staan.

Pauzeren kan ook gerechtvaardigd zijn wanneer de provider grenzen voor de verwerking en zichtbaarheid documenteert. Zonder zulke grenzen bevestigt alleen het verstrijken van de tijd niet dat de actie niet is uitgevoerd. Je moet bepalen wie verantwoordelijk is voor onopgeloste gevallen en wanneer die verantwoordelijken deze moeten beoordelen.

Herstel na een mislukking vereist mogelijk een ander bedrijfsproces

Als een terugbetaling slaagt, maar de daaropvolgende melding aan de klant mislukt, kan het herhalen van de volledige workflow de terugbetaling opnieuw in gang zetten. Herstel moet gericht zijn op het voltooien van de onafgeronde stap, met behoud van bewijs van het werk dat al is uitgevoerd.

Als corrigerende acties nodig zijn voor eerder voltooide acties, geeft Microsoft richtlijnen voor compenserende transacties. Elke toepassing bepaalt zelf hoe fouten het best kunnen worden gecompenseerd. Compensatie brengt de situatie niet noodzakelijkerwijs terug naar de oorspronkelijke toestand, en ook de compensatie zelf kan mislukken.

Bovendien kan het annuleren van een transactie kosten met zich meebrengen. Een bericht corrigeren biedt geen garantie dat iemand de eerdere versie niet heeft gezien. Daarom moet bij elke herstelactie expliciet worden afgebakend wat de agent ongedaan mag maken, mag wijzigen of mag toezeggen. Beslissingen buiten deze grenzen moeten worden voorgelegd aan iemand met de vereiste bevoegdheid.

Test de tweede poging voordat je de oplossing uitrolt

Kies één tool met ingrijpende gevolgen en voer in een testomgeving gerichte hersteltests uit. Laat na een geslaagde uitvoering de reactie op het oorspronkelijke verzoek wegvallen. Stel de uitvoering van het eerste verzoek uit tot na een statuscontrole. Start tijdens het herstel de worker opnieuw op. Wacht tot de bewaartermijn van de sleutel is verstreken voordat je het opnieuw probeert. Wijzig bij herhaalde pogingen één parameter.

Beoordeel de resulterende bedrijfsgegevens in plaats van alleen op toolreacties te vertrouwen. Registreer dubbele effecten, onopgeloste bewerkingen, gemist werk, de hersteltijd en extra handmatige tussenkomsten. Bereken de kosten per correct voltooide taak op basis van de totale workflowkosten, waaronder het terugdraaien van transacties en compensatie aan klanten.

Test daarnaast een daadwerkelijk tweede verzoek dat vergelijkbaar is met het oorspronkelijke. Zorg ervoor dat je systeem duplicaten voorkomt zonder nieuw werk te blokkeren. Beoordeel het voorkomen van duplicaten en de uiteindelijke voltooiing van taken afzonderlijk. Anders kan een agent die elke taak beëindigt veilig lijken, terwijl die weinig of geen waarde levert.

Formuleer de evaluatievraag duidelijk. Kon het systeem uitleggen:

• Voor welke bewerking was toestemming gegeven?
• Welk bewijs was er voor de uitkomst?
• Waarom was een nieuwe poging toegestaan?

Een agent die pauzeert vanwege onopgeloste onzekerheid kan tijdens demonstraties minder effectief lijken. In productieomgevingen kan pauzeren echter de oorspronkelijke bedoeling van de klant beschermen. Nuttige volharding houdt in dat het systeem geautoriseerde taken voltooit zonder ze ongemerkt dubbel uit te voeren.