🧭 1. Ausgangspunkt: Komplexität jenseits von „nur Code"
In den letzten 12–18 Monaten habe ich ein größeres KI-gestütztes Projekt aufgebaut. Kein klassisches Webprojekt, kein isoliertes Backend, sondern ein verteiltes System mit mehreren Modulen, Agenten, Persistenz-Layern und Langzeitgedächtnis-Experimenten.
Was sich in dieser Zeit deutlich gezeigt hat:
- ▸ Tools verändern sich schneller als Architekturen.
- ▸ Modelle werden besser, aber nicht stabiler im Kontext.
- ▸ Kontextverlust ist kein Randproblem, sondern systemisch.
- ▸ Agenten brauchen Struktur – nicht nur Prompts.
Das Resultat ist ein öffentliches Repository:
Autonomous Agent Manifest Specification
👉 github.com/DEVmatrose/Autonomous-Agent-Manifest-Specification
Es ist kein akademisches Paper. Es ist ein aus der Praxis entstandener Ordnungsrahmen.
⚠️ 2. Das Kernproblem: Kontextzerfall in komplexen Projekten
Bei einfachen Projekten kann ein Entwickler vieles „im Kopf halten". Bei komplexen Ökosystemen funktioniert das nicht mehr.
Ich arbeite nicht an einzelnen Komponenten, sondern an:
- ▸ Multi-Service-Architekturen
- ▸ Agenten-Workflows
- ▸ Speicher- und Retrieval-Mechanismen
- ▸ API-Orchestrierung
- ▸ Rate-Limit-Handling
- ▸ Kontext-Caching
- ▸ Versions- und Dokumentationssystemen
Allein intern: > 50 Whitepapers und > 60 Workpapers (Stand dieses Jahres).
Das ist kein Overhead. Das ist die Voraussetzung für Kontrolle.
📄 3. Whitepaper–Workpaper-System
Whitepaper = Architektur-Ebene
Ein Whitepaper beschreibt:
- ▸ Ziel des Moduls
- ▸ Architekturelle Grundannahmen
- ▸ Schnittstellen
- ▸ Abhängigkeiten
- ▸ Sicherheits- und Strukturprinzipien
- ▸ Langfristige Design-Entscheidungen
Whitepapers sind stabil. Sie ändern sich selten.
Workpaper = operative Ebene
Ein Workpaper dokumentiert:
- ▸ Konkrete Session-Arbeit
- ▸ Implementierungsdetails
- ▸ Tests
- ▸ Fehlerbilder
- ▸ Iterationen
- ▸ Entscheidungen unter Zeitdruck
Workpapers sind dynamisch. Sie bilden den realen Verlauf ab.
Mit klassischen Coding-Tools entsteht Code. Mit diesem System entsteht: Reproduzierbare Architektur.
Und genau das ist der Unterschied zwischen „KI benutzt" und „KI strukturell integriert".
🤖 4. Agenten-Level statt Prompt-Level
Wenn man mit einzelnen Prompts arbeitet, reicht Kontextfenster. Wenn man mit autonomen Agenten arbeitet, braucht man:
- ▸ Klare Arbeitsstruktur
- ▸ Formalisierte Dokumentation
- ▸ Maschinenlesbare Ordnungslogik
- ▸ Eindeutige Projekt-Normen
Agenten dürfen nicht raten, wie gearbeitet wird. Sie müssen es wissen.
Die Manifest-Spezifikation definiert genau das:
Damit wird ein Projekt für Mensch und Maschine gleichzeitig lesbar.
🔥 5. Kontextverlust – das unterschätzte Problem
Selbst mit großen Modellen bleibt ein Problem:
In größeren Projekten ist das kein Schönheitsfehler – es ist ein Produktivitätskiller.
Deshalb experimentiere ich mit:
- ▸ Longtime Memory
- ▸ Zwischenpersistenz
- ▸ Strukturiertem Retrieval
- ▸ Paper-Referenzierung statt Vollkontext
- ▸ Zustandsrekonstruktion aus Metadaten
Kontext darf kein flüchtiger Zustand sein. Er muss rekonstruierbar sein.
🏗️ 6. Ordnung als Architekturprinzip
Ich sehe das nicht als „Dokumentationsmethode". Ich sehe es als architektonisches Kontrollinstrument.
Ordnung bedeutet:
- ▸ Jeder Agent weiß, wo er steht.
- ▸ Jeder Mensch kann querlesen.
- ▸ Jede Entscheidung ist nachvollziehbar.
- ▸ Jede Iteration ist referenzierbar.
- ▸ Jede Architektur bleibt überprüfbar.
Das verhindert:
Schleichende Inkonsistenz
Implizite Annahmen
Stillschweigende Architekturbrüche
🌐 7. Warum ich das Repository öffentlich gemacht habe
Viele arbeiten inzwischen mit autonomen Agenten, lokalen LLMs, Multi-Model-Setups und verteilten Workflows. Fast alle stoßen auf dasselbe Problem:
Die Struktur fehlt. Nicht die Technologie.
Ich bin kein Wissenschaftler auf diesem Gebiet. Aber ich habe mich selbst durchgearbeitet – aus Notwendigkeit. Dieses Repository ist das Ergebnis dieser Praxis.
🔧 Erweiterung: Manifest als nachrüstbares Ordnungs-Layer
Das System ist so gebaut, dass:
- ▸ es in bestehende Repositories eingefügt werden kann
- ▸ es keine bestehende Code-Struktur zerstört
- ▸ es unabhängig von Sprache oder Stack funktioniert
- ▸ es sowohl für Menschen als auch für Agenten lesbar ist
- ▸ es projektübergreifend standardisiert werden kann
Das ist architektonisch sauber gedacht. Kein Framework, kein Tool-Zwang, keine Runtime-Abhängigkeit.
Nachrüstbarkeit als Kernprinzip
Viele arbeiten bereits mit Legacy-Code, gewachsenen Monorepos, Microservice-Landschaften und experimentellen KI-Projekten. Was dort fast immer fehlt:
- ✗ Formalisierte Architekturdokumentation
- ✗ Sessionbasierte Entwicklungsprotokolle
- ✗ Rekonstruierbare Entscheidungslogik
- ✗ Agentenlesbare Struktur
Ein bestehendes Projekt bekommt ein Manifest-Verzeichnis und arbeitet ab diesem Zeitpunkt strukturiert weiter. Ohne Migration. Ohne Rewrite. Ohne Dogma.
Architekturgedanke dahinter
Technisch betrachtet ist das System:
Der Code bleibt Code. Aber die Ordnungslogik wird explizit. Das ist ein Unterschied, den viele unterschätzen.
🎯 8. Fazit
KI-Modelle werden besser. Agenten werden leistungsfähiger. Tools werden schneller. Aber ohne Struktur entsteht Chaos.
Mein Ansatz:
- ▸ Whitepaper für Architektur
- ▸ Workpaper für operative Realität
- ▸ Manifest-Spezifikation für Agenten
- ▸ Longtime Memory gegen Kontextverlust
- ▸ Klare Projekt-Ordnungslogik
Nicht als akademische Theorie. Sondern als überlebensnotwendige Praxis für komplexe Systeme.
Wenn du selbst an größeren KI-Ökosystemen arbeitest, wird dich das Thema früher oder später einholen. Besser, man strukturiert es von Anfang an.