Retries, timeouts en dode agents: betrouwbaarheid in de praktijk
Een agent kan vastlopen of een actie onverwacht herhalen. Lees hoe time-outs, begrensde retries, hervatbare stappen, statusbewaking en menselijke escalatie zulke fouten beheersbaar maken.
Een betrouwbare agent is niet een agent die nooit faalt. Het is een agent die ook bij fouten beheersbaar blijft: met duidelijke time-outs, begrensde herpogingen, veilig te herhalen acties en een zichtbare status. Zo blijft een vastgelopen taak niet ongemerkt hangen en wordt een actie niet zomaar dubbel uitgevoerd.
Dat vraagt om afspraken voor elke stap én voor de hele taak. Je bepaalt hoe lang een agent op een antwoord wacht, wanneer hij opnieuw probeert, hoe je controleert of een actie al is uitgevoerd en wanneer een mens moet ingrijpen. Daarmee maak je fouten niet onmogelijk, maar wel zichtbaar en beter herstelbaar.
Waardoor agents vastlopen
Een agent voert vaak meerdere stappen achter elkaar uit en is daarbij afhankelijk van modellen, netwerkverbindingen en externe tools. Een tool kan traag reageren, een verbinding kan wegvallen of een model kan blijven genereren zonder bruikbaar antwoord. Ook kan een agent wachten op een resultaat dat nooit terugkomt, of telkens opnieuw een stap plannen die geen voortgang oplevert.
Van buitenaf lijken die situaties soms hetzelfde: er gebeurt niets. De oorzaak bepaalt echter wat een veilige reactie is. Een tijdelijke netwerkfout kan een nieuwe poging rechtvaardigen; een onduidelijke betaling of verstuurde e-mail vraagt eerst om controle. Kijk daarom niet alleen of een proces nog draait, maar ook of het werk inhoudelijk vooruitgaat. Zie ook agent-observability voor manieren om gedrag en voortgang zichtbaar te maken.
Time-outs per stap en voor de hele taak
Een time-out stelt een grens aan het wachten. Gebruik waar nodig een grens per stap: bijvoorbeeld voor een modelantwoord of een externe toolaanroep. Daarnaast helpt een maximale duur voor de volledige taak. Zonder die tweede grens kan een agent binnen afzonderlijke limieten blijven, maar door veel opeenvolgende stappen alsnog eindeloos doorgaan.
De passende duur verschilt per taak en afhankelijkheid. Een snelle gegevensopvraag vraagt meestal om een andere verwachting dan een verwerking die op een extern systeem wacht. Kies grenzen op basis van wat de taak nodig heeft en maak duidelijk wat er gebeurt als een grens wordt bereikt: de stap kan opnieuw worden geprobeerd, de taak kan als mislukt worden gemarkeerd of het werk kan naar een medewerker gaan.
Een time-out betekent niet altijd dat de actie is mislukt. De verbinding kan zijn verbroken nadat de externe dienst het verzoek al heeft verwerkt. Behandel een onzekere uitkomst daarom anders dan een bevestigde fout. Controleer bij risicovolle acties eerst de status voordat je opnieuw uitvoert.
Retries zonder herhaling van schade
Een retry is een nieuwe poging na een tijdelijke fout. Beperk het aantal pogingen en voeg wachttijd toe voordat je opnieuw probeert. Een oplopende wachttijd kan voorkomen dat een agent een overbelaste dienst direct opnieuw bestookt. Welke wachttijd passend is, hangt af van de dienst, de fout en de taak; een retrybeleid is dus geen universele instelling.
Niet elke fout is tijdelijk. Een ongeldige invoer wordt niet vanzelf geldig als je dezelfde aanvraag herhaalt. Herhaal daarom alleen fouten waarvoor een nieuwe poging zinvol kan zijn, en stop na een vastgesteld maximum. Leg vast wat daarna gebeurt, zodat de taak niet stilzwijgend blijft proberen.
Bij acties met gevolgen is idempotentie belangrijk. Dat betekent dat dezelfde opdracht meerdere keren uitvoeren hetzelfde eindresultaat oplevert als één keer uitvoeren. Als een agent bijvoorbeeld een verzoek verstuurt en het antwoord kwijt raakt, kan hij anders onbedoeld twee verzoeken aanmaken. Gebruik waar mogelijk een unieke sleutel of controleer eerst of de actie al is verwerkt. Sommige externe systemen bieden hiervoor geen goede ondersteuning; in dat geval moet je de onzekerheid expliciet behandelen, bijvoorbeeld door controle door een medewerker.
Status, heartbeat en hervatten
Een statusveld laat zien wat de agent doet: bijvoorbeeld gestart, bezig met een bepaalde stap, wachtend, afgerond of vastgelopen. Een heartbeat is een periodieke melding dat het proces nog actief is. Als die melding uitblijft, kan een bewakingssysteem onderzoeken of de agent werkelijk gestopt is. Een heartbeat alleen bewijst geen voortgang: een proces kan nog leven terwijl het steeds dezelfde stap herhaalt. Combineer de status daarom met informatie over de laatst voltooide stap en het tijdstip daarvan.
Sla tussenstappen op wanneer een taak na een onderbreking moet kunnen doorgaan. Bewaar genoeg om te weten wat al is afgerond, welke invoer daarbij hoorde en wat de volgende stap is. Hervatten mag niet blindelings dezelfde actie herhalen: controleer eerst of die actie al effect heeft gehad. Bewaar bovendien alleen gegevens die nodig zijn om de taak uit te voeren en te controleren.
Een duidelijke status helpt ook mensen. Die moeten kunnen zien of een taak bezig is, wacht op een externe dienst, is gestopt of aandacht nodig heeft. Voor achtergrond over het bewaren en terugvinden van context bij agents, zie continu geheugen voor agents.
Wanneer stoppen en een mens waarschuwen
Laat een agent stoppen en waarschuw een mens wanneer de pogingen op zijn, de uitkomst van een actie onzeker blijft of een volgende stap gevolgen kan hebben die niet automatisch terug te draaien zijn. Denk aan een betaling, een juridische toezegging of een bericht aan een klant. Ook tegenstrijdige gegevens, ontbrekende toestemming of een herhaald patroon zonder voortgang zijn redenen om te escaleren.
De waarschuwing moet genoeg context geven om verder te kunnen: welke taak vastliep, welke stap bezig was, welke fout optrad, wat al is geprobeerd en of een externe actie mogelijk al is uitgevoerd. Zo hoeft een medewerker niet vanaf nul te onderzoeken wat de agent heeft gedaan. Vangrails voor AI-agents beschrijven hoe je zulke grenzen vooraf inricht.
Logging, storingen testen en checklist
Log gebeurtenissen die helpen om fouten te begrijpen: begin en einde van stappen, time-outs, retries, statuswijzigingen, externe acties en escalaties. Leg ook de relevante taak- of correlatie-ID vast, zodat je gebeurtenissen bij elkaar kunt zoeken. Beperk gevoelige gegevens in logs en bepaal wie ze mag bekijken. Stel alerts in voor situaties die actie vragen, zoals taken die hun tijdslimiet bereiken of processen waarvan de heartbeat wegvalt. Een logboek is pas nuttig als iemand weet welke signalen opgevolgd moeten worden.
Test de foutafhandeling bewust. Simuleer bijvoorbeeld een trage tool, een verbroken verbinding, een antwoord dat uitblijft en een agent die zonder voortgang blijft draaien. Controleer daarna of de time-out ingrijpt, retries begrensd blijven, een actie niet dubbel plaatsvindt, de status klopt en een medewerker de juiste melding krijgt. Herhaal deze controles wanneer de taak of een belangrijke afhankelijkheid verandert.
Gebruik deze checklist bij het ontwerpen of beoordelen van een agent:
- Heeft elke stap een passende time-out en heeft de hele taak een maximale duur?
- Zijn retries beperkt, voorzien van wachttijd en alleen bedoeld voor fouten die opnieuw proberen waard zijn?
- Kun je veilig controleren of een externe actie al is uitgevoerd voordat je die herhaalt?
- Geven status en heartbeat samen voldoende zicht op voortgang en stilstand?
- Kan de taak hervatten vanaf opgeslagen stappen zonder werk dubbel uit te voeren?
- Weet je wanneer de agent stopt en welke informatie een medewerker dan ontvangt?
- Zijn logs bruikbaar, toegang ertoe beperkt en storingen bewust getest?
Betrouwbaarheid ontstaat door deze onderdelen samen te laten werken. Time-outs begrenzen wachten, retries vangen tijdelijke fouten op, status maakt stilstand zichtbaar en hervatten voorkomt dat een onderbroken taak verloren gaat. Waar de uitkomst onzeker of de impact groot is, blijft een mens de veilige volgende stap bepalen.