Geef je AI-stafchef één router-agent — laat specialisten niet onderling praten

Ik zie hetzelfde misverstand keer op keer bij oprichters die hun eerste AI-laag bouwen. Ze denken: als één agent mijn inbox niet aankan, dan zet ik er gewoon meer naast. Een agent voor e-mail, een voor de agenda, een die HubSpot bijwerkt, een die Linear-tickets aanmaakt. En dan laten ze die vier rechtstreeks met elkaar praten.

Dat is het moment waarop het stil instort. Niet luidruchtig — er gaat geen alarm af. Het wordt alleen langzaam onnavolgbaar wie wat besloot.

De vraag is nooit "hoeveel agents heb ik nodig". De vraag is: hoe zijn ze met elkaar verbonden? Dat is topologie. En de keuze die je daar maakt bepaalt of je over zes maanden nog kunt reconstrueren waarom je AI-stafchef een vergadering verplaatste of een deal als gesloten markeerde.

Mijn standpunt is helder: laat specialist-agents niet onderling praten. Zet er één router-agent tussen, en laat alle coördinatie, context en bevoegdheden via die ene regielaag lopen.

Een router-agent is geen domme verkeersregelaar zoals een API-gateway. Hij begrijpt semantisch wat er binnenkomt, breekt de taak op, kiest de juiste specialist-agent en zet de resultaten weer in elkaar. Hij beheert de context en lost conflicten op.

In een hub-and-spoke model — wat dit feitelijk is — ontvangt die ene router alles. Komt er een mail binnen waarin een klant vraagt om de levering te vervroegen? De router beslist: dit raakt de agenda, het raakt de dealstatus in Pipedrive, en het vraagt om een antwoord. Hij stuurt de deeltaken uit, wacht op de uitkomsten en stelt één coherente reactie samen.

De specialisten kennen elkaar niet. Ze weten niet eens dat de ander bestaat. Ze krijgen een afgebakende opdracht van de router, doen hun werk, geven het terug. Klaar.

Dat klinkt rigide. Het is juist het tegenovergestelde. Het is wat het systeem bestuurbaar houdt naarmate je er meer aan toevoegt.

Zodra agents rechtstreeks met elkaar mogen praten, groeit het aantal communicatiepaden kwadratisch. Vier agents lijkt overzichtelijk. Maar elk paar dat onderling kan schakelen is een verbinding die je moet begrijpen, beveiligen en debuggen. Bij tien agents heb je tientallen paden waar berichten onvoorspelbaar tussen heen en weer kaatsen.

Het eerste wat sneuvelt is je vermogen om fouten te traceren. In een peer-to-peer opzet stuitert een bericht van agent naar agent en raak je het spoor kwijt. In een router-centrische opzet is elke beslissing en elke dataoverdracht traceerbaar via dat ene punt. Dat verschil is concreet: in router-architecturen wordt 100% van de handelingen en datastromen centraal gelogd, tegenover minder dan de helft in netwerken waar agents vrij communiceren.

Dan zijn er de cascades. Eén bug of storing in een agent kan zich razendsnel door het hele netwerk verspreiden. De router daarentegen kan een falende specialist isoleren, de taak opnieuw uitzetten, naar een back-up sturen of escaleren naar jou. De fout blijft ingekapseld in plaats van uit te waaieren.

En dan heb je nog de oneindige lussen. Twee agents die elkaar blijven bevragen zonder dat iemand de noodrem heeft. Zonder centrale guardrails — maximale doorgeeflimieten, timeouts, escalatieprotocollen — gebeurt dat echt.

Hier wordt het bestuurlijk. Als jij je AI-stafchef toegang geeft tot Gmail, je agenda, je contacten, HubSpot en Stripe, dan geef je hem toegang tot beslissingen met gevolgen. Een verkeerd verstuurde mail naar een investeerder. Een verplaatste board-meeting. Een deal die ten onrechte op 'closed won' staat.

Als er iets misgaat, wil je precies kunnen reconstrueren wat er gebeurde. Welke agent deed wat, op basis van welke context, met welke bevoegdheid. In een router-centrisch model is dat één logboek, één keten. In een netwerk waar agents vrij data uitwisselen is het bijna onmogelijk om het beslispad terug te leggen.

De router is ook je enige plek voor toegangscontrole. Daar dwing je rolgebaseerde rechten af, maskeer je gevoelige data en log je elke actie. Eén controlepunt. Elke directe agent-naar-agent verbinding is daarentegen een extra aanvalsvlak — een route voor datalekken en het ongemerkt opschalen van bevoegdheden.

Voor sectoren met compliance-eisen — finance, zorg, kritieke infrastructuur — zijn onveranderlijke audit-logs simpelweg verplicht. Maar ook zonder regelgeving wil je als COO gewoon kunnen uitleggen waarom het systeem deed wat het deed.

Modulariteit is het stille voordeel. Elke specialist heeft een afgebakende, beperkte taak. De router bewaakt de grenzen, zodat agents niet langzaam elkaars werk gaan overnemen. Onderhoud blijft behapbaar.

Nieuwe capaciteit toevoegen is een kwestie van een nieuwe agent registreren bij de router. Wil je dat je stafchef voortaan ook Calendly-boekingen verwerkt of Notion-documenten samenvat? Je voegt een agent toe zonder de bestaande workflows te raken. In een netwerk moet je daarvoor de onderlinge afspraken tussen meerdere agents herzien — en dat is waar versieconflicten en semantische drift ontstaan, waarbij agents hetzelfde begrip nét anders interpreteren.

Kosten lopen ook mee. Door taken precies te routeren voorkom je onnodige LLM-aanroepen. Je vuurt niet vier agents af op een vraag die er één nodig heeft.

De veelgehoorde tegenwerping is dat de router een single point of failure wordt, of een vertraging introduceert. Allebei waar, allebei oplosbaar. Routers kunnen redundant draaien met failover, en horizontaal opschalen op moderne cloud-infrastructuur. En een goede router zet meerdere agents parallel aan het werk — de totale wachttijd wordt begrensd door de traagste agent, niet door de som. Workflows met drie tot vijf agents halen in productie doorgaans responstijden onder de vijf seconden.

Ik wil eerlijk zijn over de grenzen. Directe agent-naar-agent communicatie heeft zijn plek — in zeldzame, strak gekoppelde toepassingen waar milliseconden tellen, zoals real-time robotica-zwermen. Dat zijn uitzonderingen die gespecialiseerde architecturen vragen.

De administratieve realiteit van een oprichter valt daar niet onder. Jouw werkdag is e-mailthreads die wegzakken, een agenda vol contextwisselingen, een CRM dat achterloopt op wat er werkelijk is besproken. Dat zijn precies de taken die baat hebben bij een regielaag die het overzicht houdt — niet bij agents die ongecontroleerd onderling onderhandelen.

Het verschil tussen een echte stafchef en een takenlijst is nu juist dat oordeel: weten wat samenhangt, wat eerst moet, wat naar jou geëscaleerd hoort te worden. Dat oordeel hoort thuis in één regielaag.

Bij Moments hebben we daarom gekozen voor dit model. De stafchef die je inbox, agenda, contacten, documenten en browser aan elkaar knoopt, doet dat via één router — niet via een wolk van agents die elkaar dingen toefluisteren. Niet omdat het de modieuze keuze is, maar omdat het de keuze is die je over een halfjaar nog kunt vertrouwen en kunt uitleggen.