Vielleicht sollte der Agent das Gedächtnis nicht besitzen.

Lass nicht die Metapher deine Architektur bestimmen.

Wir nennen es einen Agenten. Also geben wir ihm Gedächtnis, Fähigkeiten, Identität und Werkzeuge.

Aber gehören diese Dinge wirklich dem Agenten, weil das System es so braucht — oder weil die menschliche Metapher diese Architektur selbstverständlich erscheinen lässt?

Diese Frage ging mir nach einem Gespräch über Agent Memory beim Mittagessen nicht mehr aus dem Kopf.

Heute habe ich am EMPOWER in Zürich José Luis Latorre getroffen.

José war so freundlich, beim Mittagessen eine Reihe schlecht formulierter Fragen von mir auszuhalten, und ich bin ihm für seine Zeit wirklich dankbar. Im Moment selbst verstand ich nur einen Teil dessen, was er beschrieb. Das Gefährliche war: Ich verstand genug, damit es mich danach nicht mehr losliess.

Also verbrachte ich den Abend mit AgentMemory for .NET, AgentEval und Neo4js NAMS Agent Skills rund um graphenbasiertes Gedächtnis und Skill-Destillation.

Was ich an Josés Arbeit so gut finde

Die einfache Version von „Agentengedächtnis“ ist Retrieval: Etwas ist früher passiert, wir speichern es, später holen wir etwas ungefähr Relevantes zurück und legen es wieder ins Kontextfenster.

Josés AgentMemory strukturiert Erfahrung als persistentes Kurzzeit-, Langzeit- und Schlussfolgerungsgedächtnis – mit Provenienz, zeitlichem Zustand, Ablösung und einer expliziten Projektionsschicht.

Seine Arbeit an AgentEval ergänzt dieses System um eine evidenzorientierte Evaluationsschicht für die Entwicklung.

Separat zeigt Neo4js NAMS-Agent-Skills-Arbeit, wie angesammeltes Gedächtnis in provenienzbasierte Skills mit menschlichem Review, Drifterkennung und Reparatur verdichtet werden kann.

Zusammen deuten diese Architekturen auf etwas Grösseres hin.

Und dann geschieht das eigentlich Interessante: Gedächtnis dient nicht mehr nur dem Erinnern.

Erfahrung
    ↓
strukturiertes Gedächtnis
    ↓
Evaluation
    ↓
Muster
    ↓
Fähigkeit
    ↓
verändertes Verhalten
    ↺

Eine einfache SKILL.md-Datei ist statischer Text. Sie sagt einer Laufzeit, wie sie sich verhalten soll, hat aber keine inhärente Beziehung zu den Ausführungen, aus denen sie entstanden ist, und kein eingebautes Konzept von Evidenz, Drift, Fehlern oder Reparatur.

Besonders interessant finde ich an NAMS Agent Skills die Verschiebung dessen, was ein Skill sein kann. Eine SKILL.md muss nicht mehr die tiefste Repräsentation einer Fähigkeit sein. Sie kann eine materialisierte Laufzeitansicht einer Fähigkeit sein, deren Grundlage, Review-Status, Drift und Reparatur tiefer im System liegen.

SKILL.md wird zur Momentaufnahme einer lebendigen Fähigkeit.

„Materialisierte Fähigkeitsansicht“ ist wohl der technisch sauberere Ausdruck. In dieser NAMS/AIP-Architektur enthält die tiefere Fähigkeit Evidenz, Provenienz, Verfahren, Evaluation, Versionierung, Drift und Reparatur. SKILL.md ist nicht zwingend die kanonische Fähigkeit. Sie ist eine materialisierte Laufzeitansicht ihres aktuell genehmigten Zustands.

AgentMemory for .NET implementiert dies heute nicht. Es ist eine der Architekturen, die zusammen mit Josés Arbeit die grössere Frage dieses Essays ausgelöst hat.

Der Umweg über DeltaDB

Hier half mir eine andere Idee zu verstehen, wonach ich suchte.

Das Team hinter Delta macht etwas konzeptionell Seltsames und Nützliches: Gemeinsamer Worktree-Zustand kann tiefer liegen als die lokale Dateisystemdarstellung, die Editoren und Compiler verwenden.

Alle Beteiligten erhalten weiterhin einen gewöhnlichen synchronisierten Checkout. VS Code bearbeitet Dateien. Node liest sie. Tests und Builds laufen damit. Nichts an der vertrauten Arbeitsschnittstelle muss verschwinden. Doch diese Dateien sind eine materialisierte Arbeitsansicht eines tieferen gemeinsamen Zustands.

Delta schafft das Dateisystem nicht ab. Es stuft es von der tiefsten Wahrheitsquelle zur Laufzeitrepräsentation zurück.

Diese Unterscheidung lässt bestehenden Werkzeugen ihre gewohnte Schnittstelle, während das kanonische Modell tiefer ins System wandert. Plötzlich sah SKILL.md für mich ähnlich aus: Die Datei bleibt für die Laufzeit wichtig, muss aber nicht der Ort sein, an dem die Fähigkeit grundsätzlich lebt.

Das Repository weist bereits in diese Richtung

Die Frage wird interessanter, weil Josés tatsächliche Architektur schon weniger agentenzentriert ist, als der Ausdruck „Agentengedächtnis“ vermuten lässt.

Framework-spezifische Oberflächen liegen um einen wiederverwendbaren Kern. Josés Implementierung trennt gespeichertes Gedächtnis, Kontextzusammenstellung und Laufzeitprojektion. Projektion ist eine explizite Architekturschicht statt einer einzigen grossen Prompt-Funktion. Owner- und Anwendungsscope sind ebenfalls als Systembelange repräsentiert, auch wenn Isolation nicht in jedem Deployment automatisch aktiviert ist.

MemoryContextAssembler
        ↓
MemoryContextProjector
        ↓
MemoryContext.Projection
        ↓
ProjectionRenderer

Diese Trennung existiert heute für die Gedächtnisprojektion. Dasselbe Muster auf gemeinsame Fähigkeiten, Rückschreiben und gesteuertes Systemlernen auszudehnen, ist meine Extrapolation.

Meine Frage lautet also nicht: „Warum hast du es so gebaut?“ Ein grosser Teil der Mechanik ist bereits da. Die Laufzeitintegration ist auf den Agentenlebenszyklus ausgerichtet, doch die zugrunde liegende Architektur sieht zunehmend wie ein wiederverwendbares Substrat aus.

Was passiert, wenn wir die Projektionsidee einen Schritt weiterdenken: vom Projizieren von Gedächtnis in eine Laufzeit zum Projizieren einer breiteren gemeinsamen Fähigkeit in unterschiedliche Akteure, Schnittstellen und menschliche Ansichten – während Ausführungen gesteuerte Änderungen zurück vorschlagen können?

Projektion ist nur die halbe Geschichte

Bei der Delta-Analogie geht es nicht nur darum, eine materialisierte Ansicht zu lesen. Eine Entwicklerin bearbeitet den Checkout, und Änderungen können in den tieferen gemeinsamen Zustand zurückfliessen.

Dieser Rückweg ist für adaptive KI-Architektur wichtig. Ein Akteur kann mit einer Laufzeitprojektion arbeiten und Evidenz erzeugen, ohne die kanonische Fähigkeit direkt verändern zu dürfen.

A. Flüchtig

Ein Akteur verändert oder lernt lokal etwas. Nichts bleibt bestehen. Die nächste Materialisierung löscht es.

Projektion
    ↓
Akteur
    ↓
Notizblock
    ↓
verschwunden

B. Vorschlag

Das ist die interessanteste Stufe. Der Akteur entdeckt einen Werkzeugfehler, ein besseres Verfahren, einen Widerspruch, eine fehlende Bedingung oder eine lokale Ausnahme. Er schreibt nicht direkt fest.

Erfahrung
    ↓
Vorschlag
    ↓
Evaluation
    ↓
übernehmen / ablehnen
    ↓
kanonische Fähigkeit

Hier wurde AgentEval für mein Gedankenexperiment wichtig. José verwendet es heute als Evaluationsschicht für die Entwicklung, nicht als Promotion-Gate in der Produktion. Doch dieselbe evidenzorientierte Denkweise legt eine mögliche Architektur nahe: Eine Ausführung erzeugt einen Vorschlag, die Evaluation testet ihn, und erst danach kann eine Änderung zur gemeinsamen Fähigkeit werden. Der obige Kreislauf ist eine vorgeschlagene Architektur, nicht das heutige Laufzeitverhalten von AgentEval.

C. Gesteuerte Freigabe

In regulierten Umgebungen reicht Evaluation womöglich nicht aus. Eine Kandidatenfähigkeit kann eine menschliche oder richtlinienbasierte Genehmigung brauchen, bevor sie zum gemeinsamen Zustand wird.

Vorgeschlagene Systemarchitektur – kein heutiges Verhalten von AgentMemory oder AgentEval.

Kandidatenfähigkeit
    ↓
Evaluation
    ↓
menschliche / richtlinienbasierte Genehmigung
    ↓
genehmigte Fähigkeit
    ↓
neue Laufzeitprojektionen

Warum Rückschreiben wichtig ist

Erfassen am Ort der Entdeckung

Der Akteur ist anwesend, wenn ein Fehler passiert. Ohne Rückweg muss ein Mensch die Entdeckung bemerken, verstehen und später in ein anderes System übertragen. Zwischen diesen Schritten geht viel Signal verloren.

Negatives Wissen

Systeme erzeugen enorme Mengen an Evidenz darüber, was nicht funktioniert hat. Runbooks enthalten sie selten. Organisationen lernen immer wieder neu, dass ein Werkzeug unter einer bestimmten Bedingung versagt.

Provenienz

Eine Fähigkeitsänderung sollte auf die Ausführungen zurückverweisen, die sie motiviert haben. Sonst können wir nicht beantworten: Warum existiert diese Anweisung? Gilt die Evidenz noch?

Reparaturgeschwindigkeit

Eine Richtlinie ändert sich. Fünf kopierte Anweisungen veralten. Vorschlag, Evaluation und Promotion können eine kanonische Fähigkeit aktualisieren; die Projektionen werden von dort erneuert.

Lokale Varianten ohne Fork

Eine Abweichung kann zusammen mit der Bedingung gespeichert werden, unter der sie gilt. Nicht jede lokale Ausnahme muss zu einem separat kopierten Skill werden.

Was, wenn der Kontext selbst virtualisiert wird?

Statt zu sagen, der Agent habe Gedächtnis, Skills und Werkzeuge, könnten wir sagen: Das System materialisiert für diese Ausführung eine Laufzeitwelt.

Der Agent erlebt diese Laufzeitwelt als seinen Kontext.

Aus der Ausführung heraus mag es wie „mein Gedächtnis, meine Werkzeuge, meine Skills, mein Kontext“ aussehen. Architektonisch können dies Projektionen eines tieferen Systemzustands sein. Zurück fliesst keine ungeprüfte Umschreibung dieses Zustands, sondern Evidenz und Vorschläge für eine gesteuerte Übernahme.

Vom akteurslokalen Lernen zum Systemlernen

Josés Gedächtnis- und Evaluationsarbeit liess mich einen akteursbezogenen Kreislauf wie diesen vorstellen:

Akteur
    ↓
Erfahrung
    ↓
Gedächtnis
    ↓
Evaluation
    ↓
verbesserte Fähigkeit
    ↺

AgentEval wird heute vor allem als Evaluationskreislauf in der Entwicklung eingesetzt. Der Schritt von dort zum kontinuierlichen Systemlernen ist die architektonische Spekulation, die ich hier mache.

Eine Ebene höher skaliert der Kreislauf anders:

Akteur
↓
Erfahrung
↓
Gedächtnis
↓
Evaluation
↓
Verbesserte Fähigkeit
↺

Erfahrungen aller Akteure
↓
Gemeinsame Evaluation
↓
Gemeinsames Fähigkeitssubstrat
↓
Begrenzte Projektionen
↓
Akteur A / B / C
↺

Wenn Akteur A entdeckt, dass ein Werkzeug unter einer bestimmten Bedingung unzuverlässig ist, sollte Akteur B das nicht unabhängig neu entdecken müssen. Wenn ein Workflow wiederholt scheitert, weil sich eine Richtlinie geändert hat, sollte nicht jede Assistenz ihre eigene veraltete Version tragen, bis jemand sie repariert.

Vielleicht besteht der Skalierungsschritt nicht in mehr Agenten. Vielleicht besteht er darin, Lernen aus dem lokalen Gedächtnis eines Akteurs in gemeinsames Systemlernen zu verschieben.

Drei Dinge, die das schwierig machen

Systemlernen braucht eine Definition des Guten. Organisationen sind darin oft viel weniger explizit, als Softwarearchitekturen annehmen.

Ist das nicht einfach wieder RAG?

RAG ist primär eine Lesezeitarchitektur.

Dokumente
↓
Abruf
↓
LLM
↓
Antwort

Fähigkeit
↓
Projektion
↓
Ausführung
↓
Evidenz
↓
Vorschlag
↓
Evaluation
↓
Fähigkeit
↺

RAG kann weiterhin Teil des Substrats sein. Das ist kein „besseres RAG“. Der Unterschied ist der geschlossene Lernkreislauf.

RAG externalisiert Wissen. Die interessante Veränderung beginnt, wenn Ausführung gesteuerte Änderungen ins System zurückbringen kann.

Die einfache Version des Schritts: Basel

Für Berechnungen in meinem Basler Raumgraphen akzeptiere ich diese Architektur bereits: Das LLM soll keine Routen, Reisezeiten oder ÖV-Beziehungen schätzen. Das deterministische räumliche und zeitliche System besitzt diese Antworten. Das Modell extrahiert Absicht und Einschränkungen und erklärt danach ein berechnetes Resultat.

Zusammen liessen mich diese Architekturen fragen, ob derselbe Schritt für gelerntes Verhalten gilt: nicht nur Wahrheit aus dem Modell, sondern Fähigkeit und Lernen aus dem Akteur zu verschieben.

Schluss mit sechs Wahrheiten

Organisationen kopieren einen realen Prozess routinemässig in Wiki, Runbook, Checkliste, Schulung, KI-Anweisungen und Workflow-Konfiguration. Jede Repräsentation wird zu einer separat gepflegten Wahrheit. Jede driftet.

EIN PROZESS
    ↓
Wiki · Runbook · Checkliste · Schulung · KI-Anweisungen · Workflow-Konfiguration
    ↓
sechs gepflegte Wahrheiten
    ↓
Drift

Was, wenn das nicht sechs gepflegte Wahrheiten sind, sondern sechs Projektionen einer gesteuerten Fähigkeit?

Schluss mit sechs Wahrheiten.

Wo könnte das tatsächlich relevant sein?

Das Modell wird dort interessant, wo eine veränderliche Fähigkeit vielen Konsumenten, Rollen oder Laufzeiten dienen muss. Nicht jeder Chatbot braucht das. Ein einfaches Frage-Antwort-System für Dokumente wahrscheinlich nicht.

gemeinsame Incident-Fähigkeit
→ Bereitschaftsdienst
→ Einsatzleitung
→ KI-Laufzeit
→ Audit / Schulung

Richtlinie + Verfahren + Provenienz + Evaluation
→ Analyse
→ Review
→ Compliance
→ Audit-Evidenz

ein lebendiger Prozess
→ Checkliste
→ HR-Workflow
→ Onboarding
→ KI-Unterstützung
→ Governance

Deployment-Substrat
→ SKILL.md
→ Dokumentation
→ CI-Validierung
→ Codex / Copilot
→ visueller Workflow

alle Supporterfahrungen
→ Evaluation
→ gemeinsame Lösungsfähigkeit
→ Kundenassistenz
→ Frontline-Support
→ Spezialisten / QA

genehmigte Werkzeuge + Richtlinien + Datenklassifizierung
+ Workflows + Vorfälle + Evaluation
→ HR-Assistenz
→ Forschungsassistenz
→ M365-Assistenz
→ Mitarbeitendenhilfe
→ Governance

Die Eigentumsfrage

Aus der Laufzeit heraus:

Ich erinnere mich.
Ich habe diese Skills.
Ich kann diese Werkzeuge verwenden.

Von aussen:

Das System hat relevanten Zustand,
Fähigkeiten und Werkzeuge
in diesen Ausführungskontext projiziert.

Vielleicht sind Agentengedächtnis und adaptive System-Middleware dieselbe Architektur, von entgegengesetzten Seiten der Laufzeitgrenze betrachtet.

Die Frage, die ich José stellen möchte, ist nun die kurze:

Ich möchte keine intelligenten kleinen Menschen bauen, an denen Software hängt. Ich möchte gute Softwaresysteme bauen, in denen probabilistisches Schlussfolgern eine Fähigkeit unter anderen ist.

Ausgangspunkte

• José Luis Latorre — LinkedIn
• AgentMemory for .NET — GitHub
• AgentEval — GitHub
• Neo4j NAMS / Agent Skills
• Delta