Warum KI-Assistenten im Unternehmen an Kontext scheitern

Die vier vorherigen Beiträge beschreiben vier verschiedene Assistenten: erstellen, transformieren, prüfen, lokalisieren. Beim Zurücklesen ist mir aufgefallen, dass alle vier mit derselben Einschränkung enden. Der Transformer ist nur so gut wie das, was angebunden ist. Der Kritiker kann Duplikate ohne vollen Bestandskontext grundsätzlich nicht finden. Der Spurenleser steht und fällt mit Logs und Traces. Der Ersteller muss Annahmen ausweisen, weil ihm etwas fehlt.

Vier Beiträge, ein Befund. Dieser Beitrag handelt davon, wie ich das fehlende Wissen zum Modell bringe — zuerst von Hand, später über MCP — und warum das Anbinden allein nicht reicht.

Das Symptom sieht aus wie ein Prompt-Problem

Der Verlauf war jedes Mal derselbe. Ein Assistent liefert ein Ergebnis, das ordentlich aussieht: alle Felder gefüllt, saubere Sprache, richtige Struktur. Man liest es, nickt — und stolpert erst später darüber, dass es die falsche Frage beantwortet hat.

Denn die Fragen, an denen im Unternehmen ein Ergebnis hängt, richten sich nicht an den Text, sondern an den Bestand:

• Widerspricht diese Anforderung einer bestehenden Funktion?
• Erweitert sie eine — und welche?
• Gibt es sie vielleicht schon?

Keine dieser drei Fragen ist aus dem vorliegenden Artefakt zu beantworten. Und der Reflex, wenn die Antwort nicht stimmt, ist trotzdem: am Prompt arbeiten.

Ich habe das eine Weile getan. Die Ergebnisse wurden dabei tatsächlich besser — präziser formuliert, vollständiger, konsistenter im Aufbau. Nur an genau den drei Fragen änderte sich nichts, und im Rückblick ist klar, warum:

Prompt-Arbeit verbessert Formulierung und Form. Sie kann kein Wissen ersetzen, das nicht im Raum ist.

Das Unangenehme daran ist, wie das Modell mit der Lücke umgeht. Es sagt nicht „das weiß ich nicht". Es füllt sie mit etwas Plausiblem. Und Plausibles ist in einer Anforderung ununterscheidbar von Richtigem — genau der Punkt, an dem beim Ersteller die Pflicht steht, Annahmen auszuweisen, und beim Transformer die Pflicht, jede angereicherte Aussage mit ihrer Herkunft zu versehen.

Wissen, das das Modell nicht haben konnte

Parallel zum Baukasten, ziemlich am Anfang seiner Entwicklung, habe ich ein Framework auf eine neue Version umgestellt. Eine völlig andere Aufgabe: kein Produktprozess, keine Anforderungen, sondern Code.

Und dort stand ich vor derselben Lücke, nur aus einer anderen Richtung. Das Modell kannte das Framework — aber nicht die Version, auf die ich wechseln wollte. Sie war jünger als sein Trainingsstand: keine Release Notes, keine Migrationsguides, keine bekannten Probleme. Ein Modell ohne diese Informationen kann nur vorschlagen, was zu dem Stand passt, den es kennt. Und das klingt genauso überzeugend wie das Richtige.

Der Workaround war unspektakulär. Ich habe Release Notes, Migrationsguide und die bekannten Probleme als lokale Dateien ins Projekt gelegt, für genau diesen Update-Prozess, und im Prompt darauf verwiesen — damit das Modell sie für diese Aufgabe heranzieht.

Dabei gehörten zwei Dinge zusammen: die Dateien und der Verweis darauf. Dass eine Information irgendwo im Projekt liegt, heißt noch nicht, dass der Agent sie bei der aktuellen Aufgabe liest. Der Verweis im Prompt war der Wegweiser. Das Ganze war Handarbeit — für eine Aufgabe zusammengestellt, von Hand gepflegt, beim nächsten Vorhaben wieder von vorn. Aber es hat funktioniert.

Zwei völlig verschiedene Aufgaben, zwei verschiedene Lücken:

• Öffentliches Wissen, das jünger ist als das Modell — neue Versionen, Release Notes, bekannte Probleme.
• Internes Wissen, das nie öffentlich war — der Bestand: Lösungskonzepte, bestehende Funktionen, frühere Entscheidungen.

Und dieselbe Ursache: Dem Modell fehlt etwas, das kein Prompt ersetzen kann. Das war der Punkt, an dem ich aufgehört habe, es als Eigenschaft des jeweiligen Assistenten zu behandeln, und angefangen habe, eine Frage vorzuschalten:

Verlangt eine Aufgabe Wissen, das das Modell nicht hat, ist jede Prompt-Runde vergeudete Zeit, solange dieses Wissen nicht angebunden ist.

Das klingt banal. In der Praxis ist es die Regel, die mir die meisten Nachmittage gespart hat — weil sie eine Sorte Arbeit stoppt, die sich sehr produktiv anfühlt und am eigentlichen Engpass nichts ändert.

Erweiterte Kontextinformationen — und die Frage, welche Quelle wofür

Einige Zeit später kam das Model Context Protocol auf, kurz MCP. Damit musste ich Wissen nicht mehr als Dateien für eine einzelne Aufgabe zusammentragen. Stattdessen lassen sich die Dienste sauber anbinden, in denen es ohnehin liegt: ein Ticketsystem wie Jira, eine Wissensdatenbank wie Confluence, Monitoring-Tools für Logs, Metriken und Traces. Der Kontext eines Agenten wird so um das erweitert, was das Unternehmen weiß. Wie eine solche Anbindung aussieht, habe ich in End-to-End-Entwicklung mit Agenten und MCP beschrieben. In den Baukasten sind MCP-Server erst deutlich später eingezogen.

Damit ist die Handarbeit gelöst. Die Frage nach dem Wegweiser nicht — sie wird größer. Ein Agent mit mehreren angebundenen Diensten muss bei jeder Aufgabe entscheiden, wo er nachsieht. Und jeder Server bringt seine Werkzeugbeschreibungen in den Kontext, ob sie für die Aufgabe gebraucht werden oder nicht.

Was früher der Verweis im Prompt erledigt hat, übernimmt heute die AGENTS.md. Ausgerechnet diese Datei ist inzwischen umstritten. Eine Untersuchung der ETH Zürich kam Anfang 2026 zu dem Ergebnis, dass solche Kontextdateien die Erfolgsquote von Coding-Agenten im Allgemeinen nicht verbessern, die Inferenzkosten aber im Schnitt um mehr als 20 Prozent erhöhen. Repository-Übersichten erwiesen sich dort als nicht hilfreich — Anweisungen dagegen befolgen die Agenten zuverlässig.

Im Baukasten war die AGENTS.md trotzdem nicht optional, sondern existenziell. Der Unterschied liegt in der Ausgangslage. Die Studie misst Aufgaben innerhalb eines einzelnen Repositorys — dort kann sich ein Agent durch Suchen und Lesen selbst orientieren. Im Baukasten sind mehr als hundert Repositories angebunden. Die überfliegt kein Agent mal eben, um sich einen Überblick zu verschaffen. Wer in einem Repository arbeitet, findet sich zurecht. Wer in einer Landschaft aus hundert Services arbeitet, braucht zuerst eine Karte.

Diese Karte ist die AGENTS.md — ausdrücklich keine Dokumentation, sondern eine grobe Führung. Sie beantwortet drei Fragen:

• Welcher Service ist wofür zuständig? Eine Zeile pro Service, nicht mehr.
• Welche Quelle passt zu welcher Aufgabe — und welche nicht?
• Wo liegen die Lösungskonzepte? Kommt eine Frage zur Architektur, weiß der Agent, wo er nachsehen muss.

Vereinfacht, zur Veranschaulichung:

## Landkarte

Grobe Zuständigkeiten. Details stehen im jeweiligen Repository.

- Check-Service: fachliche Validierungen und Plausibilitätsprüfungen
- Product-Service: Produktdaten, Varianten, Preise
- Payment-Service: Zahlungsarten, Abrechnung, Erstattungen
- Voucher-Service: Gutscheine, Rabattcodes, Einlösung
- …

## Welche Quelle für welche Aufgabe

- Anforderung ausarbeiten: Ticketsystem für den Vorgang und seine
  verlinkten Vorgänge, Wissensdatenbank für Lösungskonzepte und Glossar.
  Monitoring nicht heranziehen.
- Fehler analysieren: zuerst die Logs zur Fehlermeldung, dann die Traces
  der betroffenen Aufrufkette.
- Architekturfragen: in den Lösungskonzepten der Wissensdatenbank
  nachsehen.
- Ist eine benötigte Quelle nicht erreichbar: das im Ergebnis sagen,
  statt ohne sie weiterzumachen.

Entscheidend ist die Flughöhe. Die Datei beschreibt nicht, wie ein Service funktioniert, sondern nur, wofür er da ist. Den Rest findet der Agent selbst — wenn er weiß, in welchem der hundert Repositories er suchen muss. Das passt sogar zur Empfehlung derselben Studie: In eine Kontextdatei gehört nur, was über das hinausgeht, was ohnehin im Code steht. Eine Zuständigkeitskarte über hundert Repositories steht in keinem davon.

Mit der Datei waren die Ergebnisse wesentlich besser. Gemessen habe ich das nicht — dazu mehr bei den Grenzen —, aber es ist der Grund, warum ich das Studienergebnis nicht auf diesen Fall übertrage.

Dass die Datei bewusst so knapp bleibt, hat noch einen zweiten Grund. Den habe ich im Baukasten auf die unangenehme Art gelernt.

Mehr Kontext ist nicht besserer Kontext

Im Baukasten ist der Kontext in drei Stufen gewachsen, jede, weil die vorherige ihre Grenze sichtbar gemacht hat:

Stufe 1 reichte erstaunlich weit — für alles, was mit der Form zu tun hat. Stufe 2 kostete am wenigsten und brachte am meisten pro Aufwand: Ein Artefakt verweist ohnehin auf seine Nachbarn, und diese Verweise maschinell zu verfolgen ist billig. Stufe 3 ist die teure und die einzige, die die drei Fragen von oben wirklich beantwortet. An ihr bin ich zuerst gescheitert.

Problem 1: Mehr Quellen, schlechtere Ergebnisse. Als Stufe 3 stand, lag die naheliegende Konfiguration auf der Hand: Jeder Assistent bekommt Zugriff auf alles. Warum sollte man ihm etwas vorenthalten?

Das Ergebnis war schlechter als vorher. Nicht dramatisch falsch — unschärfer. Ein Assistent, der eine Anforderung formulieren sollte, zog plötzlich Passagen aus einem Betriebshandbuch heran, weil dort dieselben Begriffe vorkamen. Die Ergebnisse waren länger, vorsichtiger, allgemeiner. Und die Prüfzeit stieg, weil man jetzt bei jedem Absatz überlegen musste, woher der eigentlich stammt.

Geholfen hat, die Quellen pro Assistententyp festzulegen statt global. Der Ersteller sieht andere Quellen als der Kritiker, und der Spurenleser sieht Betriebsdaten, die in einer Anforderung nichts verloren haben. Das ist derselbe Gedanke wie bei der AGENTS.md und beim Ausgabeschema: Nicht das Modell soll entscheiden, was relevant ist, sondern der, der die Aufgabe kennt.

Das deckt sich mit etwas, das ich in der Agentic-Coding-Serie über überladene Agenten geschrieben habe: Ein längeres Kontextfenster ist kein besseres. Was mitgeschleppt wird, ohne gebraucht zu werden, ist nicht neutral — es konkurriert um Aufmerksamkeit.

Problem 2: Die Duplikatsprüfung fand Ähnlichkeit, nicht Gleichheit. Auch mit angebundenem Bestand findet der Assistent zuverlässig ähnlich formulierte Anforderungen — aber nicht zuverlässig dieselbe Anforderung in anderen Worten. Und zwei Anforderungen, die fast gleich klingen, können fachlich verschieden sein. Die Konsequenz war kein besserer Suchindex, sondern eine ehrlichere Ausgabe: Der Assistent sagt, wogegen er geprüft hat und wogegen nicht. Warum ein Prüfergebnis ohne Prüfumfang eine Entwarnung ist, die niemand einlösen kann, steht beim Kritiker.

Zum Mitnehmen

Aus beiden Fällen und dem Baukasten bleiben für mich vier Punkte:

1. Erst die Lücke benennen, dann prompten. Fehlt dem Modell Wissen — weil es jünger ist als sein Trainingsstand oder weil es nie öffentlich war —, rettet keine Prompt-Runde das Ergebnis.
2. Das Wissen dorthin bringen, wo der Agent es findet. Für eine einzelne Aufgabe reichen lokale Dateien im Projekt. Für Wissen, das laufend entsteht — Tickets, Dokumentation, Logs —, ist MCP der saubere Weg.
3. Anbinden ohne Wegweiser ist die halbe Arbeit. Der Verweis im Prompt, die AGENTS.md, die Quellen-Konfiguration im Baukasten: Es ist jedes Mal dieselbe Aufgabe — dem Agenten sagen, welche Quelle für welche Aufgabe zählt. Und der Wegweiser bleibt grob: wofür etwas zuständig ist, nicht wie es funktioniert.
4. Was nicht angebunden ist, gehört ins Ergebnis. Ein bekannter blinder Fleck, der im Ergebnis benannt wird, ist eine Information. Derselbe blinde Fleck, unerwähnt, ist eine stille Falschaussage.

Den vierten Punkt habe ich am längsten unterschätzt.

Grenzen

Berechtigungen sind Teil des Problems, nicht ein Detail danach. Ein Assistent mit Bestandszugriff erbt eine Zugriffsfrage: Wer darf welche Quelle sehen, und was passiert, wenn ein Ergebnis Wissen enthält, das der Empfänger nicht sehen dürfte? Das ist im Kleinen keine Frage und im Unternehmen die, die über den Rollout entscheidet.

Der Bestand ist nicht die Wahrheit. Angebundene Dokumentation kann veraltet sein, und ein Assistent zitiert sie dann korrekt und trotzdem falsch. Das ist kein Modellfehler — es ist derselbe Fehler, den ein neuer Kollege machen würde. Der einzige Schutz, den ich habe, ist die Herkunftsangabe: Wer die Fundstelle sieht, kann sie prüfen.

Diagramme bleiben außen vor. Lösungskonzepte tragen ihre entscheidende Information oft im Bild, und das System liest sie nicht. Warum ich mich bewusst dagegen entschieden habe, steht auf der Projektseite — kurz: Die Kostenstruktur ändert sich für jedes Dokument, nicht nur für die wenigen, bei denen es etwas bringt.

Und keine belastbare Wirkungsmessung. Was ich sagen kann, ist eine Rückmeldung: Seit der Kontext erweitert wurde, kommt von Nutzern, dass die Ergebnisse besser geworden sind — vorher kam diese Rückmeldung nicht. Das ist etwas wert und ist kein Messwert. Warum ich trotzdem keine Prozentzahl behaupte, steht in meinem Beitrag zur Wirkungsmessung.

Fazit

Der Baukasten hat mich eine Sache gelehrt, die ich vorher anders eingeschätzt hätte. Ich bin mit der Annahme gestartet, dass die schwierigen Teile die Aufgabe und das Ausgabeschema sind — also das, worüber die vier vorherigen Beiträge gehen. Beides ist wichtig, beides war Arbeit, und beides war lösbar.

Der Engpass war keins von beidem. Es war der Zugang zu Wissen, das das Modell nicht hat: zu dem, was das Unternehmen ohnehin schon weiß — und manchmal schlicht zu dem, was neuer ist als das Modell.

Das ist insofern eine gute Nachricht, als es kein KI-Problem ist. Ob eine Anforderung anschlussfähig ist, hängt davon ab, ob jemand den Bestand kennt — das galt vorher auch, nur hat es dann ein erfahrener Mensch getragen, und niemand hat es als Systemeigenschaft aufgeschrieben. Ein Assistent macht diese Abhängigkeit lediglich sichtbar, weil er sie nicht durch Erfahrung ersetzen kann.

Die Regel, die ich mitnehme, ist deshalb weniger technisch, als das Thema klingt: Bevor ich einen Assistenten besser mache, prüfe ich, ob er sehen kann, was er wissen müsste — und ob er weiß, wo er nachsehen soll. Und wo er es nicht kann, sagt er es — statt es zu ersetzen.

→ Der Baukasten im Überblick