AI Agents die altijd het juiste antwoord geven

Het probleem met de meeste AI agents

Vraag een gemiddelde AI agent “hoeveel omzet hadden we vorig kwartaal?” en je krijgt een prima antwoord. Vraag dezelfde agent “wat ging er mis bij dat project van vorig jaar met die lastige klant?” en je krijgt onzin. Of erger: een zelfverzekerd fout antwoord.

Het verschil zit niet in het taalmodel. Het verschil zit in hoe de agent informatie ophaalt. De meeste systemen draaien op keyword search: ze matchen woorden uit je vraag met woorden in een database. Dat werkt bij exacte vragen. Het faalt volledig bij alles wat vaag, impliciet of contextafhankelijk is.

En laten we eerlijk zijn: de vragen die er echt toe doen in een bedrijf zijn bijna altijd vaag.

Waarom keyword search niet genoeg is

Stel je voor: een medewerker vraagt aan de interne AI agent “waarom lopen onze projecten uit?” Keyword search zoekt naar documenten die de woorden “projecten” en “uitlopen” bevatten. Maar het echte antwoord staat misschien in een retrospective-document over “vertragingen door scope creep”, in een Slack-thread over “onduidelijke requirements”, en in een CRM-notitie over “klant wijzigde specificaties na sprint 2.”

Geen van die bronnen bevat het woord “uitlopen.” Keyword search mist ze allemaal.

Dit is het fundamentele probleem. Menselijke communicatie is associatief, niet letterlijk. Wij denken in concepten, relaties en patronen. Een zoeksysteem dat alleen op woorden matcht, begrijpt niets van wat je eigenlijk bedoelt.

De drielaags-architectuur

Bij ScaleLayR bouwen we AI agents op een architectuur die drie ophaal-lagen combineert. Elke laag vangt op wat de andere mist. Samen bereiken ze een nauwkeurigheid van 99,99% op interne kennisbanken.

Laag 1: Semantisch zoeken met pgvector

De eerste laag vervangt keyword search door semantisch zoeken. In plaats van woorden te matchen, matchen we betekenis.

Hoe dat werkt: elk document, elke alinea, elke notitie wordt omgezet naar een embedding. Dat is een wiskundige representatie van de betekenis van die tekst, uitgedrukt in een vector van honderden dimensies. “Projecten lopen uit” en “vertragingen door scope creep” staan ver uit elkaar in woordenboeken, maar dicht bij elkaar in embedding-ruimte.

pgvector is een PostgreSQL-extensie die deze vectoren opslaat en doorzoekbaar maakt. Het draait in dezelfde database als je bestaande bedrijfsdata. Geen apart systeem, geen extra infrastructuur, geen vendor lock-in.

Wanneer een medewerker een vraag stelt, wordt die vraag ook omgezet naar een embedding. pgvector vindt vervolgens de documenten waarvan de betekenis het dichtst bij de vraag ligt. Niet de woorden, de betekenis.

Dit alleen al lost 80% van de “vage vraag”-problemen op. Maar 80% is niet 99,99%.

Laag 2: Relaties ontsluiten met Apache AGE

De tweede laag voegt context toe die puur semantisch zoeken mist: de relaties tussen dingen in je organisatie.

Apache AGE is een graph database-extensie voor PostgreSQL. Het modelleert je bedrijfsdata als een netwerk van verbonden entiteiten: klanten, projecten, medewerkers, documenten, beslissingen, events. Elke entiteit is een node, elke relatie is een edge.

Nu een belangrijke nuance: Apache AGE zelf werkt op property-matching. Je doorzoekt de graph met exacte waarden — namen, ID’s, labels. Dat is in basis keyword-gebaseerd. De graph is niet semantisch slim. Maar dat hoeft ook niet, want de intelligentie zit in hoe je de lagen combineert.

Het patroon werkt zo: pgvector (laag 1) ontvangt de vage vraag en vindt semantisch relevante documenten. Uit die documenten extraheert de applicatielaag concrete entiteiten — een klantnaam, een projectnummer, een medewerker. Die exacte entiteiten worden vervolgens als startpunten in de graph gebruikt.

Apache AGE neemt het daar over en traverseert de relaties:

• Klant X had contract met Project Y
• Project Y had fase Sprint 3 die resulteerde in Vertraging Z
• Vertraging Z was gerelateerd aan Scope wijziging W
• Medewerker A schreef retrospective over Project Y

Het resultaat: pgvector vertaalt de vage vraag naar concrete entiteiten. Apache AGE traverseert vanuit die entiteiten het volledige relatienetwerk. De graph mist niets, want hij zoekt niet op woorden — hij volgt verbindingen. De retrospective van Medewerker A wordt gevonden via de relatie met Project Y, niet via een keyword-match.

Deze combinatie lost een probleem op dat geen van beide lagen alleen kan: vage vragen beantwoorden met relationeel complete antwoorden. pgvector begrijpt wat je bedoelt. Apache AGE weet wat er allemaal mee samenhangt.

Laag 3: Geheugen met meervoudige filters

De derde laag is wat de nauwkeurigheid van 99% naar 99,99% brengt: een persistent geheugen met meervoudige filtermechanismen.

Elke interactie met de agent wordt opgeslagen als een geheugen-entry met meerdere dimensies:

• Semantische embedding van de vraag en het antwoord
• Entiteit-tags (welke klanten, projecten, medewerkers waren betrokken)
• Temporele metadata (wanneer, welke periode betrof het)
• Betrouwbaarheidsscore (was het antwoord bevestigd, gecorrigeerd, of genegeerd?)
• Interactie-context (wie vroeg het, vanuit welke afdeling, in welke workflow)

Bij een nieuwe vraag doorloopt het geheugen meerdere filterstappen:

1. Semantische filter: welke eerdere interacties zijn qua betekenis verwant?
2. Entiteit-filter: overlappen de betrokken entiteiten (klant, project, afdeling)?
3. Temporele filter: valt de vraag binnen dezelfde tijdsperiode?
4. Betrouwbaarheidsfilter: welke eerdere antwoorden werden bevestigd door de gebruiker?

Alleen geheugens die door meerdere filters komen, worden meegenomen in het antwoord. Dit voorkomt hallucinaties en zorgt ervoor dat de agent leert van eerdere interacties.

pgvector is het landschap, Apache AGE het wegennetwerk

Een analogie die het samenspel helder maakt.

pgvector maakt van al je data een continu landschap. Elk document, elke alinea, elke notitie wordt een punt in dat landschap. Punten die qua betekenis op elkaar lijken, liggen dicht bij elkaar. “Projecten lopen uit” en “vertragingen door scope creep” liggen in dezelfde vallei, ook al delen ze geen enkel woord.

Wanneer je een vraag stelt, wordt die vraag ook een punt. pgvector zoekt vervolgens: welke punten liggen het dichtst bij? Dat is fuzzy, continu, probabilistisch. Je zoekt in een regio, niet naar een exact adres.

Apache AGE is een wegennetwerk. De nodes zijn steden: concrete entiteiten zoals Klant X, Project Y, Medewerker A, Sprint 3. De edges zijn wegen: vaste verbindingen met een naam (“had contract met”, “resulteerde in”, “schreef retrospective over”). Een graph query is de auto die over die wegen rijdt.

Maar die auto kan alleen rijden als je hem een startpunt geeft. Een exact adres. Een klantnaam, een project-ID. De auto kan niet zeggen “rij naar iets dat lijkt op Project Y.” Hij heeft het exacte adres nodig.

En daar zit de kracht van de combinatie. pgvector zegt: “zoek in de regio Brabant, daar ligt het antwoord ergens.” Uit de gevonden documenten haalt de applicatielaag concrete entiteiten: een klantnaam, een projectnummer. Dat zijn de exacte adressen.

Apache AGE zet de auto neer bij dat adres en traverseert elke weg: contracten, projectfases, vertragingen, scope-wijzigingen, retrospectives. Alles wat verbonden is.

pgvector vindt de buurt. Apache AGE kent elke straat.

Geen van beide kan het alleen. pgvector vindt de juiste regio maar mist de exacte verbindingen. Apache AGE kent elke verbinding maar kan niet zoeken zonder startadres. Samen: vage vraag in, scherp antwoord uit.

Waarom alles in PostgreSQL draait

Een bewuste architectuurkeuze: pgvector en Apache AGE zijn beide PostgreSQL-extensies. Je hele kennislaag draait in een enkele database.

De voordelen zijn substantieel:

• Een bron van waarheid: geen synchronisatieproblemen tussen aparte systemen
• ACID-transacties: je geheugenlaag is net zo betrouwbaar als je productiedata
• SQL-interface: je bestaande team kan queries draaien, debuggen en monitoren
• Schaalbaarheid: PostgreSQL schaalt verticaal tot enorme datasets, en horizontaal met Citus
• Geen vendor lock-in: alles is open-source, draait overal

Vergelijk dat met een architectuur waarbij Pinecone je vectoren beheert, Neo4j je graph host, en Redis je geheugen cached. Drie systemen, drie faalrisico’s, drie facturen, drie teams die het moeten begrijpen.

De 99,99% in de praktijk

Wat betekent 99,99% nauwkeurigheid concreet? Op 10.000 vragen geeft de agent 9.999 keer het juiste antwoord. De ene keer dat het fout gaat, is het systeem eerlijk genoeg om te zeggen “ik heb hier geen betrouwbaar antwoord op.”

Dat laatste punt is cruciaal. De meeste AI-falen komen niet doordat het model iets niet weet. Ze komen doordat het model doet alsof het iets weet. Onze architectuur heeft een ingebouwde onzekerheidsmeting. Wanneer geen van de drie lagen een antwoord met voldoende betrouwbaarheid oplevert, zegt de agent dat. Liever eerlijk onzeker dan zelfverzekerd fout.

De nauwkeurigheid wordt bereikt door redundantie:

• Laag 1 (pgvector) vangt semantisch verwante informatie
• Laag 2 (Apache AGE) voegt relationele context toe
• Laag 3 (geheugen) levert bewezen antwoordpatronen

Een antwoord dat door alle drie de lagen wordt bevestigd, is bijna gegarandeerd correct. Een antwoord dat door slechts een laag wordt ondersteund, krijgt een lagere betrouwbaarheidsscore en wordt navenant gepresenteerd.

Vage vragen, scherpe antwoorden

Terug naar de vraag waarmee we begonnen: “wat ging er mis bij dat project van die lastige klant?”

In onze architectuur gebeurt het volgende:

1. pgvector vindt documenten die semantisch gaan over projectproblemen, vertragingen en klantfeedback. Uit de top-resultaten extraheert de applicatielaag concrete entiteiten: een klantnaam, projectnummers, betrokken medewerkers.
2. Apache AGE neemt die entiteiten als startpunten en traverseert het relatienetwerk. Alle verbonden projectfases, vertragingen, scope-wijzigingen en retrospectives worden opgehaald — niet via vage zoektermen, maar via exacte graph-relaties.
3. Het geheugen herkent dat deze gebruiker eerder vergelijkbare vragen stelde over hetzelfde project en weet welke context toen relevant was.

Het resultaat: een concreet, gedocumenteerd antwoord met bronverwijzingen. Niet een generiek verhaal over “veelvoorkomende projectrisico’s.”

Implementatie: weken, geen maanden

Het mooie van deze stack is dat het geen greenfield-project hoeft te zijn. De meeste bedrijven hebben al PostgreSQL draaien. pgvector en Apache AGE zijn extensies die je installeert, geen migraties die je uitvoert.

De implementatie verloopt in drie fases:

1. Week 1-2: Data-audit en embedding-pipeline opzetten. Bestaande documenten, notities en kennisbankartikelen worden geindexeerd in pgvector.
2. Week 3-4: Graph-model bouwen in Apache AGE. Entiteiten en relaties uit je bestaande systemen worden gemodelleerd.
3. Week 5-6: Geheugenlaag activeren en agent fine-tunen op je specifieke domein. Meervoudige filters kalibreren op basis van testresultaten.

Na zes weken heb je een AI agent die je interne kennisbank doorzoekt met een nauwkeurigheid die handmatig zoeken overtreft. En die steeds beter wordt naarmate meer mensen hem gebruiken.

Conclusie

De race om AI agents is niet een race om het beste taalmodel. Het is een race om de beste ophaalarchitectuur. Het model dat je antwoorden genereert is alleen zo goed als de informatie die het krijgt.

Een drielaags-systeem met pgvector voor semantisch zoeken, Apache AGE voor relationele context, en een persistent geheugen met meervoudige filters levert de nauwkeurigheid die bedrijfskritische toepassingen vereisen. Niet 90%. Niet 95%. Maar 99,99%.

En het draait allemaal op PostgreSQL. Open-source, bewezen, schaalbaar. Geen exotische infrastructuur, geen vendor lock-in, geen verrassingen op de factuur.