Het idee is verleidelijk: als één Ai-agent nuttig werk doet, dan doen vijf agents tegelijk vijf keer zoveel werk in dezelfde tijd. Gratis snelheid, toch? Ik ben er met open ogen ingelopen, twee keer zelfs, op twee heel verschillende manieren. De eerste keer overschreven mijn agents stilletjes elkaars werk. De tweede keer legden ze mijn hele server plat. Beide keren was het geen bug in de Ai, maar een ontwerpfout van mij. En allebei zijn ze goed te voorkomen als je weet waar je op moet letten.

Het stille conflict: agents die elkaars werk overschrijven#

De eerste val is de gemeenste, want hij maakt geen geluid. Ik had meerdere agents tegelijk aan het werk gezet aan onderdelen van hetzelfde project. Op papier keurig verdeeld. Maar in de praktijk grepen ze allemaal naar dezelfde paar centrale bestanden: het configuratiebestand, het bestand waarin de routes van de applicatie staan, een gedeeld stuk logica. En als twee agents naar hetzelfde bestand schrijven, geldt er een keiharde regel: de laatste wint. De wijziging van de eerste agent verdwijnt geruisloos, alsof hij nooit heeft bestaan.

Er is een variant die nog vervelender is. In veel systemen krijgen databasewijzigingen een tijdstempel mee als volgnummer, zodat de volgorde vastligt. Als twee agents onafhankelijk van elkaar zo’n tijdstempel kiezen, kunnen ze zomaar hetzelfde nummer pakken of in de verkeerde volgorde belanden. Dan klopt de volgorde niet meer, en dat merk je pas als er iets veel verderop kapotgaat. Geen foutmelding op het moment zelf, wel een raadsel een uur later.

Het patroon achter beide: parallelle schrijvers conflicteren stil. Er springt niets op rood. Het werk lijkt gedaan, tot je merkt dat een deel ervan spoorloos is.

De oplossing bleek verrassend eenvoudig, zodra ik doorhad wat er speelde. Drie regels:

  1. Geef elke agent een exclusief bestandsdomein. In de opdracht leg ik expliciet vast: jij bent eigenaar van déze bestanden, en van geen andere. Twee agents mogen nooit hetzelfde bestand als eigendom hebben. Geen overlap, geen conflict.
  2. Geef elke agent zijn eigen werkkopie. In plaats van dat iedereen in dezelfde map graait, krijgt elke agent een eigen geïsoleerde kopie van het project om in te werken. Pas achteraf voeg je de resultaten samen, gecontroleerd, op één plek.
  3. Deel volgnummers vooraf uit. Moet er iets met tijdstempels of volgnummers gebeuren, dan wijs ik die van tevoren toe, met genoeg ruimte ertussen, zodat geen twee agents ooit voor dezelfde grijpen.

Kort samengevat: gedraag je als een goede projectleider. Je laat geen twee mensen ongecoördineerd in hetzelfde document werken, en met agents is dat niet anders.

Research is de uitzondering, maar met een limiet#

Er is één soort werk waar parallelle agents juist wél soepel gaan: onderzoek dat alleen maar leest en niets verandert. Meerdere agents die tegelijk bronnen doorzoeken en elk hun eigen ruis wegfilteren, kunnen prima naast elkaar bestaan, want ze schrijven niet naar dezelfde plek. Daar botst niets.

Toch heb ik ook daar een grens gezet: maximaal drie tegelijk voor research. Niet vanwege conflicten, maar omdat elke agent capaciteit en geld kost, en omdat de meerwaarde van de vierde en vijfde snel afneemt terwijl de kosten gewoon doortikken. Drie is voor mij de plek waar snelheid en beheersbaarheid elkaar raken. En dat brengt me bij de tweede val, want die grens heb ik niet uit voorzorg bedacht. Ik heb hem geleerd.

De dag dat vijf jobs mijn server sloopten#

Op een gegeven moment had ik een reeks taken die allemaal op vaste, ronde tijdstippen startten. Netjes ingepland, elk op het hele of het halve uur. Wat ik me niet had gerealiseerd: elk van die taken laadde een fors Ai-model in het geheugen, van elk zo’n vijf gigabyte. En doordat ze allemaal op precies hetzelfde klokmoment begonnen, probeerden ze dat geheugen ook allemaal tegelijk te pakken.

Het resultaat was een klokvaste geheugenstorm. De server had simpelweg niet genoeg werkgeheugen voor vijf van die modellen tegelijk, dus greep het besturingssysteem in en begon processen af te schieten om overeind te blijven. Op één dag telde ik 54 van dat soort noodgedwongen afschietingen, waarvan een reeks binnen een half uur, precies rond de klokmomenten waarop alles tegelijk startte. Werk dat halverwege werd afgekapt, taken die niet afliepen, en een server die tegen zichzelf aan het vechten was.

Wat me het meest bijbleef: er was niet één simpele fix. Ik moest vier dingen tegelijk doen om het echt op te lossen, want elk van de vier dichtte maar één lek:

  1. Een limiet op wat er tegelijk mag draaien. Nooit meer dan één van die zware modellen tegelijk in het geheugen.
  2. Gespreide starttijden. Niet alles op het ronde uur, maar een paar minuten uit elkaar, zodat de pieken elkaar niet overlappen.
  3. Een enkel-slot-slot. Een mechanisme dat garandeert dat er maar één zware klus tegelijk begint. Komt er een tweede aankloppen terwijl de eerste bezig is, dan wacht die netjes of slaat over.
  4. Een geheugencheck vooraf. Voordat een zware taak start, kijkt hij eerst of er genoeg vrij geheugen is. Zo niet, dan slaat hij deze ronde over in plaats van de server onderuit te trekken.

Alleen alle vier samen brachten rust. Eén ervan alleen dempte de storm niet voldoende. Dat is de les die ik meeneem naar elke situatie waarin dingen op een vast ritme externe klussen aftrappen: verwacht niet dat één maatregel genoeg is, en verwacht al helemaal niet dat “netjes op ronde tijden inplannen” veilig is. Juist die synchrone starts zijn het probleem.

Wat betekent dit voor jouw bedrijf?#

Je hoeft geen dertig agents te draaien om deze valkuilen tegen te komen. Zodra je meer dan één stuk automatisering tegelijk laat werken, gelden dezelfde vragen:

  • Wie is eigenaar van wat? Als twee processen ongecoördineerd naar dezelfde plek schrijven, verlies je stilletjes werk. Verdeel het eigendom expliciet en zorg dat er geen overlap is.
  • Botsen ze op een gedeelde bron? Denk niet alleen aan bestanden, maar ook aan volgnummers, geheugen, en verbindingen. Conflicten daar geven zelden een nette foutmelding.
  • Wat gebeurt er als alles tegelijk begint? Vaste, ronde starttijden voelen ordelijk, maar ze laten je pieken samenvallen. Spreid ze, en bouw een rem in voor als de capaciteit toch krap wordt.

De rode draad is dat parallel werken geen gratis snelheid is, maar coördinatiewerk. De Ai wordt niet dommer als je er meer naast elkaar zet; jouw ontwerp wordt alleen belangrijker. Wie dat vooraf regelt, plukt de vruchten. Wie het overslaat, betaalt met verdwenen werk of een omgevallen server, en meestal pas op het slechtst denkbare moment.

Wil je sparren over hoe je automatisering in je eigen bedrijf betrouwbaar opzet, zonder dit soort stille valkuilen? Kijk dan op de consulting-pagina hoe ik werk. En om zelf te bepalen wat je een automatisering wél en niet zelfstandig laat doen, is er een gratis werkdocument bij de downloads.