Agents ontwerpen die netjes falen

Iedereen kan een agent bouwen die werkt zolang alles goed gaat. Het interessante engineeringwerk zit in de andere tien procent — de timeout, het misvormde antwoord, de tool die plat ligt. Een goede agent vermijdt falen niet. Hij faalt op een manier waar je mee kunt leven.

"Graceful degradation" is een oud idee, geleend uit de systeemengineering: als er iets stukgaat, moet het systeem terugvallen op een lagere maar nog steeds bruikbare modus in plaats van helemaal om te vallen. Agents hebben dezelfde discipline nodig, want ze falen vaker en op creatievere manieren dan gewone code.

Maak falen een volwaardige uitkomst

De eerste fout is succes behandelen als de enige tak. Een agent-stap heeft minstens drie eerlijke afloopmogelijkheden: hij heeft het gedaan, hij kon het niet en weet waarom, of hij weet het niet zeker. Als je ontwerp alleen de eerste afvangt, lekken de andere twee naar buiten als zelfverzekerde onzin.

Modelleer ze expliciet. In een flow betekent dat dat een stap "klaar", "gefaald" of "controle nodig" kan uitsturen — en dat de gateway erna elk daarvan naar een zinnige plek doorstuurt. Onzekerheid is geen bug meer, maar een tak.

De drie guardrails die hun waarde bewijzen

• Retries met backoff. De meeste storingen zijn tijdelijk — een rate limit, een hapering. Probeer het een paar keer opnieuw met oplopende vertraging voordat je escaleert. Zorg er alleen eerst voor dat het werk idempotent is, zodat een retry niet twee keer dezelfde e-mail verstuurt.
• Fallbacks. Als het rijke pad faalt, is er dan een eenvoudiger pad dat nog steeds bruikbaar is? Kun je de lead niet verrijken via de betaalde API? Val dan terug op wat al in het dossier staat, in plaats van de run op te geven.
• Validatie aan de grens. Controleer de uitvoer van de agent tegen wat de volgende stap daadwerkelijk nodig heeft voordat je die doorgeeft. Een goedkope schemacontrole vangt het gehallucineerde veld af voordat het drie systemen verderop in de keten corrumpeert.

Een agent die zegt "ik weet het niet zeker, dit is wat ik heb" is er tien waard die zelfverzekerd gokken.

Beperk de schade-straal

Als een stap echt faalt, moet de storing lokaal blijven. Dat is het stille voordeel van agents orkestreren binnen een flow in plaats van één megaprompt alles te laten doen: een kapotte node stopt die ene node. De run pauzeert met een duidelijke reden, de rest van de context blijft intact, en je kunt één enkele stap opnieuw uitvoeren in plaats van de hele wereld over te doen.

Falen moet leesbaar zijn

De laatste guardrail is geen code — het is het bericht. "Er ging iets mis" vertelt niemand iets. "Kon de facturatie-API na 3 pogingen niet bereiken; gepauzeerd voor controle" vertelt een operator precies wat te doen. Schrijf je faaltoestanden zoals je een foutmelding aan een collega zou schrijven: wat er gebeurde, wat je hebt geprobeerd, en wat er nu nodig is.

Bouw agents die buigen, niet die doen alsof. De teams die automatisering vertrouwen, zijn niet de teams wier systemen nooit falen — het zijn de teams wier systemen falen op manieren die ze begrijpen.