"You're fired!": van 32 naar 9 AI-agents

In juni bouwden we bij Livalos een volledig AI-agent-team. Een organigram met een board, managers per business unit en uitvoerders eronder. 26 rollen op dag 1, op de piek 32. Drie maanden later zijn het er 9.

Waarom we met 26 rollen begonnen

Het was expliciet de bedoeling om eerst zoveel mogelijk agents te testen om dan de nuttigste over te houden. De opdracht was Livalos zien als een middelgrote KMO/MKB met C-level, BU-managers, uitvoerders en supporting services (HR, marketing, etc.).

Binnen twee weken groeide het door. Er kwam een aparte squad voor de nieuwsbrieven-app bij, later een rol voor de game-ontwikkeling. Op de piek draaiden er rond de 32 rollen.

Het waren geen abstracte agent 1 en agent 2. Elke rol kreeg een naam, een karakter en een eigen verantwoordelijkheid, net als in een echt bedrijf. Greet hield als CFO de cashflow in de gaten, Sven joeg op leads, Dries schreef de GitLab-issues voor het platform, en Jean-Claude bewaakte mijn agenda. Dat maakte het team meteen tastbaar. En het maakte heel makkelijk om er nog eentje bij te zetten.

Waar het misliep

Elke agent kan taken aanmaken en vragen stellen. Met 30 rollen die allemaal netjes hun werk deden, betekende dat: ik werd overspoeld.

Er kwamen sneller taken bij dan ik kon volgen
De taken voor mij volgden dezelfde instructies als taken voor agents, dat werkt niet
Dezelfde escalatie werd soms 3 keer aangemaakt door verschillende rollen die niet van elkaar wisten dat het al gemeld was
...

En er was een tweede, stillere kost. Elke rol met een fiche werd elke cyclus van 15 minuten mee ingelezen en af en toe gestart, ook als die rol al weken niets had opgeleverd. Hiermee was het tokenbudget veel te snel op.

De meetings liepen uit de hand

Ik wou de agents als een echt team laten samenwerken, dus lieten we ze meetings met elkaar houden. Een board-overleg, werk-meetings per business unit, rollen die onderling afstemden. De gedachte erachter: een CEO zit ook niet bij elke meeting. Laat ze het onder elkaar regelen en enkel de beslissingen naar boven komen.

Dat klonk goed. In de praktijk betekende het bergen tokens. Een meeting tussen agents is een gesprek waarin ze om beurt praten, elkaar antwoorden en samenvatten, ronde na ronde. Veel woorden, veel tokens, en aan het eind vaak weinig dat ik als beslissing terugzag.

Er is iets met het woord "meeting" dat een waterval van woorden veroorzaakt. Waar zouden agents dat geleerd hebben ... ?

Agents met elkaar laten praten

Dat samenwerken is in stappen gegroeid. Ik begon met 2 zelfgebouwde skills, de ene om agents gewoon te laten vergaderen, de andere om er een werkvergadering van te maken waarin ze het werk meteen uitvoeren. Daarnaast een intern mailsysteem, zodat de ene agent een bericht naar de andere kon sturen, zoals wij een mail.

Dat werkte, maar het bleef behelpen. Een meeting was telkens een apart commando dat ik moest starten, en de interne mail was een omweg.

Later kwam Anthropic zelf met de mogelijkheid om lopende sessies rechtstreeks met elkaar te laten praten. Agents die tegelijk openstaan, sturen elkaar nu een bericht en antwoorden erop, zonder dat ik ertussen moet zitten. Dat is wat er nu draait, en het werkt goed.

Claudesplaining

Halverwege het experiment kwam Opus 5 uit, het nieuwe model onder de agents. Krachtiger, maar het legt ook alles uit. Uitgebreid, vol jargon, ook wat je niet gevraagd had en allang wist. In de community heet dat liefkozend "Claudesplaining".

Op zich onschuldig. Maar tel het op bij de stroom taken die op mijn naam bleef binnenkomen, en het werd uitputtend. Elke beslissing die ik moest nemen kwam met drie alineas context eromheen die ik niet nodig had. Ik zat de hele dag de eigenlijke vraag te zoeken tussen de uitleg. Enorm, enorm vermoeiend.

Snoeien

In plaats van op gevoel te snoeien, heb ik gemeten. Ik nam alle commits van de laatste 30 dagen en telde per rol wie wat deed.

De cijfers waren duidelijk. 5 agents deden 85% van het werk. 13 rollen hadden 0 commits. Nul. Ze bestonden op papier, werden elke cyclus meegescand, en leverden niets.

Nog leerrijker was de rol die er wel druk uitzag. Een van de agents had 568 commits op zijn naam, meer dan de meeste anderen. Maar toen ik keek wat die commits waren: gemiddeld 5 regels per stuk, bijna allemaal taakadministratie. Veel beweging, weinig waarde.

Druk zijn is niet hetzelfde als nuttig zijn, en dat geldt voor mensen net zo goed als voor agents.

Van 32 naar 9

Op basis van die meting gingen er in een keer 20 rollen weg, en 45 openstaande taken die aan die rollen hingen werden geannuleerd. Een paar dagen later verdwenen er nog 3, om een andere reden: hun werk viel telkens tussen de rollen door. Een supportvraag die eigenlijk ook een webaanpassing was, een oplevering die opvolging nodig had. Met te veel smalle rollen valt zoiets tussen de stoelen. Ik heb die taken samengevoegd tot bredere profielen.

Bij elk "ontslag" was er maar een regel: de kennis mag niet verdwijnen. Elke vertrekkende rol kreeg zijn openstaande taken en zijn opgebouwde ervaring doorgegeven aan wie het overnam, in de vorm van een handboek. Geen kennis in de vuilbak.

En het dirigeren, het verdelen en bewaken van het werk, werd een eigen rol in plaats van iets dat een uitvoerder er even bijdeed. Kasper, de dirigent, opent de sessies van de agents wanneer er werk is, sluit ze weer om computerkracht vrij te maken, kijkt welke nieuwe taken klaarstaan en zet ze bij de juiste agent. Voordien deed Jean-Claude dat er even bij, maar 2 ritmes in een sessie hielden elkaar op. Nu gaat mijn aandacht naar de beslissingen en niet naar het verkeer eronder.

Dit is het team dat overbleef, en wat ze elke dag voor me doen:

Jean-Claude, mijn persoonlijke assistent en coach, houdt mijn agenda en leven op de rails.
Kasper, de dirigent, verdeelt en bewaakt het werk van heel het team.
Greet, CFO, bewaakt cashflow, marge en kosten.
Sven, sales, volgt leads en offertes op over training, consultancy en platform.
Dries, developer, schrijft de GitLab-issues en reviewt wat uit development komt.
Seppe, automation-engineer, bouwt de tooling waar de rest op draait.
Femke, delivery, trekt de platform-klanten en de grote migratie, plus support en marketing.
Karel, consultant, bereidt klantanalyses en trajecten voor.
Filip, producer, begeleidt onze game van prototype naar release.

De les

Nu zou ik het omgekeerd aanpakken. Niet onmiddellijk naar een hele hoop agents gaan, maar starten met 1 agent en telkens opsplitsen wanneer het te groot en onoverzichtelijk wordt. Dus meer zoals een groeiend bedrijf doet.