# Vielleicht sollte der Agent das Gedächtnis nicht besitzen. _Ein Mittagessen, ein Graph-Memory-Framework, eine Karte von Basel und ein seltsamer Umweg über DeltaDB liessen mich mit einer Frage zurück: Was, wenn „Agentengedächtnis“ eigentlich der Anfang einer gemeinsamen adaptiven Systemschicht ist?_ 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](https://www.linkedin.com/in/joslat/) 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](https://github.com/joslat/agent-memory-dotnet), [AgentEval](https://github.com/AgentEvalHQ/AgentEval) und [Neo4js NAMS Agent Skills](https://neo4j.com/labs/agent-memory) rund um graphenbasiertes Gedächtnis und Skill-Destillation. > **Eine Anmerkung zur Perspektive** > > Ich bin kein tiefgehender .NET- oder Neo4j-Engineer. José arbeitet technisch mehrere Ebenen unter dem, was ich im Alltag baue. Ich entwickle Prototypen, komme an diese Fragen aber aus Veränderung, Organisationsentwicklung, Schnittstellen, Systemdenken und einer starken Präferenz dafür, probabilistische KI nur zu einem Teil eines Softwaresystems zu machen. Dies ist deshalb kein technisches Review seiner Arbeit. Es ist eine architektonische Frage, die seine Arbeit bei mir ausgelöst hat. > **Welches Problem das löst** > > Wenn ein veränderlicher Prozess in Runbooks, Checklisten, Schulungen, KI-Anweisungen und Workflows kopiert wird, pflegen Organisationen am Ende mehrere auseinanderdriftende Versionen derselben Fähigkeit. ## 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.** ```text 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. **Scheinbarer Besitz des Agenten.** Ein grosser Agent scheint Gedächtnis, Skills und Werkzeuge zu besitzen. **Strukturiertes Gedächtnis.** Gedächtnis trennt sich in kurz, lang und schlussfolgernd, mit Provenienz, zeitlichem Zustand und Ablösung. **Fähigkeit entsteht.** Erfahrung fliesst durch Evaluation in Fähigkeit. **Architektonische Umkehrung.** Das kanonische Substrat projiziert eine Laufzeitansicht in einen Akteur, der nur eine Ebene ist. **Materialisierter Skill.** SKILL.md ist eine Projektion der Fähigkeit, kein Eigentum des Agenten. **Delta-Analogie.** Tieferer Zustand wird zum materialisierten Checkout für bestehende Werkzeuge. **Kontextvirtualisierung.** Die Projektion trägt Zustand, Historie, Skills, Werkzeuge, Berechtigungen und Anweisungen. **Rückweg der Erfahrung.** Ergebnisse des Akteurs kehren als Evidenz über einen getrennten Pfad zurück. **Vorschlag statt Mutation.** Evidenz wird zum Vorschlag für Governance; der Akteur schreibt nicht direkt in den kanonischen Zustand. **Geschlossener Lernkreislauf.** Genehmigte Änderungen kehren ins kanonische Substrat zurück. **Systemlernen.** Akteure A, B und C erhalten begrenzte Projektionen der gemeinsamen Fähigkeit. **Viele Projektionen.** Eine gesteuerte Fähigkeit wird zu Wiki, Runbook, Checkliste, Training, KI-Skill und Workflow. „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. **01 · Lebendige Fähigkeit** Eine gesteuerte Fähigkeit mit Evidenz und Provenienz wird in Laufzeit- und Review-Ansichten materialisiert. ```text Lebendige Fähigkeit Evidenz · Provenienz · Verfahren · Evaluation · Versionen · Drift · Reparatur ↓ Materialisierte Ansichten SKILL.md · ausführbarer Graph · Review-Oberfläche · API ``` ## Der Umweg über DeltaDB Hier half mir eine andere Idee zu verstehen, wonach ich suchte. Das Team hinter [Delta](https://delta.dev/) 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. **02 · DeltaDB-Analogie** Gemeinsamer DeltaDB-Zustand wird zu einem gewöhnlichen Checkout für bestehende Entwicklungswerkzeuge. ```text DeltaDB gemeinsamer Worktree-Zustand · Änderungshistorie · Kollaborationszustand ↓ Materialisierter Checkout gewöhnliche Projektdateien auf jedem Rechner ↓ Bestehende Werkzeuge Editor · Compiler · Tests · Anwendungslaufzeit ``` > 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. ### Technical note: Wo dies im Repository zu finden ist `MemoryContextProjector` läuft innerhalb von `MemoryContextAssembler` nach Budgetierung und Reranking – sowohl im Live- als auch im As-of-Pfad – und erzeugt eine oberflächenneutrale `MemoryContext.Projection`. Drei Render-Oberflächen konsumieren diese Projektion über `ProjectionRenderer`. ```text MemoryContextAssembler ↓ MemoryContextProjector ↓ MemoryContext.Projection ↓ ProjectionRenderer ``` Die Projektionsschicht ist bewusst opt-in: Alle sechs Flags in `MemoryProjectionOptions` sind standardmässig false. Bei deaktivierter Projektion ist `Projection` null, während die bestehenden Render-Pfade byte-identisch bleiben, abgesichert durch SHA256-Fingerprint-Tests. Auch die Framework-Grenze ist explizit: Microsoft Agent Framework, Semantic Kernel und MCP-Integrationen hängen nach innen vom Core ab, nicht umgekehrt. Direkte .NET-Nutzung kann dieselben Services ohne Agentenframework verwenden. Der Owner-Scope läuft durch `MemoryScope`; Anwendungsidentität und Store-Routing sind separate Host-Belange. `MemoryIsolationMode` verwendet aus Gründen der Rückwärtskompatibilität standardmässig `SingleTenant`; `WarnOnUnscoped` und der geschlossen fehlschlagende Modus `StrictMultiTenant` sind opt-in. [Architekturübersicht](https://github.com/joslat/agent-memory-dotnet/blob/main/docs/architecture.md) · [Integrations- und Scoping-Leitfaden](https://github.com/joslat/agent-memory-dotnet/blob/main/docs/getting-started.md) Darum fühlte sich die Projektionsidee für mich weniger spekulativ an. Die Implementierung unterscheidet bereits Zusammenstellung, Projektion und Rendering. Meine Frage ist, was geschieht, wenn dieselbe Trennung nicht nur für Gedächtnis, sondern auch für Fähigkeit, Richtlinien und gelerntes Verhalten zum Architekturprinzip wird. Mit main am 28. August 2026 abgeglichen. 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. ```text 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. ```text 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. ```text Kandidatenfähigkeit ↓ Evaluation ↓ menschliche / richtlinienbasierte Genehmigung ↓ genehmigte Fähigkeit ↓ neue Laufzeitprojektionen ``` **03 · Projektion und gesteuertes Rückschreiben** Ein kanonisches Substrat projiziert Kontext an einen Akteur; Erfahrung kehrt als Vorschlag zu Evaluation und Governance zurück. ```text Kanonisches Substrat genehmigte Fähigkeit · Evidenz · Provenienz · Richtlinien · Historie ↓ Laufzeitprojektion relevanter Zustand · Skills · Werkzeuge · Berechtigungen · Anweisungen ↓ Akteur interpretieren · schlussfolgern · entscheiden · synthetisieren ↓ Erfahrung Ergebnisse · Fehler · Entdeckungen · Ausnahmen ↓ Vorschlag Vorschlag statt direkter Mutation ↓ Evaluation / Governance übernehmen · ablehnen · Evidenz verlangen ↺ Kanonisches Substrat ``` ## 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.** **04 · Kontextvirtualisierung** Ein System materialisiert eine Laufzeitwelt und prüft Evidenz, bevor sie zu gemeinsamem Lernen wird. ```text Kanonisches Substrat Welt · Erfahrung · Fähigkeiten · Provenienz · Evaluation · Richtlinien · Berechtigungen · Historie ↓ Laufzeitprojektion relevanter Zustand · Historie · Skills · Werkzeuge · Berechtigungen · Anweisungen ↓ Akteur interpretieren · schlussfolgern · entscheiden · synthetisieren ↓ Erfahrung / Vorschlag Evidenz und mögliche Änderungen ↓ Evaluation / Governance entscheidet, was zu gemeinsamem Lernen wird ↺ Kanonisches Substrat ``` > 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: ```text 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: **05 · Vom Lernen des Akteurs zum Systemlernen** Lokales Lernen wird zu gemeinsamer Evaluation, Fähigkeit und begrenzten Projektionen für viele Akteure erweitert. ```text Akteurslokaler Kreislauf Akteur ↓ Erfahrung ↓ Gedächtnis ↓ Evaluation ↓ Verbesserte Fähigkeit ↺ Gemeinsamer Systemkreislauf 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 01 ### Berechtigungsgebundenes Lernen Akteur A lernt aus Informationen, die Akteur B nicht sehen darf. Darf die abgeleitete Lektion geteilt werden? Provenienz und Klassifizierung müssen womöglich mit der gelernten Fähigkeit reisen. 02 ### Widersprüchliche Lektionen Akteur A lernt, dass X funktioniert. Akteur B lernt, dass X scheitert. Für semantischen Widerspruch gibt es keinen Compiler. 03 ### Fehlende gemeinsame Erfolgsmetrik Systemlernen setzt voraus, dass wir wissen, was „funktioniert“ bedeutet. Schneller? Sicherer? Günstiger? Regelkonformer? Besser für Nutzende? Organisationen haben oft keine gemeinsame Metrik. > 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. RAG · Lesezeit ```text Dokumente ↓ Abruf ↓ LLM ↓ Antwort ``` Adaptives Substrat · geschlossener Kreislauf ```text 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. ```text 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? **06 · Eine Fähigkeit, viele Projektionen** Eine gesteuerte Fähigkeit wird als Wiki, Checkliste, KI-Skill, Review und Workflow materialisiert. ```text Lebendiges Fähigkeitssubstrat Verfahren · Evidenz · Richtlinien · Varianten · Evaluation · Provenienz ↓ Materialisierte Ansichten Wiki · menschliche Checkliste · KI-Laufzeitskill · Review · Workflow / ausführbare Repräsentation ``` > 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. ### Incident Response Eine sich entwickelnde operative Fähigkeit, viele Laufzeitansichten. Runbooks, Wikis, Postmortems und tatsächliches Verhalten driften schnell auseinander. Ein gemeinsames Substrat könnte erfolgreiche und gescheiterte Abläufe, Werkzeugverhalten, Eskalationen und Erkenntnisse sammeln. ```text gemeinsame Incident-Fähigkeit → Bereitschaftsdienst → Einsatzleitung → KI-Laufzeit → Audit / Schulung ``` Der Wert ist nicht „besserer Chat“, sondern eine operative Fähigkeit für mehrere Rollen. ### Regulierte Abläufe Richtlinien, Provenienz, Berechtigungen und rollenspezifische Projektionen. Banken, Versicherungen und Pharma verbinden veränderliche Richtlinien, Berechtigungen, Evidenz und Auditierbarkeit. Unterschiedliche Akteure brauchen unterschiedliche Darstellungen desselben Prozesses. ```text Richtlinie + Verfahren + Provenienz + Evaluation → Analyse → Review → Compliance → Audit-Evidenz ``` ### Organisatorisches Prozesswissen Ein realer Prozess, viele menschliche und maschinelle Darstellungen. Wie stellen wir hier tatsächlich jemanden ein? Der reale Prozess enthält formale Schritte, Systeme, Ausnahmen, lokale Praxis und wiederkehrende Fehler. ```text ein lebendiger Prozess → Checkliste → HR-Workflow → Onboarding → KI-Unterstützung → Governance ``` ### Softwareentwicklung Fähigkeit als Infrastruktur statt duplizierter Dokumentation. Eine Deployment-Fähigkeit lebt selten nur in DEPLOYMENT.md. Sie verteilt sich über Repository, CI, Tests, fehlgeschlagene Deployments, Freigaben und Umgebungsbedingungen. ```text Deployment-Substrat → SKILL.md → Dokumentation → CI-Validierung → Codex / Copilot → visueller Workflow ``` ### Kundensupport Gemeinsames Lernen aus Lösungen, Fehlern und Produktänderungen. Supportwissen verändert sich ständig. Lernen auf Systemebene ist attraktiver, als jeder Assistenz dieselbe Lektion einzeln beizubringen. ```text alle Supporterfahrungen → Evaluation → gemeinsame Lösungsfähigkeit → Kundenassistenz → Frontline-Support → Spezialisten / QA ``` ### KI-Adoption im grossen Massstab Gemeinsame Richtlinien und Fähigkeiten unter vielen Copilots. Wenn Organisationen immer mehr Copilots, Assistenzen, Prompts und Workflows ansammeln, wird die eigentliche Skalierungsfrage womöglich, was sie alle wissen und tun dürfen. ```text genehmigte Werkzeuge + Richtlinien + Datenklassifizierung + Workflows + Vorfälle + Evaluation → HR-Assistenz → Forschungsassistenz → M365-Assistenz → Mitarbeitendenhilfe → Governance ``` ## Die Eigentumsfrage Aus der Laufzeit heraus: ```text Ich erinnere mich. Ich habe diese Skills. Ich kann diese Werkzeuge verwenden. ``` Von aussen: ```text 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: > **Offene Frage** > > Ab wann wird Agentengedächtnis zur Anwendungsarchitektur? > 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](https://www.linkedin.com/in/joslat/) - [AgentMemory for .NET — GitHub](https://github.com/joslat/agent-memory-dotnet) - [AgentEval — GitHub](https://github.com/AgentEvalHQ/AgentEval) - [Neo4j NAMS / Agent Skills](https://neo4j.com/labs/agent-memory) - [Delta](https://delta.dev/)