KI-Entwicklung braucht ein Gedächtnis — sonst zahlen Sie es in Token

Die Diskussion über KI in der Entwicklung dreht sich seit zwei Jahren um die falsche Frage. Ob ein Modell guten Code schreibt, ist längst entschieden — es schreibt guten Code. Die Frage, an der Projekte scheitern, lautet anders: Woher weiß der Agent, was Ihr System tut?

In einer SAP-Landschaft ist das keine akademische Frage. Ein Feature hat eine Sonderlogik, weil vor sechs Jahren ein Werk dazukam. Ein Z-Programm existiert, weil ein Standardprozess nicht passte. Ein Prozess läuft in drei Buchungskreisen unterschiedlich. Nichts davon steht im Code, und wenn es irgendwo steht, dann in einem Ticket, das niemand mehr findet.

Wo die Token wirklich hingehen

Sehen Sie sich eine beliebige Agenten-Sitzung an. Der Anteil, der tatsächlich Code schreibt, ist klein. Der Löwenanteil geht für etwas anderes drauf: Verzeichnisse auflisten, Dateien öffnen, Suchtreffer lesen, wieder verwerfen, tiefer graben. Der Agent baut sich sein Weltbild aus dem, was er zufällig findet — und hört auf, wenn er glaubt, genug zu haben.

Das hat drei Kostenstellen, und nur eine davon steht auf der Rechnung.

Erstens die direkten Kosten. Ein Kontextfenster voller Suchtreffer kostet bei jedem weiteren Schritt erneut, weil es mitgeschleppt wird. Wer Agenten in der Breite einsetzt, merkt das an der Monatsrechnung, bevor er es an der Geschwindigkeit merkt.

Zweitens die Qualität. Ein Modell, das sich seinen Kontext zusammensucht, arbeitet mit dem, was oben lag. Der zweitbeste Treffer sieht plausibel aus, und die Antwort, die darauf steht, sieht ebenfalls plausibel aus. Genau das ist das Problem: Falscher Kontext erzeugt keine Fehlermeldung, sondern eine gut formulierte falsche Aussage.

Drittens die Wiederholbarkeit. Was eine Sitzung mühsam erarbeitet hat, bleibt in dieser Sitzung. Der nächste Agent — oder derselbe morgen früh — fängt wieder bei null an und zahlt den Suchaufwand ein zweites Mal.

Das eigentliche Problem ist nicht das Modell

Es ist die Ablage. Systemwissen liegt heute an drei Orten, und keiner davon ist für eine Maschine gebaut:

• Im Kopf. Der Kollege, der weiß, warum die Kreditlimitprüfung so aussieht, wie sie aussieht. Nicht abfragbar, oft nicht mehr im Haus.
• In Fließtext. Confluence, SharePoint, ein PDF von 2021. Ein Agent kann es lesen und nicht bewerten — er sieht nicht, ob es noch stimmt.
• Im System selbst. Tabellen, Code, Customizing. Vollständig und wahr, aber ohne fachliche Bedeutung. Dass ZSD_CREDIT_CHECK existiert, sagt nichts darüber, wofür.

RAG über die Confluence-Ablage löst das nicht, sondern verstärkt es: Der Agent bekommt jetzt veraltete Prosa mit hoher Ähnlichkeitsbewertung. Das Vertrauensproblem wird nicht kleiner, es wird nur schneller.

Was ein Werkzeug dafür leisten muss

Wenn Sie KI-Entwicklung ernsthaft organisieren wollen, braucht der Agent eine Quelle mit fünf Eigenschaften. Weniger reicht nicht.

1. Strukturiert abfragbar statt durchsuchbar. Nicht „finde Dokumente über Kreditmanagement”, sondern „welche Capability ist das, welche Features hängen daran, welche Eigenentwicklungen überbauen sie, was ist offen”. Eine Frage, eine Antwort, kein Ranking.

2. Aktuell, weil sie mitläuft. Die technische Ebene muss sich aus dem System fortschreiben — welche Features es gibt, was genutzt wird, welcher Code existiert. Alles, was von Hand gepflegt wird, ist am zweiten Tag falsch.

3. Beschreibbar. Das ist der Teil, den die meisten Ansätze auslassen. Was während der Umsetzung über ein Feature klar wurde, muss danach am Feature stehen — geschrieben aus dem Kontext heraus, in dem die Arbeit passiert ist, nicht drei Tage später aus dem Gedächtnis. Sonst hebt man die Effizienz einmal und verliert sie über die Zeit wieder.

4. Geteilt. Eine Wissensquelle, die nur ein Entwickler sieht, ist ein Notizbuch. Was der eine Agent gestern herausgefunden hat, muss der Agent des Kollegen heute vorfinden — sonst finden zehn Leute zehnmal dasselbe heraus und nichts davon summiert sich. Der Wert entsteht erst durch die gemeinsame Fläche: eine Stelle, auf die alle zeigen, und die zwischen zwei Sitzungen nicht vergisst.

5. Begrenzt. Ein Zugang, über den ein Modell Systemwissen liest, ist eine Entscheidung des Unternehmens, keine Installationsentscheidung des Entwicklers. Wer darf was sehen, für welchen Mandanten, und darf Quelltext überhaupt herausgehen? Diese Fragen gehören an den Zugang selbst — nicht in eine Richtlinie, die auf einem fremden Rechner niemand durchsetzt.

Und wenn der Agent doch am System hängt?

Viele Häuser hängen ihren Agenten direkt ans SAP-System — über ADT, über eine eigene MCP-Anbindung, über ein Skript. Das ist eine Entscheidung, die jedes Unternehmen für sich trifft, und es gibt gute Gründe dafür. Was dabei aber gern verwechselt wird: Der Live-Zugriff gibt dem Agenten Reichweite, keine Orientierung.

Er kann jetzt alles lesen. Also liest er alles. Ein Modell, das auf zehntausende Tabellen und zehntausende Objekte losgelassen wird, hat keine Landkarte bekommen, sondern ein größeres Labyrinth — und das Suchproblem von oben wird nicht kleiner, sondern teurer. Dass ZSD_CREDIT_CHECK existiert, kann er jetzt selbst herausfinden. Wofür es existiert, weiterhin nicht.

Die beiden Dinge sind deshalb keine Alternativen, sondern zwei verschiedene Aufgaben. Ein Client kann mehrere Quellen gleichzeitig ansprechen: die eine für den Zugriff auf das System, die andere für die Frage, was das Gesehene bedeutet. Wer beides hat, gewinnt an beiden Enden.

Für die Wissensquelle gilt allerdings weiterhin, was für jede Analyse auf Ihren Daten gilt: Conjola arbeitet ausschließlich auf Extrakten — kein Live-Zugriff, kein Rückkanal, definierter Scope. Warum diese Trennung bei der Analyse selbst nicht verhandelbar ist, steht in Attached vs. Detached.

Wie das bei Conjola aussieht

Conjola hält genau diese Quelle: eine Feature Map aus implementierten und genutzten Funktionen, die Eigenentwicklungen mit fachlichem Kontext, die Prozesse aus echten Belegflüssen und eine Wissensbasis, in der die Fachkonzepte neben den Daten liegen, über die sie handeln.

Über den MCP-Zugang fragt Ihr Coding-Agent das direkt ab — und schreibt Hinweise, Antworten und Status dorthin zurück. Der Mandant hängt fest am Token, lesend ist die Vorbelegung, freigeschaltet wird auf Mandantenebene, und ob Ihr Kundencoding herausgehen darf, ist ein eigener Schalter.

Der Effekt ist unspektakulär und genau der, den man will: Der Agent sucht nicht mehr, er fragt. Und was er dabei lernt, ist morgen noch da.