Komponenten als Wissensobjekte: RAG statt Prompt-Monolith

Wer schon mal versucht hat, ein komplexes UI- oder System-Setup in einen Agenten-Workflow zu pressen, kennt das Problem: Entweder du packst riesige Komponenten-Textsammlungen in den Kontext — oder der Agent rät. Beides endet selten gut.

Ein praktischer Ausweg: Komponenten (Frontend-Komponenten, Services, Module, sogar ganze Feature-Slices) nicht als “Textwüste” in Prompts zu tragen, sondern als Wissensobjekte in eine RAG-Datenbank zu legen — und sie gezielt per Tool abzurufen.

Der Trick ist die Granularität: Statt “hier ist unser gesamtes Design System”, speicherst du pro Komponente das, was wirklich gebraucht wird: Zweck, Props/Inputs, Zustände, Events, Abhängigkeiten, API-Verträge, Beispiele, Do’s/Don’ts. Zusätzlich Metadaten wie Version, Ownership, Pfade, Tags (z. B. “checkout”, “accessibility”, “mobile”).

Dann arbeitest du tool-first: Der Agent startet nicht mit einem Prompt-Monolithen, sondern fragt zuerst nach den relevanten Bausteinen — “gib mir alle Komponenten, die Payment-Status visualisieren”, oder “zeige mir die gültigen Props von <ComponentX> plus ein Beispiel”. So bleibt der Kontext klein, sauber und aktuell.

Das Ergebnis in der Praxis

• Weniger Context-Pollution und Token-Kosten
• Weniger Halluzinationen, weil nur verifizierte Bausteine gezogen werden
• Bessere Konsistenz, weil der Agent gegen dieselben “Contracts” arbeitet wie das Team
• Schnellere Änderungen: du updatest die Komponente in der DB, nicht 20 Prompts

RAG wird damit nicht nur “Dokumenten-Suche”, sondern ein Interface zur System-Wahrheit: Komponenten als abrufbare, versionierte Wissenseinheiten — statt copy-paste Chaos.