Componenten als kennisobjecten: RAG in plaats van prompt-monolieten

Als je ooit geprobeerd hebt om een complexe UI- of systeemopzet in een agent-workflow te proppen, ken je het probleem: of je stopt enorme componentteksten in de context — of de agent gokt. Geen van beide eindigt goed.

Een praktische uitweg: componenten (frontend-componenten, services, modules, zelfs hele feature-slices) niet als “tekstwoestijn” in prompts meeslepen, maar als kennisobjecten in een RAG-database opslaan — en ze gericht per tool ophalen.

De truc is de granulariteit: in plaats van “hier is ons hele design system”, sla je per component op wat echt nodig is: doel, props/inputs, states, events, afhankelijkheden, API-contracten, voorbeelden, do’s/don’ts. Plus metadata zoals versie, eigenaarschap, paden, tags (bijv. “checkout”, “accessibility”, “mobile”).

Dan werk je tool-first: de agent begint niet met een prompt-monoliet, maar vraagt eerst naar de relevante bouwstenen — “geef me alle componenten die betaalstatus visualiseren”, of “toon me de geldige props van <ComponentX> plus een voorbeeld”. Zo blijft de context klein, schoon en actueel.

Het resultaat in de praktijk

• Minder context-vervuiling en tokenkosten
• Minder hallucinaties, omdat alleen geverifieerde bouwstenen worden opgehaald
• Betere consistentie, omdat de agent tegen dezelfde contracten werkt als het team
• Snellere wijzigingen: je updatet de component in de DB, niet 20 prompts

RAG wordt daarmee niet alleen “documentzoeken”, maar een interface naar de systeemwaarheid: componenten als opvraagbare, geversioneerde kenniseenheden — in plaats van copy-paste chaos.