Aufgabe, Wissensdaten, Constraints: die drei Bausteine jedes KI-Assistenten
Jeder brauchbare KI-Assistent besteht aus genau drei Bausteinen: der Aufgabe (was er tun soll), den Wissensdaten (worauf er dabei zugreift) und den Constraints (was er nicht tun soll und wo er nachfragt). Wer diese drei sauber trennt, bekommt einen Assistenten, den man reparieren kann. Wer sie vermischt, bekommt ein langes Textfeld, in dem später niemand mehr findet, wo der Fehler steckt.
Das Schema stammt nicht von mir. Ich habe es in einem Workshop beobachtet: Die Teilnehmenden sollten ein Tool ausprobieren und haben stattdessen unaufgefordert sieben Assistenten spezifiziert, jeden einzelnen nach genau dieser Dreiteilung. Niemand hatte ihnen die Struktur vorgegeben. Sie ist offenbar die naheliegende Art, über so ein Ding nachzudenken, sobald man es ernst meint.
Baustein 1: Die Aufgabe
Die Aufgabe beschreibt den Job in einem Satz, plus die Schritte, wenn es welche gibt.
Ein Beispiel, konstruiert für diesen Artikel: „Du beantwortest Erstanfragen von Interessenten, die über das Kontaktformular kommen. Du prüfst, welche unserer drei Leistungspakete passt, schlägst genau eines vor, nennst den Preisrahmen und bietest einen Termin an.”
Was hier drin gehört: das Ziel, die Reihenfolge der Schritte, das Format des Outputs, die Rolle. Was hier nicht hingehört: konkrete Preise, Kundennamen, Leistungsbeschreibungen, Tonalitätsregeln, Ausnahmefälle. Das sind Wissensdaten und Constraints, und sie gehören in ihre eigenen Bausteine.
Die Prüffrage für die Aufgabe: Könntest du sie einem neuen Werkstudenten am Telefon vorlesen, ohne dass er zurückfragt, was er überhaupt produzieren soll? Wenn ja, sitzt der Baustein.
Baustein 2: Die Wissensdaten
Wissensdaten sind alles, worauf sich der Assistent stützt, statt es zu erfinden. Preisliste, Leistungsbeschreibung, FAQ, Beispiel-Outputs, Tonalitätsguide, Ausschlusslisten.
Der entscheidende Punkt: Diese Dinge gehören als Dateien an den Assistenten, nicht als Fließtext in die Aufgabenbeschreibung. Dafür gibt es zwei Gründe.
Erstens die Wartung. Wenn deine Preise im Anweisungstext stehen, muss jemand beim nächsten Preisupdate den Anweisungstext editieren, ohne dabei aus Versehen die Logik zu zerschießen. Liegt die Preisliste als Datei daneben, tauschst du die Datei. Fertig.
Zweitens die Zuverlässigkeit. Nelson F. Liu und Kolleginnen und Kollegen von Stanford, Berkeley und Samaya AI haben in „Lost in the Middle” (veröffentlicht in den Transactions of the ACL, Band 12, 2024) gezeigt, dass Sprachmodelle Informationen am Anfang und am Ende eines langen Kontexts deutlich zuverlässiger verwerten als Informationen in der Mitte. Die Leistung sackt messbar ab, wenn die relevante Stelle in der Mitte liegt, und das gilt auch für Modelle, die ausdrücklich für lange Kontexte gebaut wurden.
Übersetzt in deinen Alltag: Ein Anweisungsfeld, in das du zwölf Absätze Firmenwissen kippst, hat eine Mitte. Und in dieser Mitte verschwinden Dinge.
Welche Dokumente überhaupt hineingehören, welche du weglassen solltest und warum ein veraltetes Dokument schlimmer ist als gar keins, nehme ich in der Auswahl der Wissensbasis im Detail auseinander.
Baustein 3: Die Constraints
Constraints sind die Grenzen. Was der Assistent nicht sagen darf, wo er nachfragen muss, wann er abbrechen und an einen Menschen übergeben soll, welche Tonalität tabu ist.
Beispiele, wieder konstruiert: „Nenne niemals einen Rabatt. Wenn nach einem Preis gefragt wird, der nicht in der Preisliste steht, sag, dass du das nicht beziffern kannst, und biete ein Gespräch an. Verwende keine Superlative. Bei Anfragen mit Bezug auf laufende Verfahren antwortest du gar nicht, sondern markierst die Anfrage.”
Dieser Baustein wird am häufigsten übersprungen, und er ist der Grund, warum Assistenten peinlich werden. Ich habe ihm einen eigenen Artikel gewidmet: Constraints schreiben.
Warum die meisten Assistenten an derselben Stelle scheitern
Hier ist das Muster, das ich immer wieder sehe: Alles landet in „Aufgabe”.
Der Ablauf ist nachvollziehbar. Du öffnest die Konfiguration, siehst ein großes Textfeld mit der Überschrift „Anweisungen”, und fängst an zu schreiben. Erst der Job. Dann fällt dir ein, dass sie die Preise kennen muss, also schreibst du die Preise dazu. Dann fällt dir auf, dass sie nicht duzen soll, also kommt das auch rein. Nach zwanzig Minuten hast du 900 Wörter in einem Feld, und der Assistent funktioniert sogar ganz ordentlich.
Das Problem zeigt sich erst in Woche drei. Der Assistent macht einen Fehler, und du weißt nicht, welcher Teil deines Textblocks dafür verantwortlich ist. Also fügst du eine Zeile hinzu, die den Fehler verbietet. Nächste Woche der nächste Fehler, nächste Zeile. Nach zwei Monaten ist dein Anweisungsfeld ein Sedimentgestein aus Notfallreparaturen, und niemand traut sich mehr, etwas zu löschen.
Chroma hat 2025 in der Untersuchung „Context Rot” 18 aktuelle Modelle getestet und festgestellt, dass die Ergebnisqualität mit wachsender Eingabelänge bei allen 18 nachlässt, auch bei einfachen Abruf-Aufgaben und lange bevor das Kontextfenster voll ist. Dein aufgeblähtes Anweisungsfeld arbeitet also aktiv gegen dich.
Wenn du die drei Bausteine dagegen von Anfang an getrennt hältst, ist die Fehlersuche eine Sortierfrage. Falscher Preis? Wissensdaten. Falscher Ton? Constraints. Falsche Reihenfolge im Output? Aufgabe. Drei Schubladen, ein Griff.
In welcher Reihenfolge du die drei Bausteine baust
Die Reihenfolge klingt nach einer Detailfrage und ist keine.
Fang mit den Wissensdaten an. Der Grund liegt in ihrer Ehrlichkeit: Wenn du die Dokumente zusammensuchst, merkst du innerhalb einer halben Stunde, ob dein Wissen existiert oder ob es in Köpfen und E-Mail-Verläufen liegt. Diese Erkenntnis ist mehr wert als jede Aufgabenbeschreibung.
Dann die Aufgabe, kurz gehalten. Fünf bis zehn Zeilen reichen für den ersten Durchlauf. Widerstehe dem Impuls, jetzt schon Sonderfälle zu regeln.
Die Constraints kommen zum Schluss, aber nicht erst nach dem Launch. Schreib mindestens drei hin, bevor du den Assistenten das erste Mal jemand anderem zeigst. Die restlichen zehn wachsen aus echten Fehlern nach, und das ist der einzige Weg, auf dem sie gut werden.
Ein Detail, das dabei gerne untergeht: Die drei Bausteine sind unterschiedlich haltbar. Die Aufgabe steht meistens nach zwei Runden und ändert sich danach kaum. Die Constraints wachsen langsam, ruckartig, immer nach einem Vorfall. Die Wissensdaten veralten am schnellsten, oft ohne dass es jemand bemerkt, weil ein Preis sich geändert hat und die alte Datei noch daneben liegt. Wenn du also nur eine Sache regelmäßig prüfst, prüf die Wissensdaten.
Was die sieben Workshop-Assistenten gemeinsam hatten
Die sieben Spezifikationen aus dem Workshop kamen von Leuten mit völlig unterschiedlichen Geschäften. Trotzdem sahen die Zettel ähnlich aus: eine knappe Aufgabe, zwei bis vier genannte Dokumente, und in der Constraints-Spalte fast immer irgendeine Variante von „soll nichts erfinden” und „soll nachfragen, wenn unklar”.
Diese Übereinstimmung hat mich beeindruckt und gleichzeitig etwas anderes gezeigt: Alle sieben hatten die Struktur verstanden, und keiner der sieben Assistenten ist danach in den Alltag gekommen. Die Struktur ist die halbe Miete. Die andere Hälfte liegt im Sprung von der Test-Skill zur Alltags-Skill.
Die Trennung in der Praxis, Tool für Tool
Die Bausteine sind konzeptionell, die Werkzeuge setzen sie unterschiedlich um. In den gängigen Systemen läuft es ungefähr so: Es gibt ein Feld für Anweisungen (dort landen Aufgabe und Constraints), einen Bereich für Dateien oder Wissen (dort landen die Wissensdaten) und manchmal Einstellungen für Werkzeuge wie Websuche oder Code. Welches Tool sich für welchen Fall eignet, vergleiche ich im Tool-Vergleich für Assistenten.
Mein pragmatischer Umgang mit dem gemeinsamen Textfeld: Ich setze zwei Überschriften hinein, „AUFGABE” und „GRENZEN”, und halte darunter jeweils zusammen, was zusammengehört. Das ist unspektakulär und macht trotzdem einen spürbaren Unterschied, wenn drei Monate später jemand anders reinschaut.
Genau darum geht es beim Aufbau eines KI-Assistenten mit Firmenwissen: eine Struktur, die auch dann noch verständlich ist, wenn du sie nicht mehr im Kopf hast.
Der Einwand: „Das ist Overhead für einen Chatbot”
Berechtigt, und für einen Wegwerf-Assistenten stimmt er sogar. Wenn du etwas baust, um in einer Stunde eine Frage zu klären, dann kipp alles in ein Feld und lösch es danach.
Die Trennung zahlt sich in dem Moment aus, in dem der Assistent länger lebt als deine Erinnerung an seinen Aufbau. Das ist derselbe Gedanke, den ich in Skills statt Prompts beschrieben habe: Du sparst dir nicht die Denkarbeit, du konservierst sie in einer Form, die jemand anders lesen kann.
So gehst du vor
Nimm dir einen Zettel, quer, drei Spalten. Schreib in Spalte eins den Job in einem Satz. In Spalte zwei die Dokumente, die er dafür braucht, mit Dateinamen. In Spalte drei alles, was schiefgehen könnte, und was du stattdessen willst.
Dauert zehn Minuten. Wenn eine Spalte leer bleibt, hast du das eigentliche Ergebnis schon: Bleibt Spalte zwei leer, reicht dir mit hoher Wahrscheinlichkeit ein guter Prompt. Ob sich der Aufwand überhaupt lohnt, klärt der Artikel Wann sich ein eigener KI-Assistent lohnt. Bleibt Spalte drei leer, hast du noch nicht lange genug nachgedacht.
Welche der drei Spalten fällt dir bei deinem nächsten Assistenten am schwersten? Meine Vermutung ist Spalte drei, und zwar bei fast allen.
Wenn du vor der Frage stehst, wo in deinem Betrieb solche Bausteine überhaupt sauber vorliegen und wo das Wissen noch in Köpfen steckt, ist der KI-Readiness-Check ein brauchbarer Startpunkt. Danach wird das Ausfüllen der drei Spalten deutlich schneller.
Quellen
- Lost in the Middle: How Language Models Use Long Contexts – Liu et al., arXiv 2307.03172
- Lost in the Middle: How Language Models Use Long Contexts – Transactions of the ACL 12 (2024), MIT Press
- Lost in the Middle: How Language Models Use Long Contexts – ACL Anthology
- Lost in the Middle (PDF) – Nelson F. Liu, Stanford University
- Context Rot: How Increasing Input Tokens Impacts LLM Performance – Chroma Research, 2025
- Context Rot: Evaluating LLM Performance Degradation with Increasing Input Tokens – ZenML LLMOps Database
- Context Rot: Why LLMs Degrade as Context Grows – Morph