Ihre KI-Agenten scheitern, weil Sie sie nie eingearbeitet haben
Jedes Unternehmen hat einen Onboarding-Prozess für neue Entwickler. Dokumentation, Architekturrundgänge, Coding-Standards, Fachwissen. Selbst eine erfahrene Entwicklerin braucht Wochen, bis sie Ihr System versteht und etwas Brauchbares liefert. Programmieren kann sie längst.
Für Agenten macht das niemand. Die bekommen einen Prompt und ein Stoßgebet.
Deshalb driften die meisten Agenten ab, halluzinieren und produzieren Code, der in den Müll wandert. Das Modell war nie der Engpass. Der Kontext war es.
Die teure Lektion
Eine Analyse von GitClear über 211 Millionen Codezeilen zeigt: Je weiter sich KI-Assistenten verbreiteten, desto mehr brachen die Qualitätskennzahlen ein. Und zwar auf breiter Front.
Refactoring ging um 60 % zurück. Kopierter Code nahm um 48 % zu. Der Churn stieg. Mehr Code, weniger Verständnis.
Die Forschung von Anthropic bestätigt das Muster von der anderen Seite. Sie verweist auf Context Rot: Je voller das Kontextfenster, desto schlechter erinnert sich ein Modell an das, was darin steht. Agenten mit langen Aufgaben trifft das zuerst. Abhilfe schufen nicht bessere Modelle, sondern strukturierter Kontext. Verdichtung, Notizen und eine passende Architektur steuern, was ins Kontextfenster gelangt.
Die Branche wartet reflexhaft auf klügere Modelle. Die Belege sagen etwas anderes: Die Lösung gibt es längst. Mit Intelligenz hat sie nichts zu tun.
Prompt Engineering oder Context Engineering
Prompt Engineering bringt Ihnen bei, bessere Fragen zu stellen. Context Engineering bringt Ihnen bei, eine bessere Umgebung zu bauen.
Der Unterschied ist entscheidend. Ein perfekter Prompt in einem kaputten Kontext liefert trotzdem Müll. Ein mittelmäßiger Prompt in reichhaltigem, gut strukturiertem Kontext liefert Brauchbares. Und zwar verlässlich, Sitzung für Sitzung.
Context Engineering legt fest, welche Information das Modell wann und in welcher Struktur erreicht. Dazu gehören drei Ebenen: was ins Fenster kommt (Auswahl), wie es geordnet ist (Architektur) und wann es erneuert wird (Lebenszyklus). Die meisten denken nur an die erste Ebene. Sie kippen alles in den Prompt und wundern sich, dass das Modell halluziniert.
Das Team von Martin Fowler, Anthropic und die ICLR 2026 sind unabhängig voneinander beim selben Begriff gelandet. Neu ist die Disziplin nicht. Neu ist die Einsicht, dass sie über Erfolg und Scheitern entscheidet. Mit ihr werden Agenten von Sitzung zu Sitzung besser. Ohne sie fallen sie in sich zusammen.
Vier Arten, wie Onboarding scheitert
Jedes Scheitern eines Agenten, das ich erlebt habe, geht auf eines von vier Kontextproblemen zurück. Es sind Onboarding-Fehler unter anderem Namen.
Verschmutzter Kontext. Halluzinierte oder veraltete Information gelangt ins Fenster und pflanzt sich fort. Das Modell vertraut seinem Kontext. Stehen dort falsche Daten, erbt alles Weitere den Fehler.
Ein neuer Kollege wird mit einer Dokumentation eingearbeitet, die zuletzt vor zwei Jahren aktualisiert wurde.
Abgelenkter Kontext. Zu viel Irrelevantes übertönt das Relevante. Ein Fenster mit 200.000 Tokens hilft nicht, wenn 180.000 davon Rauschen sind. Das Modell gewichtet alles im Fenster ungefähr gleich.
Sie drücken einer neuen Entwicklerin den kompletten Confluence-Bereich in die Hand: „Lesen Sie das erst mal alles.“
Verwirrter Kontext. Zu viele Werkzeuge, zu viele widersprüchliche Anweisungen. Bei fünfzig Tool-Definitionen im System-Prompt verschwendet das Modell Aufmerksamkeit auf Fähigkeiten, die es für die aktuelle Aufgabe nicht braucht.
Die Onboarding-Präsentation erklärt die Abläufe jedes Teams, nur nicht den einen, auf den es ankommt.
Widersprüchlicher Kontext. Im selben Fenster steht Gegensätzliches. Die Projektanweisungen sagen „nimm pnpm“, die README sagt „nimm npm“. Der Agent wählt zufällig. Oder schlimmer: Er wechselt von Sitzung zu Sitzung.
Zwei erfahrene Kollegen geben dem Neuen am ersten Tag entgegengesetzte Ratschläge.
Für alle vier gilt dieselbe Lösung: nicht abkippen, sondern kuratieren.
Wie das Onboarding von Agenten wirklich aussieht
Ein aktuelles Paper auf arXiv dokumentiert, wie ein einzelner Entwickler mit Agenten ein System mit 108.000 Zeilen baut. Der festgeschriebene Kontext wuchs dabei auf rund 26.000 Zeilen an. Mehr als die Hälfte jeder Agentenspezifikation war Projektwissen und nicht Anweisung.
Bei Interlusion hat jedes Projekt eine Kontextarchitektur, die das Onboarding von Agenten als Infrastruktur behandelt:
Lehrtexte statt Konfigurationsdateien. Die Projektanweisungen lesen sich wie Onboarding-Unterlagen für eine erfahrene Entwicklerin, die programmieren kann, aber die Codebasis nicht kennt. Sie erklären Architektur, Muster, Rahmenbedingungen und die Gründe hinter Entscheidungen. Also nicht nur die Regeln, sondern auch, warum es sie gibt.
Schrittweise Offenlegung. Nicht alles muss gleichzeitig im Fenster stehen. Ein Leitdokument mit weniger als 200 Zeilen verweist auf ausführliche Themendateien: Muster, Entscheidungen, Notizen zur Fehlersuche. Der Agent lädt nur, was die aktuelle Aufgabe verlangt. Nicht alles, was je geschrieben wurde.
Trennung der Zuständigkeiten. Architekturkontext an einer Stelle, Coding-Konventionen an einer zweiten, Fachwissen an einer dritten. Der Agent lädt die Ebene, die er braucht. So organisieren auch menschliche Teams ihr Wissen. Wer gerade eine Datenbankmigration repariert, bekommt nicht die Doku des Design-Systems.
Laufende Pflege. Der Agent pflegt seinen Kontext bei der Arbeit nebenbei mit. Stößt er auf ein neues Muster, löst er ein wiederkehrendes Problem oder entdeckt er eine Einschränkung, wird dieses Wissen festgehalten. Die Kontextarchitektur wird mit jeder Sitzung besser, statt sich weiter von der Wirklichkeit zu entfernen.
Das Muster ist eindeutig: mehr Kontextarchitektur, weniger Anweisungen. Gestalten Sie die Umgebung. Der Agent lernt durch Lesen, nicht durch Befehle.
Die eigentliche Disziplin
Die Unternehmen, die mit KI scheitern, werden nicht die schlechtesten Modelle haben. Modelle werden rasant zur Massenware. Sie werden den schlechtesten Kontext haben: unstrukturiertes Wissen, widersprüchliche Anweisungen und Agenten, die jede Sitzung bei null beginnen.
Erfolgreich werden die Unternehmen sein, die Kontext wie Infrastruktur behandeln. Gepflegt, versioniert, getestet. Mit derselben Sorgfalt entworfen wie die Systeme, die ihre Agenten bauen.
Prompt Engineering hieß, bessere E-Mails zu schreiben. Context Engineering heißt, das Büro zu bauen, in dem der Agent arbeitet.
Die Frage ist nicht, ob Ihre KI klug genug ist. Die Frage ist, ob Sie ihr eine Welt gegeben haben, über die nachzudenken sich lohnt.
Sie wollen eine Kontextarchitektur, mit der Ihre Agenten besser werden, statt abzudriften? Sprechen wir darüber.