AI-agents opschalen: wat 202 bedrijven laten zien over wat wel en niet werkt

Herkenbaar: je hebt een paar AI-agents aan het werk, maar elke nieuwe agent kost weer net zoveel controle als de vorige. Dat is precies waarom AI-agents opschalen bij de meeste bedrijven vastloopt, blijkt uit nieuw onderzoek van Microsoft en Harvard Business School, gepubliceerd op 27 oktober 2026, onder 202 Amerikaanse bedrijven met meer dan duizend medewerkers. Niet het aantal agents verklaart het verschil tussen bedrijven die er geld aan overhouden en bedrijven die vooral kosten maken. Het zit in of correcties en context automatisch doorstromen naar andere agents, of dat elk team zijn eigen fouten blijft herontdekken. Slechts 3% van de onderzochte bedrijven, zes van de 202, had dat voor alle vier gemeten praktijken al op orde.

Wat het onderzoek naar AI-agents opschalen precies mat

Het onderzoek is geen Microsoft-marketingrapport, al financierde Microsoft het mede. Keystone, een onafhankelijk advies- en technologiebureau, voerde het samen met Microsoft uit en publiceerde de resultaten als Harvard Business School working paper "Organizing AI at Enterprise Scale: Agentic Operating Models and Firm Outcomes" (Sarkar e.a., oktober 2026). Eerst interviewden de onderzoekers leiders bij 29 organisaties met vergevorderde AI-implementaties: 18 AI-native start-ups en 11 gevestigde bedrijven. Op basis daarvan bouwden ze een vragenlijst en legden die tussen juni en september 2026 voor aan 202 Amerikaanse bedrijven met meer dan duizend medewerkers, verdeeld over financiële diensten (42), productie (41), software (30), zorg en life sciences (29), retail (21) en overig (39).

Dit gaat niet over één groot multi-agent systeem dat één taak oplost, maar over tientallen losse agents door de hele organisatie: een klantenservice-bot hier, een factuur-agent daar, een zoekagent voor de salesafdeling. De onderzoekers koppelden de antwoorden aan financiële data van Capital IQ over 2022-2025 (113 bedrijven voor rendement op activa, 97 voor operationele marge), gecorrigeerd voor bedrijfsgrootte en sector.

De onderzoekers onderscheiden vier fasen, gebaseerd op hoeveel van de coördinatie een systeem overneemt van mensen. Bij fase 4-bedrijven had 86% een werkende orchestratielaag, 76% een gedeelde contextlaag en 90% een aangewezen eigenaar voor de uitkomsten van agents. Dat eigenaarschap is precies waar het bij de meeste bedrijven al misgaat: zonder iemand die verantwoordelijk is voor een kennisbron, raakt die kennisbron verweesd zodra de bouwer van de agent iets anders gaat doen.

De vier fasen van AI-agents opschalen: welke past bij jouw bedrijf?

Gebruik deze tabel om je eigen organisatie te plaatsen. De grens tussen fase 2 en fase 3 is de belangrijkste: dat is waar handmatige controle plaatsmaakt voor een systeem dat zelf meeleert.

Belangrijk: de onderzoekers zagen geen keurig oplopende lijn tussen de fasen en financieel resultaat. De marge-verbetering per kwartiel liep ongeveer op van +0,4 naar -0,3 naar +5,1 naar +5,8 procentpunt: eerst een lichte dip, dan een sprong. De auteurs noemen dat zelf een J-vormig patroon, maar konden dat statistisch niet hard bevestigen. Lees het dus als "de sprong komt pas laat", niet als een gegarandeerde groeilijn.

De grootste valkuil bij het opschalen van AI-agents: controle door mensen in plaats van een systeem

Het is verleidelijk om een eerste agent gewoon te laten draaien en fouten op te vangen door er een extra paar ogen bij te zetten. Dat werkt bij één of twee agents. Het houdt op te werken zodra je bij tien of vijftien agents zit, want de controle-capaciteit die je nodig hebt, groeit recht evenredig mee met het aantal agents. Een systeem dat fouten vastlegt en teruggeeft, groeit dat niet: één correctie is dan voor alle agents die met dezelfde kennis werken in één keer opgelost.

Slechts 33% van de bedrijven in fase 4 voedt lessen uit agent-fouten automatisch terug in de gedeelde kennisbasis die andere agents gebruiken. 66% breidt op basis van nieuwe productiefouten wel de eigen testset uit, zodat een vergelijkbare fout bij de volgende release wordt opgevangen. Het verschil tussen die twee cijfers is precies de valkuil: testen dat een fout niet terugkomt bij de volgende versie is waardevol, maar lost niet op dat dezelfde fout dit moment nog ergens anders in de organisatie wordt gemaakt. Een aanverwant risico, agents die elkaar actief tegenwerken in plaats van alleen dezelfde fout herhalen, beschreef Anthropic eerder dit jaar in eigen onderzoek naar multi-agent-sabotage: ook daar was de kern dat agents zonder gedeeld overzicht losse, onbewust conflicterende aannames maken.

Eén praktische voetnoot bij een gedeelde kennisbasis: zet je daar ook klantgegevens of medewerkersdossiers in, dan val je onder dezelfde AVG-regels als elk ander systeem dat die data verwerkt. Een correctielogboek over "welke regiotabel is juist" is onschuldig; een logboek met "klant X klaagde over Y" is persoonsdata en hoort met een duidelijk doel en een bewaartermijn in je eigen verwerkingsregister, niet in een losse spreadsheet die niemand beheert.

Een voorbeeld: twee agents die elkaar niet spreken

Zo ziet de kloof tussen de 33% en de 66% uit de vorige paragraaf er in de praktijk uit. Het scenario hieronder is fictief. Er is geen extern gedocumenteerd incident van precies dit mechanisme beschikbaar. Dit dramatiseert dus het verschijnsel achter die twee percentages, en is geen zelfstandig bewijs ervoor. Een facilitair dienstverlener zet twee agents in: agent A verwerkt onderhoudsmeldingen van huurders, agent B stelt de factuur op voor meerwerk buiten het servicecontract. Beide lezen voor de regiotoeslag dezelfde postcodetabel, die een paar weken eerder is aangepast: regio "Noord" kreeg er een nieuwe postcode-range bij.

Een huurder in die nieuwe Noord-range meldt een lekkage. Een medewerker corrigeert agent A's regio-indeling rechtstreeks in de chat ("nee, dit postcodegebied valt nu onder Noord, niet onder Midden") en gaat door met haar dag. Twee weken later maakt agent B voor dezelfde huurder een factuur voor het meerwerk. Een realistisch, fictief fragment van wat agent B teruggeeft:

Regiotoeslag toegepast: Midden (standaardtarief € 45,00).
Let op: dit postcodegebied lijkt recent heringedeeld; controleer bij
twijfel de actuele regiotabel voordat je verzendt.

Dit is "bijna goed": agent B herkent zelf dat er onzekerheid is en vlagt die netjes, in plaats van een bedrag te verzinnen. Maar het lost het probleem niet op. De correctie die agent A twee weken eerder kreeg, staat nergens vastgelegd buiten die ene chat, dus agent B heeft er niets aan.

Wat je hieraan verbetert voordat de factuur de deur uit mag: leg elke correctie op een vaste regel (zoals een postcode-indeling) vast op één plek die beide agents raadplegen voordat ze rekenen, in plaats van in een chatvenster dat alleen de ene agent en de ene medewerker zagen. Dat is in de kern de "knowledge spine" uit het onderzoek: geen apart product, maar het simpele principe dat een correctie die één keer is gegeven, niet een tweede keer hoeft te worden gegeven. Doe je dat niet, dan kost elke volgende afwijking in de regiotabel je weer een handmatige correctie per agent, in plaats van één keer voor allemaal.

Wat dit onderzoek niet aantoont

Drie dingen om in het achterhoofd te houden voor je dit als keiharde regel aanneemt. Eén: de onderzoekers meten een verband, geen bewezen oorzaak. Bedrijven die al goed georganiseerd zijn, presteren mogelijk op meer vlakken beter, niet alleen dankzij hun agent-aanpak. Twee: de financiële data loopt van 2022 tot 2025, dus grotendeels van vóór de periode waarin de meeste bedrijven serieus met agents begonnen. De praktijken zelf zijn in 2026 gemeten. De koppeling tussen beide is dus een momentopname, geen tijdreeks die aantoont dat betere praktijken eerst kwamen en de marge daarna steeg. Drie: alle 202 bedrijven zijn Amerikaans, groot (meer dan duizend medewerkers) en gebruikten al AI. Niets hierin zegt iets over een Nederlands mkb-bedrijf met twintig medewerkers en één AI-pilot, al is het onderliggende mechanisme (coördinatie die niet meeschaalt met mensen) niet aan bedrijfsgrootte gebonden.

Hoe je na zeven dagen weet of het werkt

Drie meetpunten, zonder extra tooling:

• Tel hoeveel correcties op agent-uitkomsten deze week alleen in een chatvenster werden gegeven, zonder dat iemand ze heeft vastgelegd op een plek die een andere agent of collega kan raadplegen. Eigen aanname, geen cijfer uit het onderzoek: bij vijf tot tien agents is één correctie per agent per week normaal onderhoud. Loop je in dezelfde week vijf keer of vaker tegen dezelfde soort fout aan, dan betaal je vijf keer voor wat een gedeeld logboek in één keer had opgelost, en is dat het signaal dat je in fase 2 zit.
• Vraag na een week aan iemand buiten het bouwteam: welke agents draaien er bij ons, en wie is eigenaar van elke agent? Kan niemand die vraag zonder te zoeken beantwoorden, dan mist de basis voor fase 3, ongeacht hoe geavanceerd de agents zelf zijn.
• Check of een correctie die deze week bij één agent is gegeven, een week later nog eens moest worden gegeven bij een andere agent op een vergelijkbare taak. Gebeurt dat, dan is dat het concrete bewijs van een ontbrekende gedeelde kennisbasis, niet een stelling uit een onderzoek.

Na zeven dagen wordt vooral de zichtbaarheid beter: je weet voor het eerst zwart-op-wit welke agents er draaien en wie erop aanspreekbaar is. Wat niet beter wordt binnen een week: de onderliggende volwassenheid. Het onderzoek zegt niets over hoe lang de stap van fase 2 naar fase 3 duurt, maar die stap is een systeem bouwen dat fouten automatisch doorgeeft in plaats van een mens die dat per geval doet, en dat is met een week meten nog niet gedaan. Zie deze week als de nulmeting, niet als de oplossing.

Doe dit deze week

1. Breng in kaart welke agents er al draaien en wie ze corrigeert

   Vraag per team of afdeling: welke AI-agent draait hier, wie beheert hem, en wie corrigeert hem als hij iets fout doet? Dertig tot zestig minuten werk voor een organisatie met minder dan tien agents. Heb je al een centraal register (bijvoorbeeld via Microsoft Agent 365, zie onze uitleg daarvan), begin daar; zonder register is een simpele lijst in een document voor nu genoeg.

2. Leg één terugkerende correctie vast op een gedeelde plek

   Kies één regel, tabel of uitzondering die je de afgelopen maand meer dan één keer handmatig hebt moeten corrigeren bij een agent. Zet die op één plek (een document, een sheet, een interne wiki) en voeg aan de systeemprompt van elke agent die deze informatie gebruikt een regel toe als: "Controleer eerst [link naar de gedeelde bron] op bekende uitzonderingen voordat je een bedrag of indeling vaststelt. Vind je geen match, meld dat expliciet in plaats van te gokken." Dat is het kleinste werkende begin van een knowledge spine: het kost een paar minuten per correctie om hem vast te leggen, en voorkomt dat je dezelfde fout de komende weken opnieuw moet corrigeren bij elke andere agent die met deze bron werkt. Doe je dit niet, dan blijft elke agent zijn eigen versie van de waarheid gebruiken, ook na de correctie die je deze week gaf.

3. Wijs één eigenaar aan per gedeelde kennisbron

   Niet per agent, per kennisbron: wie houdt de regiotabel, de productlijst of het klantenoverzicht up-to-date, en wie hoor je als die verkeerd blijkt? Zonder een naam bij die vraag, raakt elke gedeelde bron binnen een paar maanden verweesd.

Wil je met je team in kaart brengen welke agents al draaien, waar de coördinatie vastloopt en welke taak als eerste een gedeelde kennisbasis verdient? Een Agent Sprint werkt dat in korte tijd uit voor jullie eigen situatie. Speelt de vraag breder, bij hoe je als team met AI samenwerkt, dan past een AI-werksessie beter. Twijfel je waar te beginnen, plan een kort gesprek.

Bronnen

• Microsoft, The AI advantage your company can keep, gepubliceerd door Jared Spataro, Chief Marketing Officer Copilot. Zelf geopend op 29 oktober 2026. De onderzoeksopzet (Keystone en Harvard Business School, 29 interviews plus 202 bedrijven), alle percentages over de vier fasen en de financiële cijfers (operationele marge en rendement op activa per kwartiel), en het "knowledge spine"-concept.
• Microsoft, auteurspagina Jared Spataro. Zelf geopend op 29 oktober 2026. Bevestiging van functie en eerdere publicaties, gebruikt om de context en autoriteit van de bron te checken.
• Microsoft, Microsoft Agent 365. Zelf geopend op 29 oktober 2026. Beschrijving van Agent 365 als controlelaag en centraal register, gebruikt voor de verwijzing in stap 1 van "Doe dit deze week".
• Harvard Business School working paper nr. 27-038, "Organizing AI at Enterprise Scale: Agentic Operating Models and Firm Outcomes" (Sarkar, Abudurexiti, Beltinger, Daubenspeck en Iansiti, oktober 2026). Niet rechtstreeks te openen op hbs.edu; titel, auteurs, papernummer en steekproef (29 startinterviews, 202 Amerikaanse bedrijven, vier fasen) zijn daarom op twee onafhankelijke manieren gecontroleerd: via de Microsoft-publicatie hierboven, en via een losse zoekopdracht die rechtstreeks naar de hbs.edu-vermelding van deze paper verwijst, zonder dat Microsoft daar in voorkomt. Geen van beide is de paper zelf; lees de cijfers in deze post dus als "door Microsoft gerapporteerd en in opzet onafhankelijk bevestigd", niet als zelf in de paper gecontroleerd.
• Project Impact, AI-agent. De basisdefinitie van een AI-agent.
• Project Impact, Microsoft Agent 365: wat de controlelaag voor AI-agents wel en niet oplost. De eerdere analyse van het registreren en beheren van agents binnen Microsoft 365.
• Project Impact, Anthropic-onderzoek: Claude-agents saboteerden elkaar. Het verwante risico van agents die zonder gedeeld overzicht conflicterende aannames maken.

Veelgestelde vragen

• Waarom lukt het opschalen van AI-agents vaak niet?

  Omdat bedrijven meer agents bouwen zonder de controle anders te organiseren. Een team dat elke agent-uitkomst handmatig checkt, werkt bij twee agents en loopt vast bij tien, want de controle-uren groeien net zo snel als het aantal agents. Onderzoek van Microsoft en Harvard Business School onder 202 bedrijven laat zien dat maar 3% dit al oplost met een systeem dat fouten en context automatisch deelt in plaats van met meer mensen te controleren.

• Wat is een knowledge spine bij AI-agents?

  Een knowledge spine is een gedeeld systeem dat vastlegt wat agents al geleerd hebben, inclusief correcties en fouten, zodat een andere agent dezelfde fout niet opnieuw maakt. Het is geen apart product dat je koopt, maar het principe dat een correctie die één keer is gegeven, niet een tweede keer hoeft te worden gegeven. Bedrijven in de meest volwassen fase hebben dit bij 76% al als gedeelde contextlaag ingericht.

• Wat zijn de belangrijkste best practices om AI-agents op te schalen?

  Vier praktijken maken het verschil, blijkt uit het onderzoek: een actueel register van welke agents er draaien, testen die automatisch worden getriggerd door fouten uit productie, het hergebruiken van eerdere foutpatronen in die testen, en het kiezen van het juiste model per taak in plaats van altijd hetzelfde model. Slechts 3% van de onderzochte bedrijven (6 van 202) had in 2026 alle vier op orde.

• Is AI-agent governance hetzelfde als een knowledge spine?

  Nee. AI-agent governance gaat over wie welke agent mag bouwen, welke rechten hij heeft en wie erop toeziet, zoals een register van agents en hun eigenaren. Een knowledge spine gaat specifiek over het delen van fouten en context tussen agents, zodat ze van elkaars correcties leren. Governance zonder een knowledge spine geeft overzicht, maar lost niet op dat elke agent zijn eigen fouten blijft herhalen.

• Hoeveel bedrijven schalen AI-agents al goed op?

  In het onderzoek onder 202 Amerikaanse bedrijven met meer dan duizend medewerkers had maar 3%, zes bedrijven, alle vier gemeten praktijken op orde om agents betrouwbaar op te schalen. Het bovenste kwartiel op deze praktijken draaide over 2022-2025 gemiddeld 5,4 procentpunt hogere operationele marge dan het onderste kwartiel.