Elke week duik ik diep in een AI-onderwerp en test ik het in de praktijk. Deze week gaat het over het systeem dat ik de afgelopen maanden, samen met een andere AI-engineer, in alle stilte heb gebouwd. Van buitenaf lijkt het op “weer een automation flow”. Van binnenuit klopt dat beeld totaal niet.
Eerst even zonder jargon: een research agent is een AI-systeem dat zelfstandig meerdere bronnen raadpleegt, tussenresultaten weegt en pas antwoordt als het genoeg weet. Denk aan marktonderzoek of een technische vraag die verspreid staat over tientallen documentatiepagina’s. Simpel is dat allerminst. Ophalen, versheid, betrouwbaarheid van bronnen, beveiliging: elk onderdeel telt. Het lastige is niet het bouwen van één los onderdeel, maar om die onderdelen zo aan elkaar te rijgen dat het geheel daadwerkelijk shipt, schaalt en niet na de eerste week uit elkaar valt.
Wat tegenwoordig “research agent” wordt genoemd, is in mijn ervaring meestal een workflow met een paar extra stappen: tool A geeft zijn volledige output door aan tool B, die weer aan tool C. Wij wilden iets anders: een systeem dat redeneert over wat het al weet, geen doorgeefluik. Dat patroon leg ik in dit artikel vast.
Waar ons eerste ontwerp faalde
Onze v1 was hét schoolvoorbeeld van een research agent uit 2024: een planner, een router, een vloot tool callers, een synthesizer. Eén lineaire keten. De volledige output van elke tool werd in de context van de volgende stap gepropt.
Drie failure modes verdienden elk een eigen sectie in het runbook:
Context-inflatie. Bij iteratie 6 zaten we al op 80k tokens aan context (het werkgeheugen van het model), grotendeels rauwe tool outputs die elkaar tegenspraken. De accuracy op een vaste testset van 200 vragen daalde van 78% bij iteratie 1 naar 61% bij iteratie 6. Het model werd er niet slimmer van: het raakte er juist door in de war.
Kostenexplosie. Dezelfde query die in v1 €0,04 kostte, kostte in v3 €0,28 omdat elke tool call de volgende prompt tot 30k+ tokens optrok. We betaalden voor herhaling.
Drift. De agent begon soms een gerelateerde maar andere vraag te beantwoorden omdat een bepaalde tool output hem op een zijspoor zette. Zonder een stabiel beeld van wat hij al wist was elk nieuw stuk context een kans om van het doel af te drijven.
Het frame dat onze manier van bouwen veranderde
Halverwege kwam in onze ontwerpgesprekken steeds hetzelfde idee terug: information gain. In gewone taal: levert deze stap nieuwe informatie op of niet? Niet als SEO-buzzword, maar als principe op systeemniveau.
Kijk je naar de richting waarin Google zijn zoekmachine met taalmodellen ombouwt, dan is de beweging zichtbaar: herhaling wordt steeds minder beloond, nieuw begrip steeds meer. Content die daadwerkelijk iets toevoegt aan de knowledge graph, in plaats van te remixen wat al bestaat. Diezelfde logica bleek voor een research agent te gelden: elke stap moet informatie toevoegen, geen ruis.
Die omslag in denken zorgde ervoor dat een hoop keuzes vanzelf op hun plek vielen. In plaats van “meer tools chainen”, “meer context proppen” of “laat het model het uitzoeken” moest elke stap zijn bestaansrecht bewijzen door de information gain te vergroten. Veranderde een tool call niets aan het opgebouwde beeld van de agent (in het vak: de belief state), dan hoorde die call niet thuis in de loop.
Hoe de loop er in de praktijk uitziet
Nu wordt het even technisch. Het patroon waar we op uitkwamen heeft drie elementen bij elke iteratie:
- m_t · de tool-calling iteratie. De agent beslist of hij een tool aanroept en welke.
- n_t · de tokens waarmee hij werkt bij iteratie t. Cruciaal: dit is niet het volledige transcript tot dan toe.
- r_{t-1} · de samengevatte kern van wat de vorige tool ons daadwerkelijk vertelde, ontdaan van opmaak, herhaling en irrelevantie; in het vak knowledge distillation.
Bij t=1 heeft de agent alleen de vraag en een kleine context n_1. Hij roept een tool aan, krijgt een rauw resultaat en distilleert dat meteen tot r_1 voordat de volgende iteratie er iets van ziet. Bij t=2 is de werkcontext van de agent n_2 = n_1 + r_1, niet n_1 + raw_tool_output_1. Dan roept hij weer een tool aan, distilleert opnieuw, enzovoort.
Compressie is de kern van het hele systeem. Zonder die compressie blaast elke tool call het context window op. De accuracy daalt halverwege, de latency loopt op en de agent vergeet uiteindelijk welke vraag hij eigenlijk moest beantwoorden. Mét die compressie groeit de context in informatie, niet in tokens.
Selectieve retrieval boven chaining
Zodra distillation de ruggengraat van het systeem werd, vereenvoudigde de rest van het ontwerp zich vanzelf. We hadden geen tien tools nodig om te chainen. We hadden twee of drie goede nodig, met een strikte gate op wanneer elke tool mocht afgaan.
Het verschil in één overzicht:
| Chaining (alles doorgeven) | Distillation (elke stap samenvatten) | |
|---|---|---|
| Wat de volgende stap ziet | Volledige rauwe tool output | De gedistilleerde kern (r_t) |
| Wanneer een tool draait | Omdat hij in de keten staat | Alleen als de call iets nieuws kan opleveren |
| Stopcriterium | Steplimiet of einde keten | “Heb ik genoeg om te antwoorden?” |
De gate is zelf een kleine reasoning-stap: is er, gegeven de huidige gedistilleerde belief state, een nieuwe vraag die deze tool kan beantwoorden? Zo niet, dan slaat de agent de call over. We verbrandden ongeveer 40% van ons oude tool budget aan calls die dingen teruggaven die de agent al wist. In het nieuwe ontwerp daalde dat naar nul.
De agent besteedt zijn iteraties nu vooral aan een van deze drie dingen:
- Retrieval uit bronnen die voor deze query nog niet zijn geraadpleegd
- Het resultaat distilleren en afzetten tegen de bestaande belief state
- Beslissen of de gain hoog genoeg is om door te gaan, of dat het tijd is om te antwoorden
De volgorde is belangrijk. Stap 3 was het ontbrekende stukje in onze eerdere prototypes. Zonder een expliciete “levert dit nog steeds genoeg op?”-check bleef de loop draaien tot hij een steplimiet raakte. Door die check toe te voegen daalde de mediane run van 14 tool calls naar 4. De drie failure modes uit ons oude ontwerp verdwenen hiermee vrijwel volledig: de agent bleef op koers bij iteratie 12, in plaats van vast te lopen bij iteratie 6.
De cijfers die we nu zien
Na twee maanden side-by-side vergelijken op dezelfde queryset:
- Mediaan tool calls per query: 14 → 4
- Mediaan totaal tokens per query: 78.000 → 14.200
- Accuracy op de gold set, onze vaste testset van 200 gecontroleerde vragen: 71% → 84%
- Doorlooptijd van vraag tot antwoord (mediaan, p50): 38 s → 11 s
- Kosten per beantwoorde query: €0,21 → €0,05
- Operationele incidenten (per 1k queries): 9 → 1
Het kostencijfer is het cijfer dat ik steeds aan klanten laat zien. Een 4× reductie bij hogere accuracy is precies het soort curve dat de architectuur zelf rechtvaardigt.
Waarom dit meer is dan een slimme truc
Dit werkt vooral omdat het weerspiegelt hoe een bekwame menselijke onderzoeker daadwerkelijk te werk gaat. Je leest niet elke pagina van elke bron. Je scant, je comprimeert, je houdt een lopende belief state bij en je duikt pas dieper als de volgende bron echt iets gaat veranderen.
LLM’s geven je tools die uitnodigen tot chainen. De verleiding om “agent_1 → agent_2 → agent_3 → antwoord” te schrijven is groot. Maar chaining levert je alleen brokken context op voor een fris model dat geen idee heeft wat het vorige stuk betekende. Distillation levert je begrip op.
Daarom denk ik ook dat de richting van Google hier relevant is. Het signaal dat Google in LLM-gedreven zoekresultaten steeds zwaarder lijkt te wegen, is hetzelfde signaal waarop wij tool calls uiteindelijk baseerden: voegde deze stap nieuw begrip toe? Is het antwoord “nee”, dan verdient het geen ranking, en verdient het in onze agent geen tool call.
Voor wie is dit nu interessant, en voor wie nog niet?
Vooral voor teams die al een AI-workflow draaien die onderzoekswerk op volume doet: supportvragen beantwoorden uit een kennisbank, leveranciers of markten uitzoeken, documentatie doorspitten. Lopen daar de kosten of doorlooptijden op, dan is distillation de kleinste ingreep met het grootste effect. Je hoeft je architectuur niet om te gooien: een samenvattingsstap na elke tool call, plus een check of doorzoeken nog iets oplevert.
Nog niet interessant is dit bij een handvol van dit soort vragen per week. Dan is een simpele workflow, of een collega met een goede prompt, goedkoper. Voor veel Nederlandse bedrijven zit de winst bovendien eerst in de basis: een research agent op een kennisbank die niet wordt bijgehouden, distilleert vooral verouderde informatie.
De realistische eerste stap is meten, niet bouwen. Draai een set representatieve vragen door je huidige flow en noteer tokens, kosten en hoe vaak het antwoord klopt; pas met die nulmeting kun je beoordelen of een nieuw ontwerp iets oplevert.
Drie regels die ik mezelf destijds had willen meegeven
- Distilleer voordat je componeert. Laat nooit rauwe tool output doorstromen naar de volgende agent-stap. De compressielaag is niet optioneel. Het is de reden dat het systeem coherent blijft.
- Gate elke call op information gain. Een stap die de belief state niet verandert, is niet gratis. Hij is erger dan gratis. Het is een kans om af te drijven, context op te blazen en budget te verbranden.
- Stop met chainen, begin met budgetteren. De vraag is niet “welke tool draait er hierna?”. De vraag is “heb ik genoeg om te antwoorden?”. Een agent die zich die vraag elke iteratie stelt, shipt. Een die dat niet doet, is een heel dure demo.
Waar we nu staan
Research agents zijn geen experiment meer zodra ze minder kosten, sneller draaien en beter antwoorden dan de workflow die ze vervingen. Die grens hebben we voor ons systeem net overschreden. Voor ons is dit vanaf hier infrastructuur, geen onderzoek meer, al blijft het veld zelf volop in beweging.
Het lastige was niet één los onderdeel, maar het geheel vanaf dag één als reasoning system behandelen, met information gain als dragend principe. Ontwerp daarop, en de rest van de architectuur is geen aaneenschakeling van compromissen meer.