Wo die Zeit wirklich verloren geht
Bei Side-Projects geht der größte Teil der Zeit nicht ins Code-Schreiben, sondern ins Wiederfinden. Wo war nochmal die Migration für category.kind? Welche Konvention gilt für ID-Prefixes? Was war die Entscheidung zum Goal-Tree mit den drei Quellen — joint, private-A, private-B?
Wer mit Agents baut, kennt das Phänomen in einer extremen Form: jede Session beginnt mit Zero Memory. Ohne zentralen Knowledge-Layer wird in jeder Session derselbe Code neu gelesen, dieselben Konventionen neu erraten, dieselben Entscheidungen aus Commit-Messages rekonstruiert.
Genau hier setzt der Orchestration Server an. Statt Wissen in lokalen Markdown-Dateien zu sammeln, lebt der Kontext eines Projekts als Entity in einem zentralen Knowledge-Layer:
- Overview — Rolle, Architektur, Gotchas, aktueller Status
- Tickets — jede Aufgabe, jede Entscheidung, jedes "haben wir schon probiert"
- Timeline — Append-only-Log dessen, was wann passiert ist
- Skills — wiederverwendbare Workflows, die nicht in jeder Session neu erklärt werden müssen
Jede neue Agent-Session lädt den State mit einem einzigen API-Call.
Der Test-Fall: Logbuch
Logbuch ist eine private Couple-Budgeting-App mit Envelope-Konten, Sparzielen und einem Long-Horizon-Goal-Tree für ein gemeinsames Sparziel. Stack: Python/FastAPI Backend, React/Vite/Tailwind Frontend (Android-first PWA), separater Importer, MariaDB, Docker Compose.
Funktionalität, die in wenigen Sessions stand:
- Phase 0 — Foundation, Auth, JSON-Logging
- Phase 1 — Core Envelope Budgeting mit Template + Per-Month-Override und Monthly Rollover
- Phase 2a — Sparziele mit Auto-Archive on Consumption
- Phase 2b — Goal-Tree beliebiger Tiefe, By-Source-Aggregation, Boat-Hero-Visualisierung
- Phase 3 — Importer (Code fertig)
- Phase 4 — Frontend Overhaul, Dark Theme, Mobile-First, Sankey-Charts für Income-Flows
Dazu: 24 Pytest-Cases passing, Backup-Sidecar mit Daily-Cron, JSON-Logging mit Request-IDs, Anonym-Mode für Screen-Sharing.
Time-to-Online: einstellige Tage. Keine Session musste mit "wo war ich stehengeblieben?" beginnen.
Was anders ist
Ohne zentralen Knowledge-Layer:
- Jede Session startet mit Re-Discovery — Code lesen, Konventionen erraten
- Dieselben Fragen werden zwei-, dreimal beantwortet
- Architektur-Entscheidungen treiben mit der Zeit auseinander
Mit Entity-Overview und Tickets:
- Eine Session beginnt mit "Was steht offen?" statt "Was ist hier los?"
- Tickets tracken jede Entscheidung — die nächste Session liest in 30 Sekunden, was sonst Stunden bräuchte
- Das Overview wächst kontinuierlich: bekannte Gotchas, Phasen-Status, verifizierte Capabilities
Die eigentliche Lektion
Knowledge-Layer ersetzen keine Architektur-Entscheidungen. Sie verhindern aber, dass Kontext-Verlust zwischen Sessions zur Hauptkostenstelle wird.
Wer mit Agents baut, dessen Bottleneck ist nicht der Code-Output. Es ist die Zeit, bis die nächste Session produktiv ist. Wenn diese Zeit von Stunden auf Minuten fällt, kollabiert die Time-to-Online von Wochen auf Tage.
Single-digit days statt long agony. Genau dafür gibt es den zentralen Knowledge-Layer.