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” gaat niet over het wegsturen van mensen; het gaat over het houden van die ene persoon in de kamer die exact kan zeggen hoe goed eruitziet.
01Anekdotische aanleiding
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. Het ging er nooit om dat AI-systemen collega's zijn; het ging erom 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 mijn eerste obsessie was de voor de hand liggende voor iedereen die teams herschikt: hoe ontwerp ik de structuur die ieder mens in dit team de absolute vrijheid geeft om op zijn werkelijke plafond te presteren? Ik had het whiteboard. Ik had de communicatielijnen. Ik had de verantwoordelijkhedenmatrix. Ik had het allemaal uitgetekend zoals je zou verwachten.
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 zonder verpinken opvangen.
02Conceptuele wending
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. Niets daarvan is een belofte over de komende zeven maanden; het is hoe de recente cadans eruit heeft gezien.
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 echt 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.
03Raamwerk
Dus hoe bouw je daadwerkelijk een Agent Inclusive organisatie? In mijn ervaring is het geen software-aankoopkwestie, ook al belandt het bijna altijd als zodanig op de agenda. Het 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. In werkelijkheid is het een structureel risico — en het onderzoek is meedogenloos specifiek over de kosten.
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.
Diezelfde wrijving is, wanneer een agent haar tegenkomt, geen heffing. Het is 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 glasheldere prioriteiten. Behandel interne documentatie niet als decoratieve presentaties voor stakeholdermanagement, maar als de broncode van hoe het team echt werkt. Standaardiseer het formaat op schone Markdown. De technische reden is dat Markdown nu het formaat is dat je toekomstige agentic teamgenoten het efficiëntst lezen — wezenlijk minder tokens dan het equivalente HTML, een betekenisvol lagere inferentiekost in retrieval-augmented pipelines, en een meetbare verbetering in retrievalnauwkeurigheid in de RAG-benchmarks (gemeten in mijn eigen homelab-opstelling; richtinggevend consistent met openbare engineeringliteratuur, maar geen peer-reviewed resultaat, dus behandel de orde van grootte als mijn datapunten, geen wet). De menselijke reden is dat de discipline van Markdown schrijven je dwingt om visuele decoratie weg te strippen en te zeggen wat je echt 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. Markdown voor de backend. HTML voor de ogen. Eén bron van waarheid aan 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, niet bij het systeem. De helderheid is het geschenk. Mensen verdienen het te weten welke input ze krijgen, binnen welke grenzen ze mogen opereren, en hoe "goed" er eigenlijk uitziet 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 stilletjes 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.
Hier is de parallel waar ik steeds op terugkom. 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 stilletjes. Mijn betoog is simpelweg dat een mens minstens zoveel helderheid verdient — geef een mens dus dezelfde helderheid die je een agent zou geven. Niet omdat mensen systemen zijn. Maar omdat de helderheid die we de machine reflexmatig gunnen, dezelfde helderheid is 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 als een krachtversterker te gebruiken in plaats van als een vage bedreiging voor zijn baan.
04Uitnodiging
Een Agent Inclusive team bouwen gaat niet over het vervangen van het menselijke element. Het gaat over het wegnemen van de wrijving die het menselijke element al jaren stilletjes verstikt.
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 stilletjes 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 in plaats van technisch — het lastigere probleem is of het team is gebouwd om de volgende capaciteit op te nemen wanneer die landt, niet of de capaciteit arriveert.
Stop met wachten tot de volgende reorganisatie is uitgekristalliseerd. Zet de defensieve draaiboeken uit. Ruim de bronbestanden op. Schrijf het PDP dat je zelf zou willen ontvangen. En ontwerp het team voor de snelheid van de komende twaalf maanden, niet van de afgelopen twaalf.
Als je serieus met deze vraag bezig bent binnen je eigen organisatie — vooral als je een bestuur hebt dat "Agent Inclusive" nog behandelt als marketingtaal in plaats van als operating model — laat het me weten. Ik zou graag willen weten wat je hebt gebouwd.
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. Het artikel gebruikt dit bewijs alleen richtinggevend; specifieke cijfers worden niet geclaimd.
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 versies van GPT, Claude, Gemini, Llama).
If any claim here is mis-cited or out of date, mail me at rt.nl/contact and I'll fix or retract.