Agent Inclusive.
De korte versie: naarmate AI-agents meer van de uitvoering overnemen, is het werk dat menselijk blijft het schrijven van de brief — vage bedoelingen omzetten in een specificatie die precies genoeg is om een agent ermee aan de slag te laten gaan. “Agent inclusive” houdt mensen erbij: om precies te zijn die ene persoon in de kamer die exact kan zeggen hoe goed eruitziet.
01Een ondernemingsraad voor agents
Ik zei vorige week bij de koffie tegen een collega dat ik erover dacht een ondernemingsraad voor AI-agents op te richten.
Ik zei het als grap; ik zie AI-systemen niet als collega's. Wat ik bedoelde, was dat we de rest van het kantoor al rond onze collega's bouwen — inwerktrajecten, documentatie, escalatieroutes, beoordelingsgesprekken — en dat al die structuur er niet is voor de AI-systemen die we in dezelfde workflows zetten. Ze lachte precies zoals de grap dat vroeg. We gingen verder, we hadden het over andere dingen, de koffie werd koud. En toen weigerde die zin de volgende drie dagen mijn hoofd te verlaten.
Hij bleef hangen omdat er onder de bedrijfsironie een stuk architectuur door schemerde dat ik niet helemaal kon loslaten. Ik had net een rol met een bredere scope op me genomen en was een teamstructuur opnieuw aan het tekenen: whiteboard, rapportagelijnen, een verantwoordelijkhedenmatrix, het gebruikelijke werk. De vraag eronder was eenvoudig: hoe zet ik dit zo op dat ieder mens zijn beste werk kan doen?
En terwijl ik die lijnen trok, bleef er één zin in mijn hoofd rondgaan op een manier die ik serieus heb leren nemen:
Deze organisatie moet Agent Inclusive ontworpen worden.
Dát was wat niet wegging. Niet "AI-enabled." Niet "AI-augmented." Agent Inclusive. In de zin van: als het volgende lid van dit team binnenloopt en geen mens is, moet de structuur dat kunnen opvangen.
02Het snelheidsverschil
De reden dat die zin bleef hangen is een rekensom die bijna geen enkele onderneming al heeft verinnerlijkt.
Organisatieverandering gaat traag. Zelfs als het ongewoon goed wordt uitgevoerd — een helder mandaat, een echt budget, verandermanagement van topniveau — kost het verschuiven van menselijke cultuur, het opnieuw uitlijnen van business units en het stabiliseren van nieuwe manieren van werken in de gemiddelde onderneming ergens tussen de twaalf en achttien maanden. McKinsey zal je vertellen dat, aan de achterkant van die programma's, 70% van hen hun gestelde strategische doelen alsnog mist tegen de tijd dat ze officieel afgerond worden verklaard. Bain zal je vertellen dat zelfs de geslaagde programma's in de twaalf maanden na de verandering een productiviteitsdip van 41% opleveren — wat de literatuur inmiddels "survivor syndrome" noemt — plus een vrijwillig verloop van 15 tot 20% onder precies de toppresteerders die je het hardst nodig had om te houden. Dat is de snelheid en dat zijn de kosten van mensen verschuiven op een organigram.
Kijk nu naar de andere kant van de snelheidsvergelijking. In de afgelopen periode hebben de meest geavanceerde AI-modellen ongeveer elke zes weken een grote iteratie uitgebracht — vijf grote versies in de zeven maanden waarin ik het scherpst meekeek. Contextvensters die ruwweg verdubbelden. Redeneerkosten die snel dalen. De tooling eromheen — orchestratieframeworks, agent-runtimes, retrieval-architecturen — beweegt minstens zo snel. Dat beschrijft de recente cadans; het belooft niets over de komende zeven maanden.
Dat betekent dat een volledig professionele reorganisatie van twaalf maanden, vandaag gestart, zal eindigen tegen de achtste of negende grote modelrelease sinds zij begon. De structuur die je zo zorgvuldig hebt ontworpen, is verouderd op de dag dat zij stabiliseert.
Als je wacht tot je organisatietransformatie klaar is voordat je serieus gaat nadenken over hoe je AI integreert in hoe het team werkt, ontwerp je voor een wereld die dan al drie generaties in het verleden ligt.
De conclusie waar ik op ben uitgekomen is de ongemakkelijke. Je kunt AI niet behandelen als een software-integratie die je op een team aansluit nadat het team gebouwd is. Je moet het team zó bouwen dat een agentic teamgenoot kan binnenlopen, op dag één kan aanschuiven en kan bijdragen zonder dat iemand de kamer voor hem hoeft te vertalen.
03Twee upgrades
Dus hoe bouw je een Agent Inclusive organisatie? In mijn ervaring belandt het bijna altijd als software-aankoopkwestie op de agenda. Wat het vraagt, zijn twee upgrades van het operating model, en je kunt deze week met allebei beginnen.
1. Verminder operationele dubbelzinnigheid.
Elke organisatie waar ik ooit ben binnengekomen heeft plekken in de operatie die volledig draaien op tribale chemie. Twee of drie mensen die al zo lang samenwerken dat ze gestopt zijn met dingen opschrijven, omdat ze "gewoon weten hoe het gaat." We hebben de neiging dit te romantiseren als institutioneel geheugen, maar het is een structureel risico, en onderzoekers hebben de kosten in cijfers uitgedrukt.
De gemiddelde kenniswerker in een onderneming, volgens IDC en McKinsey, besteedt 30% van zijn werkdag — zo'n 2,5 uur — aan het zoeken naar informatie die hij nodig heeft om zijn werk te doen. Zevenenveertig procent van de digitale werkers geeft aan moeite te hebben om data binnen hun eigen organisatie te vinden. Die zoekheffing stapelt op: een nieuwe medewerker in een ongestructureerde omgeving doet er zes tot acht maanden over om op een basisniveau van productiviteit te komen, tegenover drie tot vier maanden wanneer dezelfde functie een schone, vastgelegde set standaard werkprocedures heeft. Twintig procent van de nieuwe medewerkers vertrekt binnen de eerste negentig dagen als de inwerkomgeving ongestructureerd is, tegen gemiddelde vervangingskosten van net geen elfduizend euro per persoon. Gestructureerde documentatieprogramma's verbeteren het behoud op dezelfde functie met 82%.
Er is een naam in de literatuur voor waar dit op neerkomt. Het heet het "vijfde medewerker"-fenomeen: elk team van vijf functioneert in feite met vier, omdat één voltijdsequivalent aan capaciteit permanent wordt opgeslokt door zoeken, navragen en het reconstrueren van context die al als één zin ergens zou moeten staan waar een mens of een model hem kan vinden.
Voor een agent is die wrijving een bakstenen muur. Een agent kan de ongeschreven politieke kamer niet lezen. Hij kan de senior collega tijdens de lunch niet vragen wat het team eigenlijk bedoelt met "Q3-prioriteiten." Hij kan de presentatie niet interpreteren waarvan de maker achttien maanden geleden vertrok.
Dus de eerste stap is onglamoureus en concreet. Vertaal dubbelzinnige bedrijfstaal naar expliciete doelen, precieze timing en heldere prioriteiten. Behandel interne documentatie als de broncode van hoe het team werkt, en schrijf haar niet langer als decoratie voor stakeholdermanagement. Standaardiseer het formaat op schone Markdown. De technische reden is dat agents Markdown veel goedkoper lezen dan HTML. In mijn eigen homelab-tests gebruikten dezelfde documenten in Markdown 68–87% minder tokens dan het equivalente HTML, en steeg de retrievalnauwkeurigheid met zo'n 35%. Dat is mijn eigen opstelling en geen peer-reviewed resultaat, dus behandel de orde van grootte als mijn eigen datapunten; de richting komt overeen met wat openbare engineeringblogs melden. De menselijke reden is dat Markdown schrijven je dwingt om visuele decoratie weg te strippen en te zeggen wat je bedoelt.
Voor het mensgerichte oppervlak render je diezelfde Markdown terug naar schone HTML, zodat je team het kan lezen zonder de meetbare sprongen in informatie-overload en beslismoeheid — en de daling in geconcentreerd werk — die opduiken wanneer mensen urenlang gedwongen worden om ruwe machine-output te verwerken. Eén bron van waarheid bedient beide kanten.
2. Geef mensen de helderheid die je een agent zou geven.
De tweede stap is persoonlijker, en volgens mij belangrijker.
Begin bij de persoon. De helderheid is het geschenk. Mensen verdienen het te weten welke input ze krijgen, binnen welke grenzen ze mogen opereren, en hoe "goed" eruitziet aan het eind van de komende twee kwartalen. De meesten van ons hebben gewerkt onder het tegenovergestelde — beoordeeld op een maatstaf die niemand kon verwoorden — en het is ondermijnend. Dit is dus meer een persoonlijke managementfilosofie dan een bewering over hoe PDP's in het wild worden gevoerd: het meest respectvolle dat je voor iemand kunt doen, is precies zijn over wat je van hem vraagt.
Persoonlijke ontwikkelplannen zijn, in de meeste ondernemingen die ik heb gezien, het tegenovergestelde daarvan. Een HR-ritueel. Generieke competenties. Vage groeizinnen. Een score van 1 tot 5 tegen een leiderschapsraamwerk dat iemand in 2014 schreef. Ze zijn geschreven om auditeerbaar te zijn, niet om nuttig te zijn — en degene die het ontvangt voelt dat.
De parallel zit in hoe we agents bouwen. Wanneer we een serieus agentic systeem ontwerpen, worden we gedwongen exact te zijn: de input, de guardrails, de succescriteria, de verwachte output, de escalatievoorwaarden. Vaagheid in een van die velden breekt het systeem weken later ongemerkt. Mijn betoog is simpelweg dat een mens minstens zoveel helderheid verdient — geef een mens dus dezelfde helderheid die je een agent zou geven. Mensen zijn geen systemen, maar de helderheid die we de machine reflexmatig gunnen, is dezelfde helderheid die we elkaar telkens weer niet weten te gunnen.
Wanneer je iemand dat niveau van helderheid geeft over wat er van hem gevraagd wordt, geef je hem ook de schone aanloop die hij nodig heeft om de agentic tools om zich heen aan het werk te zetten, zodat ze niet langer voelen als een vage bedreiging voor zijn baan.
04Hetzelfde geschenk
Een Agent Inclusive team bouwen neemt wrijving weg die de mensen erin al jaren uitput.
Wanneer de documentatie schoon is geschreven, stoppen je senior mensen ermee 30% van hun week te besteden aan het beantwoorden van vragen die ze al vier keer hebben beantwoord. Wanneer de PDP's bouwplannen worden, stoppen je beste mensen zich af te vragen of ze worden beoordeeld op een maatstaf die niemand kan verwoorden. Wanneer de bronbestanden van het team als echte bronbestanden worden behandeld, heeft de volgende agent die je binnenhaalt geen integratieproject van zes maanden nodig — die kan op dag één de kamer lezen.
Het vreemde en licht contra-intuïtieve gevolg hiervan is dat de meest rigoureus Agent Inclusive organisatie die ik kan ontwerpen ook de meest rigoureus mensrespecterende is. De helderheid is het geschenk. De agent heeft toevallig gewoon hetzelfde geschenk nodig dat de senior mens op stoel 1A altijd nodig heeft gehad en zelden heeft gekregen.
De tools zijn goed en, op recent bewijs, ze blijven beter worden. Als de cadans van de laatste tijd aanhoudt, is het model waarmee je over een kwartaal werkt waarschijnlijk weer een stap vooruit. Maar hoe langer ik hierbij stilsta, hoe meer de beperking organisatorisch aanvoelt: het lastigere probleem is of het team is gebouwd om de volgende capaciteit op te nemen wanneer die landt.
Wacht dus niet tot de volgende reorganisatie is uitgekristalliseerd. Ruim de bronbestanden van het team op, schrijf het PDP dat je zelf zou willen ontvangen, en ontwerp het team voor de snelheid van de komende twaalf maanden.
Benieuwd waar je op uitkomt.
Where the numbers came from.
Gestructureerde Markdown-documentatie verlaagt de tokenkost wezenlijk en verbetert de RAG-retrievalnauwkeurigheid ten opzichte van proza.
Specifieke percentages (68–87% tokenreductie, ~35% nauwkeurigheidswinst) komen uit de eigen homelab-RAG-benchmarkruns van de auteur, 2024–2026. Vergelijkbare richtinggevende resultaten worden gemeld op openbare engineeringblogs (LangChain, LlamaIndex, Pinecone); de exacte cijfers hier moeten worden behandeld als datapunten uit de opstelling van de auteur, niet als universele benchmarks.
Gestructureerd inwerken (vastgelegde doelen, PDP's, escalatieroutes) heeft een meetbaar effect op behoud en inwerksnelheid.
Vastgesteld in de managementonderzoeksliteratuur — zie Bauers SHRM Foundation-review over onboarding op shrm.org · Onboarding New Employees voor een representatieve samenvatting. Die review onderbouwt de richting van deze sectie. De specifieke inwerkcijfers in de tekst (zes tot acht maanden tegenover drie tot vier om op basisproductiviteit te komen, 20% van de nieuwe medewerkers die binnen negentig dagen vertrekt, vervangingskosten van net geen elfduizend euro, en 82% beter behoud) hebben op deze pagina geen eigen bronvermelding.
Reorganisatiecycli duren 12–18 maanden, terwijl de meest geavanceerde AI-modellen op een cadans van ~6 weken uitkomen.
De bandbreedte van de reorganisatiecyclus is consistent met de rapportage over transformatieprogramma's van McKinsey & Deloitte (12–24 maanden voor materiële reorganisaties). Het cijfer voor de modelcadans is waarneembaar in de releasetijdlijnen van toonaangevende AI-labs, 2023–2026 (grote modelversies).
If any claim here is mis-cited or out of date, mail me at rt.nl/contact and I'll fix or retract.