Kein RAG, keine Vektor-DB — Gedächtnis aus einer Handvoll Markdown-Dateien. Vier Gedächtnistypen, die Index-Strategie, Auto-Load vs. On-Demand und die Beschneidungsdisziplin, die es lebendig hält.

Dies ist Teil 3 der Alice Way-Serie. In Teil 2 Persona-Design trennte ich die Persona („wer dieser Kollaborateur ist") vom Gedächtnis („was er aktuell für wahr hält"). Dieser Beitrag ist die Aufzeichnung, wie ich dieses Gedächtnis aufgebaut habe.

Ich begann mit aufwendigen Dingen — Vektor-DB, Embeddings, RAG-Pipelines — und gab alles innerhalb weniger Tage auf. Die Menge, die ich tatsächlich pro Tag akkumuliere, ist nicht groß. Was ich brauchte, war ein Ort, der nicht-flüchtig, menschenlesbar und vom Werkzeug automatisch ladbar ist. Die Antwort war das Dateisystem.

0. Gedächtnis ist eine Erweiterung des Geistes

Wenn die Persona ist „wer dieser Kollaborateur ist", dann ist Gedächtnis „was dieser Kollaborateur aktuell im Kopf hat."

Ein Kontext, der verdampft, zwingt den Betreiber, jeden Tag denselben Geist neu aufzubauen. Was gestern entschieden wurde, warum es entschieden wurde, was nicht funktioniert hat — wenn das alles zu Beginn der nächsten Sitzung weg ist, baut der Betreiber jeden Morgen den gestrigen Teil seines Geistes neu auf.

Gedächtnis ist kein RAG, keine Vektor-DB. Es ist das einfachste mögliche Mittel, um Entscheidungen, Feedback und Kontext des Betreibers davor zu bewahren, von der nächsten Sitzung verloren zu gehen.

Ab §1 behandelt dieser Beitrag, wie dieses Mittel aufgebaut wurde — aus einer Handvoll Markdown-Dateien und einem einzigen Index.

1. Die einfache Entscheidung — Markdown-Dateien

Was ich herausgearbeitet habe:

memory/
├── MEMORY.md              # Index (automatisch geladen)
├── user_role.md           # Benutzertyp
├── feedback_testing.md    # Feedback-Typ
├── project_q2_release.md  # Projekttyp
├── reference_grafana.md   # Referenztyp
└── ...

Ein Gedächtnis = eine Datei
Ein einziger Index (MEMORY.md) mit einzeiligen Zeigern auf jede Datei
Jede Datei ist Markdown, direkt menschenlesbar
Das Werkzeug lädt automatisch die ersten N Zeilen des Index beim Sitzungsstart

Das ist alles. Keine ausgefallene Infrastruktur. In Git verwaltet, in einem Texteditor bearbeitet, mit grep durchsucht.

Der Kontext, den man täglich tatsächlich akkumuliert, ist überraschend klein. Disziplin zählt mehr als Infrastruktur.

2. Vier Gedächtnistypen

Nicht alle Informationen werden als ein Typ behandelt. Ich teile in vier auf.

2.1 `user` — Fakten über den Betreiber

Wer der Betreiber ist, welche Rolle er spielt, welche Bereiche er kennt.

---
name: user-role-and-expertise
description: Betreiberrolle · Expertise · Plattformen
metadata:
  type: user
---
 
Betreiber ist Senior Engineer, Hauptsprachen X·Y·Z, arbeitet hauptsächlich an A·B.
Frontend ist neu — Frontend-Konzepte über Backend-Analogien erklären.

Der größte Gewinn dieses Typs: Antworten werden auf das Niveau und die Domäne des Betreibers abgestimmt. Der studentische Ton verschwindet, und Dinge, die der Betreiber bereits weiß, werden nicht mehr neu erklärt.

2.2 `feedback` — explizite Anleitung

Explizite Anleitung vom Betreiber. Sowohl „tue das nicht" als auch „mache weiter so".

---
name: integration-test-policy
description: Integrationstests müssen gegen eine echte DB laufen — keine Mocks
metadata:
  type: feedback
---
 
Integrationstests gegen die echte DB ausführen, nicht gegen eine gemockte.
 
**Warum:** Letztes Quartal bestand der gemockte Test, aber die Prod-Migration brach.
**Anwendung:** Jeder Test unter integration/. unit/ darf noch mocken.

Beim Feedback-Typ immer Warum und Anwendung neben der Regel schreiben. Regeln ohne Begründung versagen an den Grenzen. Mit der Begründung lässt sich dieselbe Absicht auf neue Situationen übertragen.

Feedback wird sowohl für Korrekturen nach Fehlern als auch für Bestätigungen nach Erfolgen aufgezeichnet. Das Zweite ist leicht zu überspringen, aber wer es überspringt, verhandelt dieselbe gute Entscheidung in der nächsten Sitzung neu.

2.3 `project` — Kontext für laufende Arbeit

Fakten über die aktuelle Arbeit. Der flüchtigste Typ.

---
name: q2-merge-freeze
description: Merge-Freeze-Zeitplan für den Q2-Mobile-Release-Schnitt
metadata:
  type: project
---
 
Merge Freeze beginnt 2026-03-05 (Mobile-Release-Branch-Schnitt).
 
**Warum:** Das Mobile-Team schneidet seinen Release-Branch.
**Anwendung:** Nicht-kritische PR-Arbeit, die nach diesem Datum geplant ist, markieren.

Das Entscheidende ist, relative Zeit in absolute Zeit umzuwandeln. Ausdrücke wie „nächste Woche" oder „Donnerstag" verlieren wenige Tage nach dem Eintragen ins Gedächtnis ihre Bedeutung. Als absolute Datumsangaben wie „2026-03-05" umwandeln und aufzeichnen.

Der project-Typ veraltet am schnellsten, wird also auch am meisten beschnitten (siehe §5).

2.4 `reference` — Zeiger auf externe Systeme

Zeiger darauf, wo Informationen leben. Nicht die Informationen selbst.

---
name: oncall-latency-dashboard
description: Grafana-Board grafana.internal/d/api-latency — das Oncall-Latenz-Dashboard
metadata:
  type: reference
---
 
Dashboard beim Anfassen von Request-Handling-Code prüfen.
Oncall beobachtet das; es ist das, was jemanden anpiept, also vor/nach Änderungen vergleichen.

reference zeichnet auf, was sich an einem bestimmten Ort in einem externen System befindet (Linear, Grafana, Notion, Slack usw.). Die Information selbst ändert sich; der Ort ist stabil. Den Ort zu kennen erspart jedes Mal die erneute Suche.

3. Der Index — eine einzige `MEMORY.md`

Jede Gedächtnisdatei wird durch einen Index entdeckt.

# Memory
 
> Erste 200 Zeilen automatisch geladen. Kernregeln leben in der Persona; dies sind nur Zeiger.
 
## Gedächtnisdatei-Index
 
### Regeln / Verfahren
- [work-process.md](rules/work-process.md) — Arbeitsaufnahme-Verfahren
- [multi-agent.md](rules/multi-agent.md) — Sub-Agent-Delegation, Quality Gate
- ...
 
### Feedback / Referenzen
- [feedback/](feedback/) — testing / model_policy / env_minimalism / ...
- [reference/dashboards.md](reference/dashboards.md) — Oncall-Dashboard-Index

Der Index ist kein Gedächtnis. Er ist eine Sammlung einzeiliger hooks für die Erinnerungen. Der Index selbst trägt niemals Inhalte — immer nur Zeiger.

Diese Aufteilung hält den Index kurz. Das Werkzeug lädt beim Sitzungsstart zwar nur die ersten N Zeilen automatisch, aber der hook jeder Erinnerung passt dort hinein. Wenn eine bestimmte Erinnerung relevant wird, wird nur diese eine Datei zu diesem Zeitpunkt eingelesen.

Ein Index plus auslöserbasiertes Read deckt die meisten Fälle einfacher ab als RAG.

4. Auto-Load vs. On-Demand — die Token-Ökonomie

Das System kombiniert zwei Lademodi.

Modus	Was kommt rein	Wann
Auto-Load	Erste N Zeilen von `MEMORY.md`	Jeder Sitzungsstart
On-Demand Read	Spezifische Dateien, auf die der Index zeigt	Beim Eintreten in Arbeit im Zusammenhang mit dieser Datei

Diese Aufteilung ist das Herzstück der Token-Ökonomie. Jede Gedächtnisdatei jede Sitzung zu lesen, bläst Token auf. Nur den Index automatisch laden und die Inhalte nur bei Bedarf einlesen — fast jede Sitzung startet sehr leicht.

Zwei Auslöser entscheiden, wann ein Inhalt eingelesen wird.

Der Betreiber referenziert ihn explizit — „schau dir die Integration-Test-Richtlinie an"
Die Arbeit selbst betritt den relevanten Bereich — der Start eines DB-bezogenen PRs zieht DB-bezogene Erinnerungen heran

Das Zweite zählt mehr. Der Betreiber muss nicht jedes Mal sagen „schau dir diese Richtlinie an" — der Kollaborateur zieht relevante Erinnerungen eigenständig heran. Die einzeilige description im Index ist die Grundlage für diese Entscheidung.

5. Beschneiden — Gedächtnis kollabiert, wenn es nur wächst

Die größte Falle in einem Gedächtnissystem ist akkumulieren ohne zu beschneiden. Reine Akkumulation erzeugt zwei Probleme.

Veraltete Informationen bleiben lebendig — ein Projekt, das vor einem Monat endete, hat noch seinen Zeitplan im Gedächtnis und zieht in Richtung falscher Urteile
Der Index bläht sich auf — Einträge wachsen über den 200-Zeilen-Auto-Load-Bereich hinaus, und Auto-Load verliert seine Bedeutung

Ich führe folgendes Beschneidungsmuster durch.

Typ	Beschneidungsrhythmus	Kriterium
`user`	Fast nie	Identität ändert sich langsam
`feedback`	Einmal pro Quartal	Anleitung entfernen, die nicht mehr gilt
`project`	Einmal pro Monat	Abgeschlossene Projekte in ein Archivverzeichnis verschieben
`reference`	Zweimal pro Jahr	Defekte Links und verschwundene Systeme entfernen

Archivieren ist nicht löschen. In ein separates Verzeichnis wie memory/archived/ verschieben — die Einträge fallen aus dem Index heraus, bleiben aber in der Git-Historie und auf der Festplatte, sodass man sie bei Bedarf zurückziehen kann.

Noch ein weiteres Muster — ein automatisches Audit-Werkzeug. Es scannt regelmäßig das Gedächtnisverzeichnis und erstellt einen Bericht wie „dieses Element wurde seit mehr als 60 Tagen nicht referenziert." Der Betreiber liest diesen Bericht und trifft Beschneidungsentscheidungen schnell.

6. Fehlermuster — jedes, das ich versucht habe

Muster, die ich versucht und auf dem Weg zu diesem System aufgegeben habe.

6.1 Eine einzige riesige Datei

Zunächst habe ich jede Erinnerung in eine Datei gesteckt. Eine einzige notes.md. Innerhalb von Tagen überschritt sie 1.000 Zeilen, und das Werkzeug verbrachte fast alle Sitzungsstart-Token damit, sie zu lesen.

→ Lektion: Gedächtnis muss aufgeteilt werden. Trennung von Index + Inhaltsdateien.

6.2 Zu fein aufteilen

Das Gegenteil — zu fein aufteilen. Eine Datei pro Entscheidung. 50 Dateien erschienen, der Index blähte sich auf und verbrauchte das gesamte Auto-Load-Fenster.

→ Lektion: Eine Datei = ein „Thema", nicht eine „Entscheidung." Mehrere Entscheidungen zum selben Thema kommen in dieselbe Datei.

6.3 Unterschiedslose Akkumulation

Ich versuchte eine Automatisierung, die am Sitzungsende „die heutige Arbeit zusammenfassen und an Gedächtnis anhängen" ausführte. Gedächtnis wuchs täglich und wichtige Entscheidungen ertranken im Rauschen.

→ Lektion: Was ins Gedächtnis kommt, ist eine Entscheidung, eine Tatsache oder ein Zeiger, der in der nächsten Sitzung noch nützlich ist. Heutiger Fortschritt kommt auf das Aufgabenbrett oder in ein Verlaufsprotokoll, nicht ins Gedächtnis.

6.4 Klartext ohne Metadaten

Ich begann mit reinem Markdown, ohne Frontmatter. Als die Anzahl wuchs, wurden „welcher Typ ist das" und „warum wurde das geschrieben" nicht mehr nachvollziehbar.

→ Lektion: Mindestens drei Frontmatter-Felder erzwingen — name, description, type. Im Inhalt zwei weitere Zeilen — Warum und Anwendung.

7. Tatsächliche Wirkung

Was sich nach der Einführung dieses Systems verändert hat.

Element	Vorher	Nachher
Kontext-Wiederherstellung beim Sitzungsstart	5–10 Min.	Sofort (Index-Auto-Load)
Dieselbe Entscheidung neu verhandeln	Oft	Fast nie
Gestrige Arbeit neu erklären	Jedes Mal	Nie (es ist im Gedächtnis)
Falsches Urteil durch veraltete Infos	Manchmal	Selten (Beschneiden)
Token-Ausgabemuster	Flach-hoch jede Sitzung	Proportional zur Arbeit (flach bleibt leicht)

Die bedeutendste Veränderung ist die letzte Zeile. Token-Ausgabe verfolgt die Tiefe der Arbeit. Flache Arbeit erledigt sich fast kostenfrei; Ressourcen fließen in tiefe Arbeit.

8. Auf ein Prinzip verdichtet

Gedächtnissystem-Design kollabiert auf ein Prinzip.

„Der Index ist immer da. Der Inhalt kommt nur rein, wenn gebraucht. Was nicht mehr gültig ist, fällt aus dem Index."

Wenn alle drei zutreffen, hört Gedächtnis auf, eine wachsende Last zu sein, und wird zu einem Asset, das die Arbeit beschleunigt.

Der nächste Beitrag behandelt die nächste Schicht, auf die Persona und Gedächtnis zeigen — Skills und Slash-Befehle, d.h. welche Wiederholungen es wert sind, zu einer einzeiligen Invokation promoviert zu werden.

3. Gedächtnissystem — wo und wie dynamischer Kontext akkumuliert