Stop met losse AI-agents stapelen: bouw eerst een agent-register voor je directieprocessen

Als ik bij een founder of COO meekijk in hun stack, tel ik gemiddeld vier tot tien AI-agents die ergens draaien. Eentje labelt mails in Gmail. Eentje vat Slack-threads samen. Een tweede AI-notetaker schrijft mee in calls. Iemand uit sales heeft een agent gebouwd die leads in HubSpot scoort. Finance heeft een GPT die facturen uit Stripe leest. Support draait een bot bovenop tickets.

Niemand heeft een lijst. Niemand weet welke rechten elk van die agents heeft. Niemand weet wat er gebeurt als de bouwer vertrekt.

Dit patroon heeft een naam: agent sprawl. Het is dezelfde fout die teams tien jaar geleden maakten met microservices — overal kleine diensten bouwen zonder centraal register, met als gevolg duplicatie, inconsistente standaarden en operationele chaos. Bij AI-agents is het erger, omdat ze autonoom handelen, permissies opbouwen en namens jou met klanten praten.

Een vaak geciteerd Fortune 100-voorbeeld zegt genoeg: een recruiting-afdeling deployde veertien aparte sourcing-agents, elk met eigen permissies en eigen data-retentie. Resultaat: GDPR-overtredingen én tegenstrijdige berichten naar dezelfde kandidaat. Geen techniekfout. Een governance-fout.

Een agent-register is geen platform of vendor. Het is een centrale catalogus — desnoods een Notion-database om te beginnen — waarin elke AI-agent in je bedrijf staat met zijn identiteit, eigenaar, versie, capaciteiten, endpoints, toegangsrechten en audit logs.

Zie het als het HR-systeem voor je AI-medewerkers. Een model registry houdt statische ML-artefacten bij. Een agent registry beheert levende, autonome programma's die redeneren, handelen en met andere systemen praten. Dat is een ander beest.

De kernfuncties die je minimaal wil afdekken: registratie (elke agent dient een metadata-payload in voordat hij iets mag doen), discovery (teams en andere agents kunnen vinden wat er al bestaat), access control met fijnmazige RBAC, audit logging van elke aanroep, en lifecycle management — inclusief expliciete retirement.

Dat laatste punt onderschatten operators massaal. Een agent uit dienst nemen moet net zo serieus als een werknemer offboarden: rechten intrekken, credentials vernietigen, integraties loskoppelen. Anders blijven er zombie-agents draaien die niemand meer monitort maar die wel toegang houden tot je Gmail of Pipedrive.

Ik dwing operators die met me werken om voor elke agent vijf dingen vast te leggen voordat hij iets mag aanraken in productie.

Eigenaar. Eén mens met naam en achternaam. Niet 'het ops-team'. Als de agent vannacht een verkeerde mail stuurt naar een investeerder, wie wordt er gebeld?

Trigger. Wat zet de agent in beweging? Een nieuwe mail in een Gmail-label? Een deal die in HubSpot naar 'closed-won' gaat? Een Linear-issue dat een specifiek label krijgt? Een Stripe-webhook? Als je de trigger niet in één zin kan opschrijven, snap je de agent niet.

Brondata en scope. Tot welke systemen heeft de agent toegang, en met welke permissies? Het uitgangspunt moet least-privilege zijn: eigen service-account, ephemeral credentials, geen brede persistente rechten. De recruiting-case hierboven gebeurde precies omdat elke agent zijn eigen rechten verzamelde.

Escalatiepad. Wat gebeurt er als de agent twijfelt of een fout maakt? Naar welke inbox, welk Slack-kanaal, welke persoon? Een agent zonder escalatiepad is een agent die stilletjes verkeerde dingen doet.

Kill switch. Eén knop, één commando, om de agent per direct te stoppen en zijn credentials in te trekken. Je weet pas dat je governance op orde is als je dit binnen vijf minuten kan uitvoeren — op een vrijdagavond, zonder de bouwer.

Een COO die ik volg had vorig kwartaal drie agents die elk een stuk van het sales-proces aanraakten: één verrijkte leads in HubSpot, één schreef opvolgmails vanuit Gmail, één maakte Calendly-uitnodigingen aan. Geen van de drie wist van elkaars bestaan.

Gevolg: dubbele opvolging naar dezelfde prospect, conflicterende toon, en één keer een mail die uitging vóórdat de account executive de deal had gezien. Niet omdat de agents slecht waren — ze deden precies wat ze moesten doen. Maar er was geen router, geen volgorde, geen eigenaar van het geheel.

De fix was niet 'betere prompts'. De fix was een register waarin de drie agents als één workflow stonden, met de AE als eigenaar, een trigger-volgorde, en de afspraak dat de Gmail-agent niets verstuurt zonder menselijke approval in de eerste twee weken.

Hetzelfde zie ik in finance. Stripe, een AI die facturen leest, een agent die betalingsherinneringen stuurt vanuit Outlook. Werkt prima — tot een klant betaalt, de Stripe-webhook één seconde te laat binnenkomt, en de herinneringsagent alsnog een boze mail stuurt naar je grootste account. Eén register, één escalatiepad naar de CFO, klaar.

In engineering hetzelfde verhaal: agents die Linear-issues triëren of PR's samenvatten. Nuttig, totdat er drie verschillende AI-comments onder dezelfde PR staan en niemand meer weet welke leidend is.

AI-agents zijn goed in patronen herkennen, herhalend werk wegnemen, en context samenvatten over kanalen heen. Ze zijn niet goed in oordelen vellen die afhangen van politiek, vertrouwen of historische context die nergens is opgeschreven.

Dat is precies waarom een goede Chief of Staff — menselijk of AI — niet meer agents toevoegt, maar agents verbindt. Het verschil tussen een goede CoS en een task manager zit in de greep op de threads die anders door de mazen vallen: de investeerder die je drie weken geleden iets beloofde, het besluit dat in de vrijdagmeeting half werd genomen, de klant die nog wacht op een antwoord van iemand die deze week vrij is.

Dat is werk dat één AI-agent niet doet. Dat is werk dat een geöorkestreerd systeem van agents doet — mits er een register is dat weet wie wat mag, wanneer het escaleert, en wie de eigenaar is.

Bij Moments AI bouwen we de orkestratielaag bovenop je inbox, agenda, CRM en documenten met dit principe als uitgangspunt: elke actie heeft een trigger, een eigenaar en een escalatiepad. Geen aparte bots stapelen, maar één governance-laag waarin ze samenwerken. Dat is ook waarom we klanten actief tegenhouden om méér agents te activeren voordat de basis staat.

Je hoeft geen leverancier te kiezen om hieraan te beginnen. Open een Notion-pagina of een spreadsheet en doe vier dingen.

Eén: inventariseer. Schrijf elke AI-agent op die ergens in je bedrijf draait, inclusief de shadow-deployments die iemand op een vrijdagmiddag heeft gebouwd. Vraag het expliciet in elk team — je zal verbaasd zijn.

Twee: vul voor elke agent de vijf velden in: eigenaar, trigger, brondata en scope, escalatiepad, kill switch. Als een veld leeg blijft, pauzeer die agent tot het ingevuld is. Niet 'we kijken er nog naar'. Pauzeren.

Drie: zet een terugkerende review in. Eén keer per kwartaal loop je het register door: welke agents worden niet meer gebruikt, welke permissies zijn opgeblazen, welke eigenaars zijn vertrokken. Behandel dit als access reviews voor mensen.

Vier: maak registratie verplicht voor alles wat erbij komt. Geen nieuwe agent in Gmail, HubSpot, Slack of waar dan ook, zonder eerst die vijf velden. Dit is de simpelste regel die agent sprawl stopt voordat hij begint.

De operators die ik zie schalen met AI zijn niet degenen met de meeste agents. Het zijn degenen die elke agent kunnen aanwijzen, uitleggen en desnoods binnen vijf minuten kunnen uitzetten.

Dat is geen rem op innovatie. Dat is de voorwaarde ervoor.