Agentic RAG: van zoekbalk in SharePoint naar een collega die antwoord geeft
Vraag iemand op een willekeurig MKB-kantoor waar de meest recente versie van een contract staat. Tien tegen één dat het antwoord is: “ergens in SharePoint, of misschien in de mailbox van Marieke”. Bedrijfskennis is in de meeste MKB-organisaties verspreid over een gedeelde schijf, een SharePoint, een Teams-kanaal, een handvol mailboxen en een paar PDF’s op de laptop van de oprichter. Iedereen zoekt elke week opnieuw. De zoekbalk vindt niks. Mensen mailen elkaar dezelfde vraag voor de derde keer.
Daar verandert nu iets aan. Niet door een nieuwe AI-chatbot in de hoek van het scherm, maar door een aanpak die “agentic RAG” heet. In klare taal: een AI die zélf bepaalt waar het zoekt, of het antwoord deugt, en of het nog een keer dieper moet kijken. Voor MKB is dat het verschil tussen een zoekbalk die niks vindt en een collega die antwoord geeft.
Wat agentic RAG anders maakt
Even nuchter beginnen. “RAG” staat voor Retrieval-Augmented Generation: een AI-model haalt eerst stukken tekst uit je eigen bronnen op en gebruikt die om te antwoorden. Dat is sinds 2023 de standaardmanier om AI met bedrijfsinformatie te laten werken. Het probleem is dat klassieke RAG in één rechte lijn werkt: vraag → één zoekslag in een vectordatabase → top-vijf resultaten → antwoord. Geen tweede poging, geen evaluatie, geen “ik weet het nog niet zeker, ik kijk verder”.
Agentic RAG is wat je krijgt als je daar een agent voor zet. Een agent is een AI-model dat zelf beslissingen mag nemen en hulpmiddelen mag inzetten — een zoekfunctie aanroepen, een vraag herformuleren, een tweede bron raadplegen, of erkennen dat het antwoord onvoldoende onderbouwd is en nog een ronde nodig heeft. De Agentic RAG-survey (Singh e.a., januari 2025) noemt dit “iteratief retrieven met planning, reflectie en tool-gebruik”. In de praktijk komt het neer op vier dingen die klassieke RAG niet doet:
- De vraag herformuleren. Een gebruiker vraagt “wat hebben we afgesproken met die nieuwe leverancier”. De agent merkt dat dat te vaag is, kijkt eerst in het CRM welke leverancier recent is toegevoegd, en zoekt dán pas in contracten.
- Meerdere bronnen langs. Eerst SharePoint, dan de mailbox, dan het projectarchief — niet allemaal tegelijk en hopen dat het goed komt.
- Het eigen antwoord nakijken. Klopt de gevonden context met de vraag? Spreken twee documenten elkaar tegen? Dan komt er een vervolgvraag in plaats van een verzonnen antwoord.
- Stoppen bij gebrek aan bewijs. Bij klassieke RAG fantaseert de AI er soms wat bij. Een goed ingerichte agent zegt: “ik vind hier geen sluitend antwoord — wil je dat ik in archief X kijk?”
Wat er in 2025–2026 veranderde
Tot anderhalf jaar terug was dit het terrein van research-papers en pilots. In de afgelopen twaalf maanden is het gewoon beschikbaar geworden:
- Anthropic publiceerde in september 2024 Contextual Retrieval en liet zien dat een combinatie van slimmere chunk-context en hybride zoeken de retrieval-fouten met 49 procent verminderde. Met een rerank-stap erbovenop liep dat op tot 67 procent minder fouten. Niet spectaculair gebracht, wél onderbouwd met code en benchmarks.
- AWS heeft in de loop van 2025 agentic retrieval als productfeature naar Amazon Bedrock Knowledge Bases gebracht — met parallelle deelvragen, sessiehistorie en herrangschikking voor complexe vragen. In november 2025 ging multimodale retrieval algemeen beschikbaar (zoeken over tekst, beeld, audio en video tegelijk).
- Microsoft heeft een soortgelijke “agentic retrieval”-laag in Azure AI Search gezet, en Google biedt vergelijkbare bouwblokken via Vertex AI. Open-source-frameworks als LangChain en LlamaIndex hebben sinds eind 2024 expliciete agentic-RAG-patronen in hun documentatie.
De rode draad: de leveranciers waar MKB-bedrijven uiteindelijk via hun integrator op uitkomen, hebben dit al in hun stack zitten. Het is geen exotische research-stof meer. Het is gewoon de manier waarop in 2026 nieuwe AI-koppelingen worden gebouwd.
Wat dit concreet voor je MKB betekent
Drie scenario’s die we in gesprekken bij Spies Creations veel zien terugkomen:
- Support en service. Een agent die bij elke binnenkomende klantvraag eerst in het ticketarchief, dan in de handleidingen en dan in de FAQ kijkt, en pas antwoordt als de bronnen daadwerkelijk dekken wat er gevraagd wordt. Eerstelijns wordt sneller, tweedelijns krijgt meer ruimte voor het echte werk.
- Sales en offertes. Eerder zelfde traject geleverd? De agent kijkt in oude offertes, contractbijlagen en projectnotities en stelt een eerste opzet samen. Geen verzonnen prijs — die blijft van de mens — maar wel een eerlijke schets op basis van wat je écht eerder hebt gedaan.
- Directie en bestuur. “Wat staat er bij ons over leveranciersrisico” of “welke contracten lopen dit kwartaal af”. Nu nog op drie systemen tegelijk. Met agentic RAG: één vraag, één antwoord, met bronvermelding zodat je het kunt verifiëren.
In alle drie de gevallen is het verschil met klassieke RAG dat de agent eerlijk benoemt wat wel en niet is gevonden. Dat is geen detail. Voor een directie die op het antwoord wil kunnen sturen, is “ik weet het niet zeker” oneindig veel waardevoller dan een verzonnen zekerheid.
Wat het niet is
Even hard de andere kant op. Agentic RAG lost niet op:
- De rommel in je bronnen. Drie versies van hetzelfde contract, een SharePoint met dode mappen, e-mailbijlagen die niemand archiveert. De agent vindt wat erin staat. Niet wat er had moeten staan.
- Toegangsrechten. Wie wat mag zien blijft een organisatorische vraag. Een agent moet niet meer rechten krijgen dan de gebruiker die de vraag stelt. Daar moet je over nadenken vóór de eerste koppeling live gaat, niet erna.
- De kosten. Iteratief retrieven betekent meer tokens en meer API-aanroepen. Goed ingericht is dat geen probleem. Slecht ingericht kun je honderden euro’s per maand verbranden aan loops die niets opleveren.
Wat je je IT-leverancier kunt vragen
Zoals bij elke nieuwe technologie geldt: vraag niet “is dit de toekomst”, maar “kun jij dit nuchter voor mijn bedrijf inrichten”. Een leverancier die agentic RAG verkoopt als wondermiddel is een leverancier die je over een jaar nog een keer iets gaat verkopen om het op te lossen.
Wat moet hij of zij wél kunnen vertellen? Welke bronnen aansluiten, welke toegangsrechten passen, hoe je controleert dat de agent niet meer doet dan mag, en hoe je achteraf terug kunt zien wat er feitelijk is opgevraagd. In een serieus gesprek over AI-koppelingen komen die punten vanzelf langs. Komen ze er niet, weet je genoeg.
Om dat gesprek beter te maken hebben we zeven vragen op een rij gezet. Geen audit, geen offerte — vragen die je in een gewoon overleg kunt stellen.
Download de Agentic RAG-readiness check — 7 vragen die je IT-leverancier moet kunnen beantwoorden. Naam en e-mail volstaan.
Liever even sparren over je eigen situatie? Plan een gesprek. Een uur, geen verkopers-script, gewoon kijken wat klopt en wat niet.
Bronnen
- Anthropic — Introducing Contextual Retrieval (september 2024)
- Singh e.a. — Agentic Retrieval-Augmented Generation: A Survey on Agentic RAG, arXiv 2501.09136 (januari 2025)
- AWS — Amazon Bedrock Knowledge Bases (productpagina)
- AWS — Multimodal retrieval for Bedrock Knowledge Bases generally available (november 2025)
- Microsoft Learn — Retrieval Augmented Generation in Azure AI Search
- NVIDIA Developer Blog — Traditional RAG vs. Agentic RAG
- Weaviate — What Is Agentic RAG?