De workflow die alles meesleepte in zijn val

Het is maandag, iets na achten. Een flow die de dossiers van vorige week samenvat, start volgens planning. Deze week is de hoeveelheid werk twee keer zo groot. De flow gebruikt steeds meer geheugen, maar komt niet klaar.

Om twintig over acht reageert het aanmeldformulier op de website niet meer. Niemand heeft iets veranderd aan de flow voor het aanmeldformulier. Die draait alleen op dezelfde server als de grote flow.

Om negen uur start iemand de server opnieuw op. De planning start de grote flow opnieuw, en de ochtend begint weer van voren af aan.

Er was niets kapot. Het platform deed waarvoor het was gebouwd. Het team wist alleen niet waar de limieten lagen.

Eén team meldde dat stappen die minutenlang op een externe AI-taak wachtten, een time-out van de gateway kregen. Het team haalde het langdurige werk uit de workflowtool en zette het in een wachtrij.

Eén gebruiker draaide één omgeving voor meerdere betalende klanten. Die gebruiker meldde dat een lang spraakgesprek voor één klant, met een lus die steeds opnieuw de status opvroeg, de webhook van een andere klant blokkeerde. Later gaf de gebruiker elke klant een eigen omgeving, met een harde geheugenlimiet.

Een andere gebruiker meldde dat één workflow door een gebrek aan geheugen de volledige gehoste omgeving urenlang onbereikbaar maakte. Opnieuw opstarten hielp niet, omdat de workflow daarna weer begon. De gebruiker kon geen manier vinden om alleen die workflow uit te schakelen terwijl het platform onbereikbaar was.

Een derde team meldde dat één grote run een schijf van 120 GB vol maakte, waardoor de omgeving en de gebruikersinterface uitvielen. Er was vooraf geen waarschuwing. Nadat het team bijna alle oude runs had verwijderd, was het databasebestand nog steeds groot. Pas na een handmatige opschoning terwijl de dienst was gestopt, kwam er weer schijfruimte vrij.

Vier tools, vier configuraties, maar hetzelfde patroon: er was een limiet en niemand had die vastgelegd.

Een AI agent doet meer dan tekst schrijven. Een agent roept tools aan, wacht op andere systemen en houdt tijdens het werk gegevens in het geheugen. Lees ook wat een AI agent is. Bij al deze activiteiten gebruikt de agent middelen die op een server niet onbeperkt beschikbaar zijn. Vier limieten zijn daarbij het belangrijkst:

Tijd: wat een taak stopt als die te lang duurt, en wanneer dat gebeurt. Gedeelde capaciteit: hoeveel middelen één zware run aan andere runs onttrekt. De uitknop: hoe u één flow stopt terwijl de rest blijft draaien. De schijf: welke gegevens blijven groeien en wie ze opruimt. Deze limieten zitten in de harness, de runtime-laag waarin uw agents draaien, en niet in het model zelf. Hieronder leest u hoe elke limiet in EpicStaff werkt. Wilt u weten wie toezicht houdt op deze laag? Lees dan wie controleert de agent-harness.

In EpicStaff heeft elke flow een eigen tijdslimiet die u per flow instelt. Deze limiet meet de tijd sinds de status van de run voor het laatst is veranderd, niet de totale duur van de run. U kunt de tijdslimiet voor een flow ook uitschakelen.

Binnen een run gelden nog andere limieten. Voor Python-stappen geldt één systeembrede time-out die de beheerder instelt. Als een Python-stap deze time-out bereikt, stopt EpicStaff de stap en alle processen die door die stap zijn gestart. Elke agent kan daarnaast een eigen maximale uitvoeringstijd hebben. Ook kunt u een tokenbudget voor een run instellen.

De vraag 'Hoe lang mag een taak duren?' heeft dus niet één antwoord. Controleer elke laag aan de hand van de langste stap in uw workflow: de flow, de Python-stap, de agent en het tokenbudget.

In EpicStaff kan één zware run andere runs vertragen. De beheerder bepaalt hoeveel runs tegelijk worden uitgevoerd.

Elke Python-stap draait in een eigen proces. Alle Python-stappen delen één geheugenlimiet. Er is geen afzonderlijke geheugenlimiet of CPU-limiet per stap.

Houd bij het plannen van uw workflows rekening met het volgende:

Stel het maximale aantal gelijktijdige runs af op wat uw server aankan wanneer de zwaarste flow draait, niet op basis van een gemiddelde belasting. Plan zwaar batchwerk buiten de uren waarin snelle flows, zoals flows die op webhooks reageren, veel worden gebruikt. Als klanten onder geen beding elkaars prestaties mogen beïnvloeden, geef dan elke klant een eigen installatie. Dit geldt voor elke tool.

Een flow in EpicStaff heeft geen eigen aan-uitknop. U kunt de planning uitschakelen en een lopende run stoppen. Webhook- en Telegram-triggers kunt u niet uitschakelen.

Bepaal daarom vooraf voor elke flow die via een webhook wordt gestart waar u de binnenkomende aanroepen kunt tegenhouden: bij het systeem dat ze verstuurt of bij de gateway vóór EpicStaff. Noteer die keuze naast de naam van de flow. Tijdens een incident wilt u dat niet meer hoeven uitzoeken.

EpicStaff heeft een maximale bestandsgrootte en een maximale uploadgrootte. De beheerder kan deze limieten aanpassen. Stel ze in op basis van de grootste bestanden die uw flows daadwerkelijk nodig hebben.

EpicStaff verwijdert oude runs en bestanden niet automatisch. Een runsessie verdwijnt alleen wanneer een gebruiker deze verwijdert. Plan daarom de opschoning: bepaal hoe lang u runs bewaart, wie ze verwijdert en hoe vaak dat gebeurt. Houd daarnaast het schijfgebruik van de server in de gaten en stel een waarschuwing in die ruim op tijd afgaat, voordat de schijf vol raakt.

Gebruik een testomgeving die qua capaciteit vergelijkbaar is met uw productieomgeving. Voer deze controles uit voor elke tool, ook die van ons. Onder elke controle staat wat u bij EpicStaff kunt verwachten.

Start uw langste taak. Wat stopt de taak als deze blijft hangen, en op welke laag gebeurt dat? EpicStaff: er gelden limieten op verschillende niveaus. Elke flow heeft een eigen tijdslimiet die meet hoe lang de status van de run ongewijzigd blijft. Python-stappen hebben een time-out die de beheerder instelt. Elke agent kan een eigen maximale uitvoeringstijd hebben en u kunt een tokenbudget voor een run instellen. Voer uw zwaarste flow uit en start tegelijkertijd een kleine flow die via een webhook wordt aangeroepen. Wordt de kleine flow trager? EpicStaff: dat kan. Eén zware run kan andere runs vertragen. De beheerder bepaalt hoeveel runs tegelijk worden uitgevoerd. Meet de reactietijd met één, twee en vier zware runs tegelijk. Voer een Python-stap uit die veel geheugen gebruikt, terwijl ook een normale stap draait. Heeft de normale stap daar last van? EpicStaff: dat kan. Alle Python-stappen delen één geheugenlimiet. Er is geen afzonderlijke geheugen- of CPU-limiet per stap. Elke Python-stap heeft wel een tijdslimiet. Probeer één flow uit te schakelen terwijl de bijbehorende triggers actief blijven. Lukt dat? EpicStaff: gedeeltelijk. U kunt een planning uitschakelen en een lopende run stoppen. Webhook- en Telegram-triggers kunnen niet worden uitgeschakeld. Test daarom ook de manier waarop u de aanroepen bij de afzender of de gateway wilt tegenhouden. Upload een bestand dat groter is dan de ingestelde limiet. Wordt het geweigerd? EpicStaff: ja. Er gelden limieten voor de bestandsgrootte en de uploadgrootte. De beheerder kan deze aanpassen. Controleer of oude runs en bestanden automatisch worden opgeruimd. Gebeurt dat? EpicStaff: nee. EpicStaff verwijdert oude runs en bestanden niet automatisch. Een runsessie verdwijnt alleen wanneer een gebruiker deze verwijdert. Leg vast wie de opschoning uitvoert en wanneer. Vul een testschijf tot 80 procent van de capaciteit. Wie ontvangt de waarschuwing? EpicStaff: deze controle gaat over de monitoring van uw server, niet over de tool. Stel de waarschuwing in bij uw servermonitoring en controleer wie de melding ontvangt.

Zet de antwoorden op deze zeven controles op één pagina en bewaar die bij uw draaiboek. Noteer ook hoeveel runs uw server tijdens de tweede controle gelijktijdig aankon.

Volgende maandag draait de grote flow opnieuw. Dit keer weet u hoeveel capaciteit die kan gebruiken en waar u kunt ingrijpen om te voorkomen dat de rest mee uitvalt.