Wat agentframeworks werkelijk besturen, en wat ze aan jou overlaten

Veldnotities agentplatform, drie van acht. Notities een en twee betoogden dat de trust root van jou moet zijn en dat “connected” niet “soeverein” is. Deze gaat over de frameworks zelf, want de eerste vraag die elk team stelt is “welke”, en dat is de verkeerde vraag zolang je niet weet wat “welke” voor je beslist.

De as

Ik heb meer dan honderd agentframeworks, orchestrators, gateways en runtimes beoordeeld voor een governed platform voor de Nederlandse lokale overheid. De meeste vergelijkingen rangschikken ze op developer experience, omvang van het ecosysteem of benchmarkscores. Voor een gereguleerde koper zijn die secundair. De vraag die ertoe doet is smaller:

Van de beslissingen waar een toezichthouder, een auditor of een inwoner uiteindelijk naar zal vragen, welke neemt het framework, en welke laat het aan jou over?

Ik gebruik vijf van zulke beslissingen, dezelfde vijf die de governance-ruggengraat uit notitie een definiëren:

1. Identiteit en delegatie. Wie is deze agent, namens wie handelt hij, en wat mag hij dat de persoon zelf niet mag?
2. Beleidshandhaving. Waar draaien de regels, en kan het model zich eromheen praten?
3. Goedkeuringsbinding. Als een mens moet goedkeuren, wat keurt die dan precies goed, en kan het plan daarna nog veranderen?
4. Toolmediatie. Wie beslist of een tool call wordt uitgevoerd, en is die beslissing standaard weigeren?
5. Bewijs. Welk record blijft over, wie heeft het geschreven, en kan het worden bewerkt?

Hier is mijn lezing van zes frameworks op die as. De lezing is actueel tot medio 2026, gebaseerd op hun gepubliceerde documentatie en mijn eigen praktijkwerk met de eerste vier. Zie het als een kaart, niet als een oordeel; deze projecten veranderen maandelijks.

Microsoft Agent Framework

De samensmelting van de orkestratiepatronen van AutoGen en het enterprise-loodgieterswerk van Semantic Kernel, algemeen beschikbaar sinds april 2026, met beide voorgangers nu in onderhoudsmodus. Ben je een .NET-huis, dan is dit de standaardkeuze.

Wat het bestuurt: veel van het loodgieterswerk. Filters op elke model- en tool call, volwaardige telemetrie, native MCP en A2A, en, via de gehoste optie, per sessie gesandboxte uitvoering met een automatisch uitgegeven directory-identiteit per agent en geen opgeslagen secrets. Dat laatste is echte governance: een agent met een eigen identiteit, afgebakend per tenant, is een voorwaarde voor al het andere.

Wat het aan jou overlaat: de identiteit is het sterkst wanneer Microsoft de hosting doet. Draai je het zelf, dan houd je de filters en de protocollen, maar bouw je het identiteitsmodel, de goedkeuringsbinding en de bewijsopslag zelf. Filters zijn bovendien hooks binnen de runtime; ze worden afgedwongen door de runtime, en dat is precies wat volgens notitie een niet je trust root mag zijn. Ik heb het als runtime voor mijn platform gekozen en de beleidspoort achter een interface geplaatst die het framework niet bezit. Dat is geen kritiek. Het is de juiste taakverdeling, en de eigen interfaces van het framework maken het mogelijk.

LangGraph

De low-level graph runtime onder de LangChain-familie, versie 1.0 sinds oktober 2025. State als getypeerd object, nodes en edges, checkpoints bij elke stap.

Wat het bestuurt: duurzaamheid en onderbreking. Door de checkpointer kan een run pauzeren voor een mens, geïnspecteerd worden, hervatten of vanaf elk punt opnieuw afgespeeld worden. Dat is de beste primitieve voor goedkeuringsbinding in het open-sourceveld, omdat de goedkeuring aan een specifieke checkpoint gehangen kan worden in plaats van aan “het gesprek”.

Wat het aan jou overlaat: alles over wát de mens goedkeurt. De graph stopt en wacht; hij weet niet of de planrevisie die hij hervat, dezelfde is die werd goedgekeurd. Beleid is code in nodes, en wordt dus afgedwongen waar jij het neerzet en nergens anders. Identiteit is wat je applicatie meegeeft. Bewijs is de checkpoint store, een database die je zelf bezit, wat goed is, maar het is een opslag van state, geen tamper-evident record van beslissingen. Die laag schrijf je zelf.

OpenAI Agents SDK

Klein, uitgesproken, en de snelste weg naar een werkend multi-agentsysteem op OpenAI-modellen. Agents, handoffs, guardrails, sessies.

Wat het bestuurt: input- en outputguardrails die parallel aan de agent draaien, en handoffs als volwaardig mechanisme, wat delegatie in elk geval expliciet maakt in plaats van impliciet.

Wat het aan jou overlaat: de guardrails worden geëvalueerd door de SDK, in-process, meestal via een extra modelaanroep. Dat is een afspraak, geen control, in de zin van notitie een. Structureler: het runtimecontract van de SDK is strak om de eigen gehoste primitieven van de provider heen gebouwd: threads, files, stores, tools. Elk daarvan is een providerafhankelijkheid die je moet kwalificeren, vastpinnen en vastleggen als route, en aan de bewijskant helpt de SDK je niet. Voor een frontier-connected use case is het een prima motor. De governor kan het niet zijn.

Claude Agent SDK

De programmeerbare vorm van Claude Code: dezelfde agentloop, hetzelfde toolsysteem en hetzelfde permissiemodel, aangeboden als library.

Wat het bestuurt: toolpermissies, en dat doet het goed. Fijnmazige allow- en deny-regels per tool, hooks vóór en na elke tool call, gesandboxte uitvoering en een zichtbare audit van wat de agent deed. Van de zes is dit degene die “mag deze tool draaien” behandelt als een volwaardige vraag in plaats van als een callback.

Wat het aan jou overlaat: de harness is gebundeld en gebonden aan de provider. De permissiebeslissingen worden afgedwongen door de harness, dus dezelfde trust-root-kanttekening geldt, en de identiteit in het spel is de API-sleutel, niet een principal die je directory kent. Ik gebruik het dagelijks, onder mijn eigen geschreven regels, als codeeragent binnen een pipeline die de merge- en productiesleutels elders bewaart. Dat is de juiste plek: een uitstekende governed werker, niet de governor.

Google ADK

Code-first, meertalig, en sinds ADK 2.0 in mei 2026 een deterministische workflow-runtime met human-in-the-loop checkpoints, ingebouwde evaluatie en native telemetrie-export.

Wat het bestuurt: evaluatie. ADK levert trajectory- en response-evaluatie als onderdeel van de toolkit, en dat is zeldzamer dan het zou moeten zijn. Als je, zoals ik, vindt dat niets in productie verandert zonder de evaluatieset te doorstaan, dan geeft ADK je die discipline standaard. De workflow-runtime geeft je ook dezelfde op checkpoints gebaseerde goedkeuringsprimitieve als LangGraph.

Wat het aan jou overlaat: identiteit, beleid buiten de prompt, en bewijs, met dezelfde asymmetrie tussen zelf hosten en laten hosten als bij het framework van Microsoft. De meest bestuurde configuratie is die op Google’s eigen agent engine. Elders bouw je de ruggengraat zelf.

CrewAI

Rolgebaseerde crews met doelen en achtergrondverhalen, plus event-driven flows. Populair, snel te prototypen, wekelijkse releases.

Wat het bestuurt: de taakverdeling tussen agents. De teammetafoor is leesbaar en maakt de bedoeling van een multi-agentsysteem begrijpelijk voor niet-engineers, wat in een workshop echte waarde heeft.

Wat het aan jou overlaat: alle vijf beslissingen. Er is geen identiteitsmodel, geen beleidslaag buiten de prompt, geen goedkeuringsbinding, tooltoegang is zo breed als de tools die je overhandigt, en bewijs is logging. Voor het beoogde gebruik is dat geen gebrek. Het is wel een reden om “we hebben een crew” niet te verwarren met “we hebben een governed agent”.

Het patroon

Leg de zes naast elkaar en er verschijnt één vorm. De frameworks besturen de delen van het probleem die binnen de run leven: orkestratie, onderbreking, hooks per aanroep, toolpermissies. De delen die rond de run leven, wie de agent is, welke regels hem binden ongeacht de runtime, wat precies werd goedgekeurd en welk record overblijft, worden in elk geval aan jou overgelaten, en zijn alleen het sterkst wanneer je de hosting van de leverancier als trust root accepteert.

Dat is het build-versus-buy-antwoord in één zin: koop de runtime, bouw de ruggengraat. Elk van de eerste vijf is een redelijke runtime voor de juiste stack. Geen van alle is een governor, en geen van alle beweert dat te zijn, zodra je de documentatie op deze as leest in plaats van op de featurelijst.

De wet van Conway heeft een uitbreiding voor agentplatforms: een framework bestuurt precies de beslissingen die de leverancier zelf moest nemen, en laat jou de beslissingen die hij aan iemand anders kon factureren.

Wat ik niet kan bewijzen

Vier hiervan heb ik in de praktijk gedraaid; twee ken ik uit documentatie en uit de ervaringen van anderen in mijn onderzoeksbasis. Versies gaan snel, en vooral de gehoste governancefuncties van de twee grote leveranciers ontwikkelen zich per kwartaal. Een deel van wat ik vandaag onder “laat het aan jou over” plaats, is volgend jaar een productfunctie. De as blijft staan; de invullingen niet.

Wat je hiermee doet

Schrijf vóór je volgende frameworkbeslissing de vijf vragen hierboven op een whiteboard. Beantwoord voor elke kandidaat elke rij met “framework”, “hosting van de leverancier” of “wij”. Welk framework je kiest, doet er minder toe dan hoeveel rijen “wij” zeggen en of iemand het budget heeft gekregen om die te bouwen.

Volgende notitie: MCP-gateways, en waar beleid, identiteit en egress werkelijk worden afgedwongen wanneer elke tool een server is.

Nobody expects the governance questions. Hun belangrijkste wapen is identiteit. Identiteit en bewijs. Hun twee belangrijkste wapens zijn identiteit, bewijs en approval binding. Tot hun arsenaal behoren beleid en toolbemiddeling. Ik kom nog een keer binnen.

Verwijzingen

De knipogen en citaten in dit stuk, met hun herkomst:

• Melvin Conway, “How Do Committees Invent?” (1968): organisations design systems that mirror their communication structures.
• Monty Python’s Flying Circus (BBC, 1970), the Spanish Inquisition sketch: “Nobody expects the Spanish Inquisition” and the escalating list of chief weapons.