Dit stuk gaat over een systeem dat ik de afgelopen maanden samen met een andere AI-engineer heb gebouwd. Van buitenaf lijkt het op “weer een automation flow”, maar dat beeld klopt niet zodra je van dichtbij kijkt.
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. Eén los onderdeel bouwen is te doen. De kunst zit erin die onderdelen zo aan elkaar te rijgen dat het geheel in productie komt, meegroeit 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, in plaats van een 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 faalmodi 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? Bedoeld als ontwerpprincipe, niet als SEO-term.
Kijk je naar de richting waarin Google zijn zoekmachine met taalmodellen ombouwt, dan is de beweging zichtbaar: herhaling wordt steeds minder beloond en materiaal dat er echt iets aan toevoegt steeds meer. 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. Wij noemen die stap distillation. Verwar hem niet met knowledge distillation uit machine learning: daar traint een klein model op de output van een groot model, hier wordt niets getraind en alleen samengevat.
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. De gate vangt het grootste deel daarvan nu af voordat de call vertrekt.
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
Dat laatste getal laat ik klanten steeds als eerste zien. Een 4× lagere rekening bij een hogere accuracy is op zichzelf al genoeg om de herbouw te rechtvaardigen.
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. Met distillation geef je het model in plaats daarvan een beeld waar het mee verder kan.
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 in onze agent geen tool call.
Wanneer een samenvattingsstap zich terugbetaalt
Deze ingreep loont bij 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.
- Zet een poort voor elke call. Een stap die de belief state niet verandert, is bepaald niet 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 er hierna draait, maar of je genoeg hebt om te antwoorden. Een agent die zich dat elke iteratie afvraagt, komt in productie. Eentje die dat niet doet, blijft een heel dure demo.
Waar we nu staan
Een research agent is geen experiment meer zodra hij minder kost, sneller draait en beter antwoordt dan de workflow die hij verving. Die grens hebben we voor ons systeem net overschreden. Voor ons is dit vanaf hier infrastructuur, al blijft het veld zelf volop in beweging.
Het zwaarste werk zat niet in één los onderdeel. Het zat in de keuze om het geheel vanaf dag één als redeneersysteem te behandelen, met information gain als dragend principe. Doe je dat, dan volgt de rest van de architectuur uit die ene keuze in plaats van uit een reeks losse compromissen.