Knowledge Base versus System Prompt voor AI-voice-agents in 2026

Knowledge Base versus System Prompt: waar hoort welke informatie thuis?

Het korte antwoord: de system prompt stuurt het gedrag aan, de knowledge base levert kennis, een mid-call tool haalt live data uit je systemen en de flow builder dwingt een vaste volgorde af. Deze vier lagen zijn niet inwisselbaar. Als je ze door elkaar haalt, krijg je een agent die trager antwoordt, per gesprek onnodig duurder is en bij elke prijswijziging vanaf nul opnieuw getest moet worden.

We zien dit patroon keer op keer bij klanten van Famulor. Een bedrijf begint met een strakke, korte system prompt. Drie maanden later bevat deze 40 FAQ-antwoorden, de volledige prijslijst, openingstijden voor alle drie de locaties en een lijst met 60 productvarianten. De agent werkt nog wel, maar reageert trager, volgt de gespreksstructuur minder betrouwbaar en niemand durft er nog iets aan te veranderen.

Dit artikel geeft je een beslissingsmatrix: welke informatie hoort in welke laag, waarom, en wat het je kost als je de verkeerde keuze maakt. Als je net begint, is het de moeite waard om eerst naar de No-Code AI Voice Agent en de kernconcepten in de documentatie te kijken.

De vier contextlagen van een AI-voice-agent

Elke voice-agent in productie haalt zijn antwoorden uit vier duidelijk te onderscheiden bronnen. Het cruciale verschil is wanneer elk stukje informatie wordt geladen.

• System prompt: wordt bij elk gesprek volledig geladen en gedurende het hele gesprek geëvalueerd. Altijd actief, altijd deterministisch, altijd betaald in tokens.
• Knowledge base: wordt alleen opgehaald wanneer de gesprekscontext een zoekopdracht triggert. Schaalt naar grote hoeveelheden tekst zonder de prompt te vervuilen.
• Mid-call tool: roept tijdens het gesprek een API aan en krijgt exacte, actuele waarden terug. De enige laag die kan rekenen, sorteren en terugschrijven.
• Flow builder: definieert het gespreksverloop in plaats van dit aan het model over te laten. Voor sequenties waarbij de volgorde niet onderhandelbaar is.

Vuistregel: de prompt is het brein van je agent, niet zijn encyclopedie. Alles wat gedrag vormgeeft, hoort erin thuis. Alles wat enkel opgezocht hoeft te worden, hoort er buiten.

Wanneer is de system prompt de juiste keuze?

De system prompt is het deterministische fundament. Deze is bij elk gesprek aanwezig, ongeacht wat de beller zegt. Precies daarom hoort hier alleen in wat altijd van toepassing moet zijn.

Zet in de system prompt:

• Rol en toon: wie de agent is, voor welk bedrijf hij spreekt, hoe hij klinkt. Een receptie-agent voor een accountantskantoor klinkt anders dan een outbound-agent voor zonnepanelen.
• Gesprekslogica en volgorde: begroeting, volgorde van vervolgvragen, wanneer te openen en wanneer af te sluiten.
• Guardrails: wat de agent nooit mag doen. Geen juridisch advies, geen bindende prijsafspraken, geen diagnoses aan de telefoon.
• Escalatieregels: wanneer doorverbinden naar een mens, wanneer een terugbelverzoek aanbieden.
• Korte, stabiele standaardantwoorden: drie tot vijf bezwaren die dagelijks voorkomen en altijd op dezelfde manier beantwoord moeten worden.
• Triggers voor gestructureerde logica: wanneer elke mid-call tool wordt aangeroepen en met welke parameters.

Concreet: een tandartspraktijk met zes behandelkamers schrijft in de prompt dat de agent bij pijnklachten altijd eerst naar de urgentie vraagt en acute gevallen direct doorverbindt naar de receptie. Dat is gedrag. Welke kamers er op donderdag vrij zijn, staat daarentegen niet in de prompt, maar komt uit de agenda. De system prompt guide laat zien hoe je een prompt strak structureert.

Wanneer wint een knowledge base?

Een knowledge base slaat lange, ongestructureerde tekst op en wordt alleen doorzocht wanneer het gesprek daarom vraagt. De agent draagt niet permanent 20 pagina's documentatie met zich mee; hij haalt het relevante gedeelte op wanneer dat nodig is.

Zet in de knowledge base:

• Support- en productdocumentatie: handleidingen, troubleshooting, installatiestappen.
• Lange of vaak wijzigende FAQ-collecties: alles boven de pakweg twaalf vragen, zeker als vakinhoudelijke teams de content beheren.
• Beleid en contracttaal: retourbeleid, garantievoorwaarden, privacyverklaringen waar de exacte formulering ertoe doet.
• Regionale of segmentspecifieke regels in proza: bijvoorbeeld verschillende servicebeloftes per locatie, zolang er niets berekend hoeft te worden.

De echte winst is organisatorisch. De knowledge base scheidt inhoud van gedragslogica. Je serviceteam kan een garantievoorwaarde bijwerken zonder dat iemand aan de prompt hoeft te komen en het gespreksgedrag in gevaar brengt.

De grenzen zijn eveneens duidelijk. Een knowledge base kan niet rekenen, niet sorteren en niet betrouwbaar individuele waarden uit een prijstabel halen. En omdat het ophalen afhangt van de context, is het niet volledig deterministisch: twee vergelijkbare gesprekken kunnen net iets andere passages raken. Voor kennisvragen is dat onschadelijk. Voor bindende getallen niet.

Wanneer werkt alleen een mid-call tool?

Zodra de agent een exacte, actuele waarde nodig heeft of iets moet wijzigen in een extern systeem, is er geen ontkomen aan een mid-call tool. Deze roept tijdens het gesprek een API aan en krijgt een precies antwoord terug.

Typische gevallen:

• Gestructureerde data in externe systemen: CRM-velden, orderstatus, contractduur, voorraad per vestiging.
• Gepersonaliseerde realtime waarden: openstaand saldo, eerstvolgende beschikbare afspraak, bezorgstatus.
• Conditionele logica: als klanttype zakelijk is en postcode binnen het servicegebied valt, bied dan optie B aan.
• Schrijfbewerkingen: een lead aanmaken, afspraak boeken, adres wijzigen, ticket openen.
• Berekeningen en drempelwaarden: kwalificatiecriteria, volumekortingen, voorrijkosten.

Een voorbeeld uit de techniek: een loodgietersbedrijf met 14 monteurs laat de agent bij elk spoedgeval checken of de postcode binnen het werkgebied valt en of er vandaag nog een monteur beschikbaar is. Beide zijn live waarden. Los dit op met een knowledge base en de agent belooft af en toe een klus waar niemand heen kan rijden. De technische implementatie wordt behandeld in custom mid-call tools, en de koppeling met je bestaande software verloopt via de Famulor-integraties.

Wanneer neemt de flow builder de controle?

De flow builder is de vierde laag en de blinde vlek in de meeste vergelijkingen. Deze definieert het gespreksverloop expliciet in plaats van het aan het taalmodel over te laten. Dat is de juiste keuze wanneer de volgorde om juridische of operationele redenen niet onderhandelbaar is.

• Verplichte vragen: toestemming opnemen, identificatie voor openbaarmaking, leeftijdsverificatie.
• Intake in formuliervorm: schademeldingen, patiëntenintake, pre-kwalificatie van sollicitanten met vaste velden.
• Vertakkingen met duidelijke eindpunten: drie aanvraagtypes, drie verschillende afsluitingen.

Het verschil met de prompt: een prompt vraagt het model om een volgorde te volgen. De flow builder dwingt deze af. Voor een toestemmingsvraag is dat geen verschil in gemak, maar in compliance.

De beslissingsmatrix in één oogopslag

Wat de verkeerde laag werkelijk kost

De kosten van een slechte contextarchitectuur komen op drie plekken naar voren, en geen van die plekken staat op een factuur met de titel 'verkeerde beslissing'.

Ten eerste: tokens. De system prompt wordt bij elk gesprek verwerkt. Een prompt die groeit van 800 naar 6.000 woorden maakt elk gesprek duurder, ongeacht of de beller de extra informatie überhaupt nodig heeft. Bij 40 gesprekken per dag betaal je die toeslag 40 keer per dag, zelfs als slechts twee bellers naar garantievoorwaarden vragen. Hoe gebruik zich vertaalt in facturatie staat in de documentatie over usage-based pricing.

Ten tweede: latency. Aan de telefoon is wachten pijnlijk zichtbaar. Er is geen laadbalk, alleen stilte. Hoe meer context het model voor elk antwoord verwerkt, hoe langer het duurt voordat de eerste lettergreep wordt uitgesproken. Een opgeblazen prompt vertraagt elk antwoord in het gesprek, terwijl het ophalen uit een knowledge base alleen het antwoord vertraagt waar het daadwerkelijk nodig is.

Ten derde: onderhoudsinspanning. Dit is de duurste post en degene die het vaakst over het hoofd wordt gezien. Als prijzen in de prompt staan, is elke prijswijziging een ingreep in de gedragslogica van de agent en vereist dit een volledige testronde. Als prijzen uit een mid-call tool komen die je voorraadsysteem uitleest, is een prijswijziging simpelweg een prijswijziging.

Bereken voor je eigen situatie hoe gespreksvolume, gemiddelde gespreksduur en personeelskosten de businesscase beïnvloeden:

Implementatie in vier stappen

1. Inventariseer. Exporteer je huidige system prompt en label elke paragraaf met B voor gedrag, K voor kennis of D voor data. Alles wat geen B is, is een kandidaat voor verplaatsing.
2. Verplaats kennis. Verschuif alle K-blokken naar een knowledge base en geef deze een nauwkeurige beschrijving zodat de agent weet wanneer hij moet zoeken. Een vage beschrijving is de meest voorkomende reden waarom het ophalen nooit wordt geactiveerd.
3. Koppel de data. Controleer voor elk D-blok of er een API bestaat. Agenda's, CRM, voorraad- en ticketsystemen kunnen meestal worden gekoppeld via bestaande integraties of een custom mid-call tool. Wat de agent tijdens het gesprek verzamelt, sla je op in variabelen en geef je door in gestructureerde vorm.
4. Vergrendel verplichte paden. Alles wat wettelijk in een specifieke volgorde moet gebeuren, verhuist naar de flow builder. Test daarna op basis van echte gespreksopnames, niet op verzonnen voorbeeldgesprekken.

Een goed doel na de opschoonactie: de system prompt past op twee tot drie schermen en bevat geen enkel getal dat kan veranderen.

Veelgemaakte fouten in de praktijk

• Prijzen in de prompt. De klassieker. Prijzen veranderen, prompts worden zelden netjes bijgewerkt en de agent citeert maandenlang vol vertrouwen verouderde bedragen.
• Openingstijden in de prompt. Werkt precies tot de eerste feestdag of bedrijfssluiting. Openingstijden zijn data, geen gedragsregels.
• Knowledge base voor tabellen. Prijstabellen en staffelkortingen in een knowledge base stoppen levert plausibel klinkende maar onjuist samengestelde antwoorden op. Tabellen horen achter een tool.
• Beschrijving van de knowledge base te vaag. Als de agent niet weet wat de bron dekt, raadpleegt hij deze nooit en antwoordt hij op basis van modelkennis.
• Alles in de flow builder. Het andere uiterste. Script elk pad en je bent terug bij een telefoonmenu, alleen dan met een betere stem. Gebruik vaste paden alleen waar ze echt nodig zijn.
• Geen fallback-regel. Voor het geval dat een tool niet reageert of de knowledge base niets vindt, heeft de agent een duidelijke instructie in de prompt nodig: geef het netjes toe, bied een terugbelverzoek aan, ga niet gokken.

Drie voorbeelden uit de industrie

Accountantskantoor met circa 400 klanten. De prompt bevat de toon, de regel dat er nooit fiscaal advies aan de telefoon wordt gegeven en de escalatie naar de verantwoordelijke dossierbeheerder. De knowledge base bevat uitleg over deadlines en benodigde documenten per type dossier. De mid-call tool levert de status van de klant en vrije consultatie-slots. De flow builder regelt de identificatie voor elke openbaarmaking.

Shopify-webshop met circa 5.000 orders per maand. De prompt bepaalt de toon en de limiet voor coulancebeslissingen. De knowledge base bevat het retourbeleid en de retourinstructies. De mid-call tool haalt de orderstatus en verzendinformatie op. De flow builder leidt bellers door de retourregistratie zodat er geen verplicht veld wordt gemist.

Autodealer met werkplaats en verkoop. De prompt routeert bellers naar service of verkoop en definieert wanneer er moet worden doorverbonden naar een verkoopadviseur. De knowledge base bevat onderhoudsintervallen en garantieomvang. De mid-call tool levert vrije werkplaats-slots en voertuigbeschikbaarheid. Meer sectorspecifieke opstellingen staan onder industrieën.

Conclusie

Contextarchitectuur is geen detail. Het is het verschil tussen een agent die drie maanden meegaat en een agent die drie jaar schaalt. De regel is simpel: gedrag in de prompt, kennis in de knowledge base, data achter een tool, verplichte sequenties in de flow builder. Duidelijke grenzen tussen deze lagen maken je agent sneller, goedkoper en bovenal onderhoudbaar door de mensen die de content toch al beheren.

Als je een bestaande agent opschoont, begin dan met de inventarisatie uit het implementatiegedeelte: exporteer de prompt, label elke paragraaf B, K of D, en verplaats alles wat geen B is. In de meeste gevallen krimpt de prompt met meer dan de helft. Met Famulor bouw je alle vier de lagen zonder code in dezelfde interface en behoud je volledige controle over kosten, latency en onderhoud. Een overzicht van de plannen is beschikbaar op de pricing-pagina.

FAQ

Wat hoort er in de system prompt en wat niet?

De prompt moet de rol, toon, gesprekslogica, guardrails en escalatieregels bevatten. Het moet geen prijzen, openingstijden, lange FAQ-collecties of zaken bevatten die kunnen veranderen zonder dat het gedrag hoeft te veranderen.

Wanneer heb ik een knowledge base nodig in plaats van een langere prompt?

Zodra je meer dan pakweg twaalf FAQ-antwoorden hebt, of tekst insluit die door een vakinhoudelijk team wordt beheerd. De knowledge base wordt alleen opgehaald wanneer dat nodig is en belast dus niet elk gesprek.

Waarom zou ik geen prijzen in de knowledge base zetten?

Omdat een knowledge base tekst vindt, maar niet kan rekenen en niet betrouwbaar individuele cellen uit tabellen kan extraheren. Prijzen, staffels en beschikbaarheid horen achter een mid-call tool met een exact API-antwoord.

Verhoogt een knowledge base de latency van mijn voice-agent?

Alleen bij de antwoorden waar deze daadwerkelijk wordt opgehaald. Een opgeblazen system prompt vertraagt daarentegen elk antwoord in het hele gesprek.

Wat is het verschil tussen de flow builder en de system prompt?

De prompt vraagt het model om een volgorde te volgen. De flow builder dwingt deze technisch af. Voor toestemming, identificatie en verplichte velden is dat verschil doorslaggevend.

Hoe groot kan een system prompt zijn?

Er is geen harde limiet, maar een goed doel is twee tot drie schermen. Alles daarbuiten betekent bijna altijd dat kennis of data naar de prompt is gemigreerd.

Kan ik alle vier de lagen in Famulor gebruiken zonder developer?

Ja. System prompt, knowledge base, mid-call tools en flow builder zijn allemaal configureerbaar via de interface. Er zijn meer dan 300 integraties beschikbaar voor het koppelen van je data.

Wat gebeurt er als een mid-call tool niet reageert tijdens het gesprek?

De agent heeft een expliciete fallback-regel in de system prompt nodig. Het verstandige patroon is om de ontbrekende waarde openlijk te benoemen en een terugbelverzoek of doorverbinding aan te bieden in plaats van te gokken.

Hoe test ik of mijn contextarchitectuur werkt?

Test op basis van echte gespreksopnames in plaats van verzonnen voorbeelden. Let er in het bijzonder op of de knowledge base daadwerkelijk wordt geactiveerd bij de vragen die je verwacht.