In innovatiewerk komt altijd dezelfde vraag terug, en meestal pas als er al iets draait: wie mag dit bouwen. Niet wie kan het, want dat blijkt vaak mee te vallen zodra iemand het gereedschap in handen krijgt. Wie mag het. Wie kijkt ernaar. Wie draait het terug als het misgaat op een dinsdagavond.
Anthropic publiceerde deze week een klantverhaal over ABC Legal, een Amerikaans bedrijf dat juridische documenten bezorgt. De casus zelf is niet het interessante deel: een groot bedrijf zet AI in en het gaat goed, dat verhaal ken je. Wat er wel in staat zijn vier concrete afspraken waarmee ze het bouwen buiten de IT-afdeling hebben opengezet zonder de boel te laten verwilderen. Die afspraken zijn los te koppelen van het product waar ze in staan, en dat is precies wat ik eruit wilde halen.
Wat er gebeurde, kort
CTO Brandon Fuller rolde Claude Enterprise uit naar 1.100 medewerkers. Mensen begonnen ongevraagd hun eigen werk te automatiseren, wat prettig is tot je je afvraagt waar die automatiseringen eigenlijk staan. Het antwoord was: op laptops, als geplande taken op individuele bureaubladen. Iedere bouwer had zijn eigen hoekje en niemand had overzicht.
Fuller verplaatste alles naar Claude Managed Agents, het beheerde platform waarop agents in de cloud draaien in plaats van op iemands machine. Daarna nam hij de stuurgroep van vijftien mensen uit finance, marketing, operations en development, van wie niemand softwareontwikkelaar was, en liet ze de repository klonen en zelf een agent bouwen met Claude Code.
Binnen een week had alle vijftien iets werkends. Die vijftien trainden hun eigen teams. Binnen een maand draaiden er ruim vijftig agents, elk met een naam, een eigenaar en één taak.
De zin die me het langst bijbleef gaat niet over AI:
“Ik moest ze uitleggen wat een PR was. Een hoop van hen dacht dat het rennen betekende, zo hard als je kunt.”
De drempel zat in clonen, branchen, een pull request openen en op iemand anders wachten. Niet in het model.
De vier patronen
| Patroon | Wat het regelt | Wat het kost |
|---|---|---|
| Agent als code | Alles wijzigt via een reviewbare wijziging, niks in het geheim | Iedereen moet met git leren werken |
| Mens in de lus als startpositie | Nieuwe agent adviseert, mens beslist | Trager begin, iemand moet echt kijken |
| De PR als stuurvlak | Goedkeuring, commentaar per regel en een onveranderlijk spoor zijn gratis | Alleen bruikbaar als het besluit in tekst te vangen is |
| Oogsten en bijstellen | Feedback wordt een voorstel tot wijziging, geen hertraining | Twee extra agents per agent die je zo behandelt |
Een agent is tekst, dus hoort hij in een repository
Fuller laat elke agent als code definiëren. Zijn redenering: een agent is gestructureerde tekst, een prompt plus configuratie, en alles wat tekst is kan in een repository staan waar het hele bedrijf het kan zien, beoordelen en verbeteren. Prompt, toolijst, schema, credentials en geheugen staan in configuratiebestanden naast de gewone software. Er verandert niets aan een agent behalve via een pull request.
Daarmee wordt het bouwen van een agent zichtbaar voor collega’s die er zelf niet aan werken, en dat is meer dan versiebeheer alleen. Een prompt op iemands laptop is een privé-afspraak met een model. Dezelfde prompt in een repository is een document waar iemand commentaar op kan geven.
Hun volgende stap gaat dezelfde kant op: ze zoeken nu naar meer dingen die “als code” kunnen bestaan. Notificatiesjablonen, routeringsregels, verdeellogica. Alles wat in een repository komt, kan een agent lezen en er een verbetering op voorstellen.
Elke agent begint met adviseren
Geen enkele agent begint zelfstandig. Elke nieuwe agent post eerst een aanbeveling voor een mens. Pas als hij aantoonbaar consequent hetzelfde besluit neemt als de mens, mag hij alleen handelen. Fuller: “Elke agent verdient vertrouwen voordat hij alleen handelt. Hij begint daar niet.”
Dit is een promotiepad en geen aanknop, en dat is het verschil met hoe de meeste organisaties het doen. Meestal is de vraag “mag deze agent zelfstandig handelen” een ja of nee die vooraf wordt beantwoord, in een risicoanalyse, door iemand die de agent nooit heeft zien werken. Hier is het antwoord een uitkomst van meekijken.
Waar ik in dit patroon een gat zie, staat verderop bij de kanttekening.
Maak van het besluit een pull request
Dit is het patroon dat ik zelf ga gebruiken. Fuller zegt: “Wil je een agent betrokken hebben bij een besluit, laat dat besluit er dan uitzien als een pull request.”
Zodra een besluit die vorm heeft, krijg je commentaar per regel, een goedkeuringsprocedure en een spoor dat achteraf niet meer te wijzigen is, zonder dat je daar iets voor hoeft te bouwen. Het komt gratis mee met versiebeheer. En het werkt voor mensen en agents tegelijk, want ze schrijven allebei tekst.
De beperking zit in dezelfde zin: het besluit moet in tekst te vangen zijn. Een afweging die op tafel wordt gemaakt tussen vier mensen die elkaars gezicht zien, wordt geen PR zonder dat er iets verdwijnt.
Oogsten, bijstellen, herhalen
Voor de agents waarvan de uitkomst wordt beoordeeld, gebruiken ze drie rollen die dezelfde werkruimte en dezelfde credentials delen maar op verschillende momenten draaien:
- De initiële agent doet het werk zodra er een klus binnenkomt en legt van elke handeling een spoor vast.
- De harvester draait elk uur of elke dag en verzamelt de reacties van mensen uit Slack, waar ze binnenkomen als antwoorden in een draadje en als emoji. Elke reactie wordt een gelabeld datapunt.
- De tuner draait wekelijks, kijkt naar alles tegelijk en stelt een wijziging voor aan de prompt of de configuratie. Niet aan de gewichten van het model. Hij schrijft alleen een concept. Een mens beoordeelt en merget de pull request.
Er wordt hier niets hertraind, er is geen dataset en er is geen apart proces. De feedback komt binnen via de plek waar mensen toch al reageren en verlaat het systeem via de plek waar wijzigingen toch al langskomen.
En ze zijn eerlijk over de reikwijdte: het merendeel van de vloot krijgt dit niet. De meeste agents zijn eenmansklussen waarvan niemand de uitkomst beoordeelt, en die werken alleen.
De cijfers, met de meetopzet erbij
Peildatum juli 2026, gepubliceerd 17 augustus 2026, door de leverancier van het product.
- Ruim 50 agents in productie. Elk met een naam, een eigenaar en één taak.
- Ongeveer 310 medewerkers gebruiken Claude dagelijks. Op 1.100 medewerkers is dat 28 procent. Het bedrijfsbrede gebruik dat het openingsverhaal suggereert, is dus ruim een kwart van de organisatie.
- Tot ongeveer 50 procent lagere kosten voor de menselijke taken die sommige agents overnemen. Vier voorbehouden in één zin: “tot”, “ongeveer”, “sommige”, en het gaat om de kosten van de taak, niet van de afdeling. Er staat expliciet bij dat dit vóór zware optimalisatie is gemeten.
- De uitgaven stegen in het voorjaar en daalden in juli terwijl het gebruik doorgroeide. Geen bedragen, geen grafiek.
Dat laatste punt is het cijfer dat me het meest zegt en het minst is uitgewerkt. Dat de kosten dalen terwijl het gebruik stijgt is precies de claim waar je een tabel bij wilt zien, en die is er niet.
Er staat ook geen enkel incident in. Geen agent die iets fout deed, geen rollback die nodig was, geen voorbeeld van een pull request die is afgekeurd. In een stuk dat gaat over vertrouwen verdienen, is de afwezigheid van één geval waarin dat vertrouwen werd teruggenomen de opvallendste lege plek.
Wat ik hiervan meeneem
Ik ontwerp werkvormen waarin mensen zonder programmeerachtergrond zelf iets bouwen. Wat in de zaal steeds gebeurt: het bouwen lukt, en daarna staat er iets waarvan niemand weet waar het hoort. Dat is exact het probleem waar ABC Legal mee begon, alleen dan op de schaal van één middag in plaats van 1.100 mensen.
Drie dingen die ik overneem.
De vraag verplaatsen van “mag jij bouwen” naar “waar komt het te staan”. Toestemming vooraf regelen is traag en het regelt het verkeerde. Als de afspraak is dat alles wat je bouwt in een gedeelde repository terechtkomt, is het bouwen zelf vrij en is het zichtbaar zijn de prijs.
De git-drempel serieus nemen als de echte drempel. Ik ben dat zelf steeds vergeten. In mijn werkvormen zit uitleg over prompten en niets over versiebeheer, terwijl de deelnemers na afloop precies daar vastlopen. Het model uitleggen kost tien minuten. Uitleggen waarom je je werk voorlegt aan iemand anders kost meer, en dat is geen technische uitleg.
Beginnen met adviseren, ook als het traag voelt. In een omgeving waar besluiten over mensen worden genomen, is een agent die adviseert en een mens die beslist niet de tussenstap. Dat is meestal het eindstation, en dat mag ook zo blijven.
Wat ik niet overneem is de aanname eronder: dat een agent zichzelf uit de lus kan verdienen. In publieke dienstverlening werkt dat anders, en dat is de eerste kanttekening.
De kanttekening
De standaard verschuift van “een mens besluit” naar “een mens keurde ooit goed”. Het criterium voor zelfstandigheid is dat de agent consequent hetzelfde besluit neemt als de mens. Dat is overeenstemming, geen correctheid. Nam de mens systematisch een scheve beslissing, dan is de agent die dat trouw kopieert volgens dit criterium klaar voor zelfstandigheid, en vanaf dat moment kijkt niemand meer mee. Bij een documentbezorger is dat een bedrijfsrisico. Bij een besluit over iemands uitkering is het iets anders. De vraag “waaraan meten we of dit goed gaat” is daarmee belangrijker dan de vraag “mag hij zelfstandig”, en die eerste vraag beantwoordt het stuk niet.
De verantwoordelijkheid landt bij degene die op merge klikt. Dat is de bedoeling en het is netter dan wat ervoor was, waar niemand het wist. Maar het is ook een marketingmedewerker die een wijziging goedkeurt in een agent die klantgegevens aanraakt. Een pull request levert een spoor op, geen deskundigheid. Het risico is dat alles er beoordeeld uitziet omdat elke wijziging langs een goedkeuring is gegaan, terwijl de goedkeurder de gevolgen niet kon overzien. Wie het proces overneemt, moet dus ook regelen wie waarvoor mag tekenen, en dat staat niet in de vier patronen.
Wat wegstroomt is de kennis van het werk zelf, en de uitweg raakt tegelijk dicht. De accountmanager die elke week handmatig dossiers ophaalde, doet dat niet meer. Dat is winst en het is ook het moment waarop niemand meer merkt dat het rapport al drie weken de verkeerde selectie geeft. Daar komt de tweede beweging bovenop: de harness, de modellen, de console, de facturatie en het geheugen komen in dit ontwerp van één leverancier. De agents zelf staan gelukkig als tekst in je eigen repository, wat betekent dat je prompts en configuratie meeneemt als je vertrekt. Maar de runtime die ze uitvoert niet, en de agents die twee jaar draaien zonder dat iemand nog weet hoe het handmatig ging ook niet. Voor een overheidsorganisatie is dat geen technische afweging maar een vraag over soevereiniteit, en die stel je vooraf of niet meer.
Wat ik zelf doe: het PR-patroon overnemen, de promotie naar zelfstandigheid niet, en bij elke agent opschrijven hoe het werk zonder die agent ging. Dat laatste kost een half uur en het is het enige wat een uitweg openhoudt.
Veelgestelde vragen
Heb ik Managed Agents nodig om deze patronen te gebruiken?
Nee. Alle vier zijn productonafhankelijk. Agents als tekst in een repository, een promotiepad van adviseren naar handelen, besluiten in de vorm van een pull request en feedback die via diezelfde pull request terugkomt: daar heb je git voor nodig en een plek waar mensen reageren. Wat het platform toevoegt is de uitvoering zonder eigen infrastructuur, plus versiebeheer per push, sessies die je kunt terugkijken, facturatie per werkruimte en het inplannen van terugkerende runs.
Wat is het verschil met de agent-vloot van Spotify?
Wie er bouwt. Bij Spotify draaien de agents op de codebase en zijn de bouwers en beoordelaars engineers; daar draait alles om verificatie, omdat een pull request automatisch merget zonder dat iemand hem ziet. Bij ABC Legal zijn de bouwers mensen uit finance en marketing en draait alles om zichtbaarheid, omdat de beoordelaar juist wél moet kijken. Beide vlooten gebruiken de pull request als stuurvlak, om precies tegengestelde redenen.
Werkt “de PR als stuurvlak” ook voor besluiten die geen code zijn?
Alleen als het besluit in tekst te vangen is. Een adviesnota, een routeringsregel, een sjabloon of een configuratie: prima. Een afweging tussen vier mensen in een kamer wordt geen pull request zonder dat er iets verdwijnt. De vorm dwingt af dat het besluit uit een voorstel plus een goedkeuring bestaat, en niet elk besluit heeft die vorm.
Hoeveel van het bedrijf gebruikte dit nou echt?
Ongeveer 310 van de 1.100 medewerkers, dus 28 procent, gemeten in juli 2026. De titel van het bronartikel zegt “every employee into a builder”; het aantal mensen dat daadwerkelijk een agent bouwde, is de vijftien uit de stuurgroep plus de collega’s die zij trainden, en dat aantal staat er niet.
Bronnen
- Anthropic, How ABC Legal turned every employee into a builder with Claude Managed Agents, 17 augustus 2026
- Claude Platform Docs, Claude Managed Agents overview, geraadpleegd 19 augustus 2026
- Eigen eerder werk: Een chatbot antwoordt. Een agent doet het gewoon., 11 juli 2026
- Eigen eerder werk: Hoe Spotify Claude loslaat op 20 miljoen regels code, 5 juli 2026
- Eigen eerder werk: Verificatie is niet je unit-test, 25 juni 2026
Gecontroleerd op 19 augustus 2026 tegen het klantverhaal en de productdocumentatie. Alle cijfers in dit stuk komen uit het bronartikel van Anthropic, dat gaat over hun eigen product; er is geen onafhankelijke meting en geen tegenspraak van een andere partij beschikbaar. Ik heb ABC Legal niet gesproken en de agents niet gezien. De percentages heb ik zelf uitgerekend uit de genoemde absolute getallen (310 van 1.100). Het kostencijfer van ongeveer 50 procent is in het origineel omgeven door vier voorbehouden en betreft de kosten van de taken die agents overnemen, niet de kosten van de organisatie. De vier patronen komen letterlijk uit de best-practicessectie van het bronartikel; de toepassing op publieke dienstverlening en de kanttekeningen zijn van mij en staan niet in de bron.