LangGraph vs CrewAI vs Workers: een agent-stack kiezen

02:14, dinsdag. Een senior associate bij een juridisch onderzoekskantoor van 19 mensen vlak bij de Meir in Antwerpen uploadt een SPA van 47 pagina's. De contract-samenvattingsagent geeft een nette executive summary terug, drie risico-flags en een lijst met kruisverwijzingen. Daarna geeft hij dezelfde drie risico-flags. Daarna stopt hij met reageren.

De on-call engineer (wij dus) opent het dashboard. De graph laat een node zien die slaagde maar geen output gaf. Een retry loop vrat 38.000 tokens in 90 seconden. Niemand weet welke versie van de clause-classification prompt draaide, want die prompt staat in een Python-decorator drie bestanden diep, en de partner die er vorige week aan sleutelde deed dat via een Notion-doc dat een engineer daarna overtypte.

Dit is de post die we zes maanden eerder hadden willen lezen, voordat we een orchestration-laag kozen. We bouwden dezelfde multi-step contract-samenvattingsagent drie keer: één keer op LangGraph, één keer op CrewAI, één keer als zelfgebouwde state machine op Cloudflare Workers. Dezelfde inputs, hetzelfde Claude-model erachter, dezelfde evaluatieset van 120 Nederlandse en Engelse contracten. We scoorden elk op drie dingen die op schaal telden: kun je het om 02:00 debuggen, wat kost één run aan tokens, en wie is eigenaar van de prompt-diff.

De pipeline die we orkestreerden

De agent heeft vijf stappen. Metadata extraheren (partijen, data, jurisdictie). Het contract opsplitsen in clausules. Elke clausule classificeren tegen een taxonomie van 34 categorieën die het kantoor in drie jaar heeft opgebouwd. Per clausule een samenvatting maken. Die optellen tot een executive summary plus een risicoregister. Elke stap is een aparte LLM-call. Sommige stappen waaieren uit (clausule-classificatie draait in parallelle batches van 8). De hele pipeline duurt end to end 90 tot 180 seconden en kost ergens tussen de EUR 0,40 en EUR 1,20 per contract, afhankelijk van de lengte.

De evaluatieset van 120 contracten is met de hand gelabeld door twee partners over vier weekenden. Een regressie daarop kost dus meer dan alleen engineering-tijd. Die set als dragend behandelen veranderde elke architectuurbeslissing die volgde. Konden we een wijziging niet binnen één nightly cycle daartegen meten, dan ging die wijziging niet live.

Deze vorm, kleine graph plus fan-out plus retries plus deelfouten, is precies wat elk agent-framework claimt goed te doen. Dus we lieten ze het allemaal bewijzen.

Debugbaarheid om 02:00

Frameworks sneuvelen in productie om 02:00. Dan telt het on-call-verhaal. We beoordeelden elke optie op wat er nodig was om één vraag te beantwoorden: welke prompt draaide, met welke inputs, en wat kwam er terug?

LangGraph levert hooks mee voor LangSmith, en dat is de makkelijkste route naar traces. Met LangSmith aan logt elke node inputs, outputs en de resolved prompt. Zonder dat zit je Python stack traces te lezen en gok je welke edge in de graph is gevuurd. De 02:00-ervaring is goed als je voor LangSmith betaalt en goede engineers de graph hebben gebouwd. Hij verslechtert snel als de graph conditional edges met lambdas bevat, want de graph viewer kan je niet laten zien welke branch is genomen zonder de run opnieuw af te spelen.

CrewAI heeft uitgesproken meningen over agents en tasks, een stuk minder over observability. De default logs zijn spraakzaam en goed leesbaar, wat fijn voelt totdat je ze om 02:00 probeert te grep'en en merkt dat de overdrachten tussen agents door elkaar staan op stdout. Je kunt OpenTelemetry erbij plakken, maar die integratie wordt door de community onderhouden en de spans zijn grof. Het mentale model (agents met rollen die met elkaar praten) zorgt dat de logs lezen als een script in plaats van een trace. Charmant in een demo, pijnlijk tijdens een incident.

Zelfgebouwd op Cloudflare Workers betekent dat je de state machine zelf hebt geschreven, waarschijnlijk met Durable Objects of Cloudflare Workflows die de state tussen stappen vasthouden. Het framework geeft je niets. Maar je geeft jezelf ook niets wat je niet wilt. Wij logden elke state-overgang als een structured event in één Workers Analytics Engine-dataset, met de resolved prompt-hash, het aantal input-tokens en de output. Om 02:00 vertelt één SQL-query ons welke prompt-versie draaide. De adder is dat je dit op dag één moest bouwen. Heb je dat niet gedaan, dan zit je slechter dan bij een van beide frameworks.

Token-verbruik per run

We draaiden dezelfde evaluatieset van 120 contracten door alle drie de orchestrators, met hetzelfde Claude-model en dezelfde prompts (modulo de scaffolding die het framework injecteert, en dat is precies waarom we dit meten). Mediane tokens per contract:

LangGraph         38,400 in   6,200 out
CrewAI            51,700 in   9,800 out
Hand-rolled       29,100 in   5,900 out

De overhead van LangGraph komt uit de system messages die het injecteert om structured outputs af te dwingen, plus iets opgeblazen tool definitions. Te verkroppen. De overhead van CrewAI is het gepraat tussen agents. Als twee agents samenwerken, wisselen ze context uit, en die context kost tokens. Op een schone run met vijf stappen was CrewAI 32 procent duurder dan de zelfgebouwde versie. Op een run met één retry was het 58 procent meer. Bij 200 contracten per dag is dat het verschil tussen EUR 90 en EUR 145 per dag aan inference. Vermenigvuldig met 220 werkdagen per jaar.

De zelfgebouwde versie is het goedkoopst omdat er niets wordt geïnjecteerd dat je niet hebt gevraagd. Het is ook de versie die het meest kans heeft om een guardrail die je vergat toe te voegen stilletjes over te slaan. De keerzijde van dezelfde medaille.

Eigenaarschap van de prompt-diff

Dit is de vraag die elke vergelijkingspost overslaat, en de vraag die het project heeft beslecht.

De senior partner van het advocatenkantoor schrijft geen Python. Wel heeft ze sterke meningen over hoe een force-majeure-clausule samengevat hoort te worden, en daar heeft ze gelijk in. De vraag is of ze die prompt kan aanpassen zonder een ticket aan te maken.

Bij LangGraph staan prompts meestal als Python-string-constanten of PromptTemplate-objecten in node-functies. Ze refactoren naar een config-bestand kan, en we hebben het gedaan, maar dat is werk. Tot je dat werk doet, is elke prompt-wijziging een Python-PR.

Bij CrewAI zijn agent-backstories en task-descriptions argumenten van Agent- en Task-constructors. Zelfde verhaal. Je kunt ze naar YAML externaliseren (nieuwere CrewAI-versies stimuleren dat), maar het rondje partner past YAML aan, engineer reviewt PR, CI draait, deploy houdt elke wijziging nog steeds vast aan engineering.

Bij de zelfgebouwde Workers-versie stopten we elke prompt in een geversioneerde tabel in een D1-database met een kleine admin-UI. De partner past een prompt aan, drukt op opslaan, de volgende contract-run gebruikt de nieuwe versie. Elke run registreert de hash van de prompt-versie. Regresseert de nieuwe prompt op de evaluatieset van 120 contracten (die nightly draait), dan piept het systeem ons op en draait het terug. De partner is eigenaar van de diff. Engineering is eigenaar van de rails.

De aansprakelijkheidsvraag

Voor een juridisch onderzoekskantoor zijn AI-hallucinaties geen technische curiositeit. Het is blootstelling. Verzint de contract-samenvattingsagent een clausule die niet bestaat, en leunt een partner in een onderhandeling op die samenvatting, dan staat het kantoor er voor. Niet de framework-leverancier. Beroepsaansprakelijkheidsverzekeraars beginnen hier schriftelijk naar te vragen.

Het Europese gesprek over aansprakelijkheid bij generatieve AI komt op hetzelfde punt uit: de deployer is verantwoordelijk. De EU AI Act behandelt systemen die juridische beslissingen materieel beïnvloeden standaard als hoog risico, met de bijbehorende verplichtingen rond logging, menselijk toezicht en post-market monitoring. Dat is geen probleem voor 2028. De dragende artikelen bijten eerder, en de general counsel van je klant leest ze nu al.

Dat duwde twee wijzigingen door in onze architectuur, los van welke orchestrator we kozen. Eén: elke clausule-samenvatting moet de source span citeren (start- en eindkarakter-offsets), en de UI rendert de samenvatting naast de originele tekst. Ontbreekt de source span, dan wordt de samenvatting onderdrukt. Twee: de executive summary wordt alleen gegenereerd uit clausule-samenvattingen, nooit uit het ruwe contract. Het model krijgt het contract nooit te onthouden. Het mag alleen geverifieerde stukken samenstellen.

Je kunt dit bouwen in elk van de drie frameworks. Het is makkelijker af te dwingen in de zelfgebouwde versie omdat je de dataflow tussen stappen in de hand hebt. In LangGraph moet je de validator als een node schrijven. In CrewAI moet je een agent leren om het af te dwingen, en dat is een model vragen om een model te politioneren.

Wat we hebben uitgerold

De zelfgebouwde state machine op Cloudflare Workers. Niet omdat het in de mode is, en niet omdat we een hekel hebben aan frameworks. De doorslaggevende factoren, op volgorde:

1. De senior partner is eigenaar van de prompt-diff. Dat alleen al was de extra bouwkosten waard.
2. Eén structured log-regel per state-overgang geeft ons 02:00-traces zonder dat we een aparte observability-vendor hoeven te betalen.
3. Het token-verbruik ligt 24 procent lager dan LangGraph en 43 procent lager dan CrewAI op dezelfde evaluatieset.
4. De volledige orchestrator (state machine, retry policy, prompt-registry, eval-runner) is ongeveer 1.200 regels TypeScript. Een nieuwe engineer leest het in een middag door.

De trade-off is reëel. De frameworks geven je een voorsprong. LangGraph is met name uitstekend als je team al in het LangChain-ecosysteem leeft en je geen partners nodig hebt om prompts te bewerken; de checkpointing-primitives zijn ook handig als je human-in-the-loop-pauzes hebt die uren duren. CrewAI is echt prettig voor prototyping als je een multi-agent-gevoel wilt en je niets om token-economie geeft. Zit je op drie contracten per dag, kies dan wat je engineers al kennen en ship.

Bij 200 contracten per dag met een partner die mee wil praten, verandert de rekensom.

De audit van vijf minuten

Open het bestand waar de prompts van je agent staan. Klok hoe lang je erover doet om de exacte prompt te vinden die gisteren om 14:32 in productie draaide tegen contract-ID 8821. Lukt het je in onder de zestig seconden, dan zit je stack goed. Duurt het langer, dan zit de orchestrator-vraag stroomafwaarts van een logging-vraag. Fix dat eerst. Zodra de trace eerlijk is, wordt het framework-debat goedkoop: je kunt meten wat elke optie je daadwerkelijk kost, in plaats van erover te bekvechten.

Toen we de contract-samenvattende AI-agent voor dit Antwerpse kantoor herbouwden, liepen we ertegenaan dat de partner eigenaar moest zijn van de prompts maar engineering eigenaar moest zijn van de rails. We hebben het opgelost door elke prompt in een D1-tabel te versioneren en een nightly eval-set te draaien tegen de contracten van de afgelopen zeven dagen, zodat een prompt-regressie ons binnen twaalf uur oppiept in plaats van drie weken.