De server valt een keertje uit. Wat telt, is wat er behouden blijft.

Het is tien over twee in de nacht van maandag op dinsdag. Een AI agent werkt al veertig minuten aan een lange taak. Dan wordt de server opnieuw opgestart. Misschien vanwege een update, een volle schijf of omdat de hostingpartij de machine heeft verplaatst.

De volgende ochtend ziet iemand dat de taak niet is afgerond en start die opnieuw. De taak begint weer van voren af aan en een klant ontvangt dezelfde e-mail twee keer.

Dit soort situaties is niet uitzonderlijk. Niemand heeft iets doms gedaan. Dit is wat er kan gebeuren wanneer een systeem een gewone nacht doormaakt.

Eén team meldde dat één binnenkomende aanroep een betaalde pipeline twee of drie keer startte. Een ander team zag dat een lange tool call na een nieuwe poging nogmaals werd uitgevoerd, waardoor zowel het werk als de kosten verdubbelden. Een derde team ontdekte dat een agent een schrijfactie herhaalde die al was uitgevoerd. Daardoor kreeg een extern systeem een dubbele invoer. Eén team kwam erachter dat de database maanden oud was nadat de hostingpartij de server had verplaatst.

De details verschillen, maar de les is dezelfde. Een server waarop AI agents draaien, valt op een dag uit, op een moment dat u niet zelf kiest. De nuttige vraag is niet hoe u dat volledig voorkomt, maar wat er daarna nog beschikbaar is en welke acties mogelijk dubbel worden uitgevoerd.

Een AI agent genereert niet alleen tekst. Via tools voert die ook acties uit in andere systemen. Lees onze uitleg over wat een AI agent is als u daar meer over wilt weten. Wanneer een server onverwacht stopt, staan er dus drie dingen op het spel. Houd ze goed uit elkaar.

• De lopende run. De stap waarop de agent was gebleven en de positie in de flow.
• Het runverslag. Wat het systeem heeft vastgelegd: welke stappen zijn gestart, wat elke stap heeft ontvangen en teruggegeven, en welke fouten zijn opgetreden.
• De bijwerkingen (side effects). Wat de run buiten het systeem al heeft gedaan: de verzonden e-mail, de afgeschreven betaling of de toegevoegde regel in een ander systeem.

Na een herstart gedragen deze drie zich niet op dezelfde manier. Een herstelplan dat ze als één geheel behandelt, loopt vast op precies dat onderdeel dat over het hoofd is gezien.

EpicStaff draait op uw eigen infrastructuur. U bepaalt dus wanneer back-ups worden gemaakt en waar de kopieën worden bewaard. Runverslagen staan in uw eigen PostgreSQL-database. Maak daarnaast een back-up van de bestandsopslag. Uploads en bestanden die tijdens een run worden gemaakt, staan in een aparte bestandsopslag (MinIO), waarvoor u een afzonderlijke back-up nodig hebt. Maakt u alleen een back-up van de database, dan kunt u een runverslag terugzetten dat verwijst naar bestanden die niet meer beschikbaar zijn.

EpicStaff legt het runverslag vast terwijl elke stap en tool call plaatsvindt. Het model vat het werk dus niet pas achteraf samen. Als de server stopt, bevat het verslag al het werk dat tot dat moment is vastgelegd. EpicStaff registreert elke stap zodra die begint. Zelfs als een run blijft hangen, kunt u daarom nog zien welke stap als laatste is gestart. Bekijk die registratie als eerste na een herstart.

Ook de flow blijft behouden. Elke run bewaart een kopie van de flow zoals die op dat moment werd uitgevoerd. Latere wijzigingen verbergen dus niet wat er tijdens de afgebroken run gebeurde. U kunt benoemde versies van een flow opslaan en een eerdere versie terugzetten. Gewoon opslaan maakt echter geen nieuwe versie aan. Sla daarom een benoemde versie op voordat u een flow aanpast die ’s nachts wordt uitgevoerd.

Meer over wat een bruikbaar runverslag bevat: De AI agent is klaar. Niemand kan zeggen wat hij deed.

Als de server tijdens een run opnieuw wordt opgestart, gaat de run niet verder. De status verandert uiteindelijk in ‘expired’ (verlopen), waarna u de run opnieuw moet starten. Totdat de tijdslimiet is verstreken, kan de status nog op ‘running’ staan. Na een herstart betekent ‘running’ dus niet dat de run nog actief is. Wacht totdat de status ‘expired’ verschijnt.

U kunt een run niet hervatten vanaf de stap waarop die is mislukt. Een nieuwe run begint helemaal opnieuw.

Daar moet u bij het bouwen van flows rekening mee houden. Deze maatregelen helpen bij elke tool:

• Verdeel langdurige taken over kleinere flows. Een herstart kost dan hooguit één korte flow in plaats van een uur werk.
• Plaats goedkope stappen die alleen gegevens lezen vooraan en stappen die acties uitvoeren in andere systemen achteraan.
• Plan updates en herstarts buiten de uren waarin lange runs worden uitgevoerd.

EpicStaff voorkomt niet dat een stap twee keer wordt uitgevoerd. Acties zoals betalingen en e-mails hebben daarom een eigen controle nodig om dubbele uitvoering te voorkomen. Als een nieuwe run helemaal opnieuw begint, worden ook stappen die al acties in andere systemen hebben uitgevoerd opnieuw uitgevoerd.

Er zijn twee gangbare manieren om dubbele uitvoering te voorkomen.

De eerste is een idempotency key (idempotentiesleutel). De term is technisch, maar het idee is eenvoudig. U geeft elke actie in de buitenwereld een unieke sleutel die is opgebouwd uit gegevens die bij nieuwe pogingen hetzelfde blijven. Denk bijvoorbeeld aan een ordernummer in combinatie met ‘factuur-email’. U stuurt die sleutel mee met de actie. Heeft de ontvangende dienst dezelfde sleutel al eerder gezien, dan voert die de actie niet nogmaals uit. Veel betaaldiensten ondersteunen dit soort sleutels.

De tweede mogelijkheid is een controle waarmee u nagaat of de actie al is uitgevoerd. Voordat de stap de actie uitvoert, controleert die een eigen kleine tabel: staat de betreffende sleutel er al in? Zo ja, dan wordt de actie overgeslagen. Zo nee, dan wordt de actie uitgevoerd en de sleutel daarna geregistreerd. Stopt de server tussen de uitvoering en het vastleggen van die registratie, dan is een dubbele actie nog steeds mogelijk. Als dat risico onaanvaardbaar is, moet u ook bij het ontvangende systeem controleren of de actie al is uitgevoerd voordat u deze opnieuw uitvoert.

Neem deze controle op in de code die de actie uitvoert, niet in de instructies van de agent. Een model kan een instructie negeren. Een controle die in code is vastgelegd, wordt op die manier niet afhankelijk van de instructies van het model.

Eén geplande herstart leert u meer dan een maand lezen. Gebruik een testomgeving, een testmailbox en testgegevens. Doorloop deze stappen voor elke tool, ook die van ons. Onder elke stap staat wat u bij EpicStaff kunt verwachten.

1. Start een lange run en herstart de server halverwege. Gaat de run verder? EpicStaff: nee. Als de server tijdens een run opnieuw wordt opgestart, gaat de run niet verder. De status verandert uiteindelijk in ‘expired’ (verlopen), waarna u de run opnieuw moet starten. Noteer hoe lang de status ‘running’ zichtbaar blijft voordat de run als verlopen wordt gemarkeerd.
2. Open het runverslag van de afgebroken run. Kunt u zien hoever de run is gekomen? EpicStaff: ja. EpicStaff registreert elke stap zodra die begint. Ook als een run blijft hangen, kunt u dus zien welke stap als laatste is gestart.
3. Probeer de run opnieuw te starten vanaf de stap waarop die is mislukt. Kan dat? EpicStaff: nee. Een nieuwe run begint helemaal opnieuw. Maak een lijst van de stappen die daardoor opnieuw acties in andere systemen zouden uitvoeren.
4. Voer een stap die een e-mail verstuurt twee keer uit. Voorkomt de tool dat de tweede e-mail wordt verstuurd? EpicStaff: nee. EpicStaff voorkomt niet dat een stap twee keer wordt uitgevoerd. Acties zoals betalingen en e-mails hebben daarom een eigen controle nodig om dubbele uitvoering te voorkomen. Voeg een idempotentiesleutel of een andere controle toe, voer de stap opnieuw twee keer uit en controleer of er maar één e-mail wordt verstuurd.
5. Zet de back-up van de vorige nacht terug op een reservemachine. Zijn zowel de runverslagen als de bestanden beschikbaar? EpicStaff: runverslagen staan in uw eigen PostgreSQL-database en de bestanden in een aparte bestandsopslag. Maak van beide een back-up en zet beide terug. Open vervolgens een oud runverslag en controleer of u ook een bestand kunt openen dat tijdens die run is gemaakt.
6. Controleer welke flow werd uitgevoerd. Kunt u de flow bekijken zoals die op dat moment was en teruggaan naar een eerdere versie? EpicStaff: ja. Elke run bewaart een kopie van de flow zoals die werd uitgevoerd. U kunt benoemde versies opslaan en een eerdere versie terugzetten.
7. Leg de uitkomst vast. Wie start na een incident de runs opnieuw? Wie controleert eerst welke acties al zijn uitgevoerd? Wanneer vindt de volgende oefening plaats? EpicStaff: dit bepaalt u zelf. Het gaat om de afspraken binnen uw team, niet om de software.

De server zal een keer uitvallen. Als u deze oefening eenmaal hebt uitgevoerd, is de volgende ochtend gewoon een werkdag in plaats van een incident.