Mein KI-Agent lief 3 Wochen – und verhielt sich wie mit Amnesie

Letzte Woche habe ich einen Telegram-Agenten auf einen Bestandskunden losgeschickt. Alles gespeichert, riesiges Kontextfenster, sogar ChatGPT Memory an – dachte ich.

Drei Wochen später, vor der Follow-up-Mail:

„Von welcher Firma sind Sie noch mal? Können Sie das Projekt kurz zusammenfassen?“

Der Kunde postete einen Screenshot in unseren Kanal. Dann war klar: Der Agent erinnerte sich an den Chat, nicht an die Beziehung. Bei Pilotkunden nickten alle – nicht das „dumme Modell“, sondern Chatverlauf als Agent Memory missverstanden.

So haben wir unser OpenClaw-Setup repariert: echte Szenarien, kein Glossar zuerst, und die Trennung von AI Memory (Speichersystem) und History im Chat-Fenster. Stack: OpenHuman vs ChatGPT Memory; IDE: Karpathy Kontext-Schichten.

Szenario 1: Chat archiviert, Regel trotzdem weg

Ein B2B-Support-Team erzählte dasselbe Desaster.

Woche drei: „Angebote nur als PDF, kein Excel.“ Agent: „Notiert.“ Im Backend: jedes Wort noch da, „PDF“ durchsuchbar.

Drei Monate später: Excel-Angebot. Kunde: „Hört ihr überhaupt zu?“

Die Regel landete nie in abrufbarer, erzwingbarer Memory – versteckt in Smalltalk und falscher CC-Liste. Neue Session hebt „Kunde A = nur PDF“ nicht zuverlässig nach oben.

Chatverlauf = Audit-Spur. Agent Memory = Zustand für die nächste Entscheidung – CRM-Flag „kein Excel“, kein drei Stunden Call vor jedem Deal.

Szenario 2: Million Tokens – Claude Code macht alles nochmal

In Claude Code lief es anders schief.

Monorepo kartieren, Architektur-Docs – zwei Tage Arbeit. „Fenster reicht, mache später weiter.“

Zwei Wochen später: „Mach mit der Doku am Repo weiter.“ Wieder von vorn scannen, ähnlicher Entwurf. Chat teilweise da – Task-Status fehlt: welches Submodul, was in docs/, was auf mich wartet – liegt in Tool-Output und auf der Platte.

Karpathy: „Unendlicher Kontext ist keine Festplatte.“ In AI Memory gehört eine aktualisierbare Ein-Zeilen-Checkpoint, nicht 20.000 Zeilen stdout.

LangGraph: Memory vs Thread-State. Nachrichtenliste ≠ Memory-Store.

Drei Dinge, die ein Agent wirklich braucht

• Wer & harte Regeln – Kunde A nur PDF; Chef hasst Sprachnachrichten; Team UTC.
• Wo wir standen – Issue #482 bei Legal; Alert ack, Root Cause offen; Doku Kapitel 3.
• Wie beim nächsten Mal – Release-Checkliste, Freigabe, On-Call-Reihenfolge.

Im Architektur-PDF heißen das Semantic, Episodic, Procedural – fehlende Schicht = peinlicher Moment in genau dieser Schicht.

Unser Fehler: jeden Chat-Turn embedden

Frühe OpenClaw-Tests: volles Transkript vektorisieren. Nach einem Monat: sechs Monate altes Deploy-Playbook als aktuelle SOP; widersprüchliche Chat-Schnipsel → falsche Wahl mit Überzeugung.

Schwer ist nicht Speichern, sondern Löschen, Ändern, Abgrenzen. Jede Agent Memory-Zeile: Quelle, created_at, Ablauf/Version. Filter Kunde/Projekt, dann Zeitverfall – weniger erfundene „Richtlinien“. Das schreiben wir ins SOW, nicht „Vector DB erwägen“.

MCP: Schlussfolgerungen in Memory, nicht stdout im Index. Model Context Protocol.

Reicht ChatGPT Memory?

ChatGPT Memory ist gut für Ton in einer App. Läuft der „Agent“ in Slack, Telegram, Cron, IDE, bleibt Memory in OpenAI gefangen. Stack-Übersicht: ChatGPT = Stil, OpenHuman = Arbeitsfakten, OpenClaw+MCP = ausführen. Nur chatten: Memory reicht. Agent der arbeitet: eigene AI-Memory-Schicht.

Langläufer: Gedächtnis ist Schritt eins

Nach dem Memory-Fix: der Agent überlebt die Nacht nicht – Deckel zu, Wi-Fi weg, MCP gekillt, Cron morgens tot. Einträge im Store, Agent wie nie dagewesen.

Drei Schichten: Memory, Ausführung (OpenClaw Gateway auf VPS), Tools (schweres MCP, xcodebuild weg vom schlafenden Laptop). Memory auf Mac/NAS, Gateway Linux VPS, Builds Cloud Mac – weil uns ein Archive schon den Vault-Sync eingefroren hat. Gateway auf VPS.

Kurz gefragt