Das Konzept

Die Illusion der Intelligenten Software

Der derzeitige Industriestandard für KI-Agenten ist oft enttäuschend: Wir bauen Systeme, die unter totaler Amnesie leiden. Wenn dein Agent heute einen SQL-Fehler macht und du ihn manuell korrigierst, wird er denselben Fehler nächste Woche wieder machen, es sei denn, du aktualisierst den System-Prompt. Das ist kaum als Intelligenz zu bezeichnen. Das ist oft nur glorifizierte Automatisierung.

Ich vertrete die Ansicht, dass Code eine Verbindlichkeit (Liability) ist. Je mehr Regeln ich hartcodieren muss, desto starrer wird das System. Mein Ansatz ist anders: Ich entwerfe Anti-Fragile Software.

Wenn meine Software abstürzt, soll sie nicht nur neu starten. Sie soll klüger zurückkommen. Sie soll verstehen, warum sie abgestürzt ist, und sicherstellen, dass dieser spezifische Fehler nahezu unmöglich zu wiederholen ist – ohne dass ich auch nur eine Zeile Code anfassen muss.

Das Konzept nenne ich Recursive Memory.

Das Szenario: Der SQL-Absturz

Lass uns ein konkretes Szenario aus meiner Arbeit mit der Supabase-Infrastruktur nehmen.

1. Ein Agent soll komplexe Benutzerdaten abrufen.
2. Der Agent entscheidet sich, eine CTE (Common Table Expression) zu nutzen, um die Abfrage zu strukturieren.
3. Die Umgebung (Supabase Edge Function) wirft einen Fehler: Security Exception: Recursive CTEs not allowed in this context.

Der normale Entwickler-Zyklus: Der Entwickler liest die Logs, ärgert sich kurz über die Datenbank-Restrictions, passt den System-Prompt an ("Benutze keine CTEs") und deployt neu. Zeitaufwand: 30 Minuten.

Mein Ansatz (Der Agentic Workflow): Der Agent fängt den Fehler ab. Er analysiert die Fehlermeldung. Er schreibt die Lösung um (Subquery). Und dann – das ist der entscheidende Schritt – nutzt er ein Tool namens add_learned_lesson, um sein eigenes "Gedächtnis" zu aktualisieren. Er schreibt "Do not use CTEs for User-Queries" in seine agent_memory.md.

Beim nächsten Run liest er diese Datei bevor er Code generiert. Er vermeidet den Fehler proaktiv.

Der Code

Die Implementierung: Lean Architecture

Viele Entwickler greifen an dieser Stelle reflexartig zu einer Vektor-Datenbank (Pinecone, Weaviate). Das ist oft unnötiger Overhead ("Enterprise Bloat"). Für Meta-Regeln ("Benutze keine CTEs") brauchen wir keine Embeddings. Wir brauchen Text.

Warum? Weil Text debugbar ist. Ich kann agent_memory.md öffnen und sehen, was mein Agent gelernt hat. Ich kann falsche Annahmen löschen.

Hier ist der Code für das Tool, das ich in meinen Orchestrierungs-Layer injiziere. Es ist im besten Sinne einfach gehalten.

(CAG - Code Augmented Generation): Ich zeige hier nicht den ganzen Boilerplate, sondern nur die entscheidende Logik, die das Gedächtnis physisch schreibt.

Das Urteil

Das Ergebnis: Zinseszins für Intelligenz

Was wir hier gebaut haben, verändert die fundamentalen Regeln der Softwareentwicklung. Normalerweise unterliegt Software dem "Bit Rot" – sie veraltet, wird langsamer und fehleranfälliger.

Mit Recursive Memory kehren wir diesen Prozess um. Jeder Fehler macht das System robuster. Wenn der Agent heute 10 Mal abstürzt, hat er morgen 10 neue Regeln gelernt, die ihn vor diesen Abstürzen schützen. Sein "IQ" wächst mit der Nutzung, ohne mein Zutun.

Das ist der Unterschied zwischen einem simplen Automatisierungsskript und einem echten digitalen Mitarbeiter.

Mein Ansatz: Statt statische Chatbots zu bauen, die auf perfekten Prompts basieren, sollten wir Systeme entwickeln, die ihre eigenen Prompts schreiben. Prompts sind fragil – lernfähige Systeme sind robust.

Wenn du sehen willst, wie ich das in einem kompletten Framework umgesetzt habe, schau dir mein Agentic Orchestration Layer Model auf GitHub an (siehe Dominien). Dort findest du die vollständige Architektur, nicht nur Snippets.

Das Fazit

Code, der nicht lernt, ist schnell veraltet. Ich entwerfe Systeme, die darauf ausgelegt sind, manuelle Eingriffe überflüssig zu machen. Das ist der nachhaltige Weg zur Skalierung.

Baue keine Tools. Baue Teammitglieder.