Markdown Agent OS (MAOS): Multi-Agent-Systeme aus reinem Text
📄 Das vollständige Paper lesen (PDF) — Markdown Agent OS (MAOS): Building Multi-Agent Systems from Markdown, Terminals, and Coding Agents.
Ich habe dieses Paper bereits im Februar 2026 geschrieben und veröffentliche es erst jetzt. Die Grundidee ist seitdem nur relevanter geworden: Man braucht kein neues Framework, um leistungsfähige Multi-Agent-Systeme zu bauen. Man braucht ein Terminal, ein Dateisystem und einen Coding-Agent – und die Bereitschaft, seine Workflows als einfaches Markdown zu schreiben.
Ich nenne dieses Muster Markdown Agent OS (MAOS).
Das Problem mit der Art, wie wir Agenten orchestrieren
Coding-Agenten wie Claude Code sind heute allgegenwärtig. Sie lesen und schreiben Dateien, führen Shell-Befehle aus und rufen Tools auf. Darauf aufbauend versprechen Multi-Agent-Frameworks spezialisierte Agenten, die planen, zusammenarbeiten und langlaufende Workflows verwalten.
Aber fast die gesamte Orchestrierung ist noch immer Code. Einen Workflow zu definieren bedeutet, Python-Graphen, Konfigurationsdateien, Pipelines oder eigene Backends zu schreiben. Selbst wenn das Framework mächtig ist, bleibt die Einstiegshürde hoch: Man muss seine Abstraktionen lernen, Abhängigkeiten verwalten, Dienste deployen und sowohl den eigenen Code als auch das Modellverhalten debuggen.
Für nicht-technische Nutzer ist das praktisch unmöglich. Für technische Nutzer ist es langsam und fragil.
Also bin ich von einer anderen Frage ausgegangen: Was, wenn wir gar kein neues Framework bauen? Was, wenn das Terminal, das Dateisystem und ein Coding-Agent-CLI, die wir bereits haben, die Runtime sind – und alles andere nur Text ist?
Die Grundidee
Bei MAOS ist der Workflow das Dokument. Aufgaben, Schritte, Vorgaben und erwartete Ergebnisse werden als Markdown geschrieben, und ein Agent mit lokalem Tool-Zugriff interpretiert sie und erledigt die Arbeit im selben Workspace.
Das Denkmodell ist einfach:
- Terminal + Dateisystem sind der Körper.
- Der Coding-Agent-CLI ist das Gehirn.
- Markdown-Dateien sind das Nervensystem – sie definieren Skills, Workflows und Vorgaben in einfacher Sprache.
- Tools und MCP-Integrationen sind die Hände – sie browsen, fragen APIs ab, aktualisieren Datenbanken und rufen externe CLIs auf.
Ein Skill ist eine Beschreibung eines wiederholbaren Workflows in natürlicher Sprache, umgesetzt als Ordner mit einer SKILL.md-Datei sowie optionalen Templates, Referenzdokumenten und Skripten. Ein Flow ist ein kurzer Auslöser – etwa /new-idea oder /client-research – der dem Agenten sagt, welchen Skill er ausführen soll. Ist der Skill einmal geschrieben, braucht es keinen weiteren Code.
Das verwandelt das Terminal in eine Art natürlichsprachiges Betriebssystem: Flows sind Befehle, Skills sind Programme, Tools sind Systemaufrufe, und das Dateisystem ist der gemeinsame Speicher.
Warum reiner Text gewinnt
Das ganze Argument des Papers läuft auf vier Aussagen hinaus:
- Markdown kann die Orchestrierungsschicht sein. Ein Workflow besteht aus Schritten, Vorgaben und Output-Verträgen in natürlicher Sprache, die Menschen und Agenten lesen und bearbeiten können.
- Der lokale Workspace ist die Runtime. Kein neues Framework – nur ein Dateisystem plus ein Agent, der mit deiner Erlaubnis Dateien liest/schreibt und Tools ausführt.
- Dateibasierte Workflows sind portabel und einsehbar. "State" wird zu menschenlesbaren Artefakten – Notizen, Entwürfe, Logs, Checklisten – statt verstecktem Gedächtnis. Du kannst ihn prüfen, versionieren und wiederverwenden.
- Der Ansatz ist modell- und tool-agnostisch. Jede Runtime, die Markdown lesen und auf lokalen Dateien arbeiten kann, kann ihn umsetzen.
Ein System auf einen anderen Rechner zu bringen heißt, einen Ordner zu kopieren. Die Logik zu ändern heißt, Text zu bearbeiten.
Multi-LLM-Zusammenarbeit ohne Orchestrierungscode
Einer meiner Lieblingsteile: MAOS ermöglicht es, dass mehrere Modelle innerhalb eines einzigen Workflows zusammenarbeiten – ganz ohne expliziten Orchestrierungscode, Agent-Graphen, Sockets oder Scheduler.
Claude Code agiert dabei meist als Orchestrator. Andere CLIs – Codex, Gemini, Qwen – laufen headless als spezialisierte Sub-Agenten und schreiben ihr Ergebnis jeweils an einen strukturierten Ort im gemeinsamen Workspace. Sind sie fertig, liest der Hauptagent diese Dateien, vergleicht die Resultate und synthetisiert ein zusammenhängendes Ergebnis.
Ein /start-blog-research-Flow könnte etwa Codex für eine technische Literaturrecherche, Gemini für Mainstream-Quellen und Qwen für Community-Diskussionen anstoßen – und Claude aggregiert, filtert Redundanz und schreibt den vereinten Entwurf.
Die Koordination entsteht ganz natürlich über das gemeinsame Dateisystem und die Textanweisungen. Das Dateisystem ist die Lingua franca zwischen den Agenten, der Markdown-Skill die Partitur des Dirigenten und der Coding-Agent-CLI der Orchesterleiter.
Den Menschen im Loop behalten
Weil Workflows Dateien bearbeiten und Befehle ausführen können, behandelt MAOS Skills von Dritten als nicht vertrauenswürdigen Code und setzt auf einige Schutzmechanismen:
- Explizite Scopes – welche Ordner gelesen oder geschrieben werden dürfen.
- Freigabe-Gates – für alles Unumkehrbare (z. B. zuerst einen menschenlesbaren
content.md-Entwurf schreiben; erst nach Freigabe SQL committen oder irreversible Aktionen ausführen). - Leichtgewichtige Logs – damit jeder Lauf nachvollziehbar und wiederholbar ist.
Gedächtnis ist einfach ganz normaler Workspace-State: dauerhafte Markdown-Dateien, die Präferenzen, Vorgaben und frühere Entscheidungen festhalten. Menschen können sie lesen; Agenten können sie diffen.
Was es tatsächlich bewirkt hat
In der Praxis hat dieses Muster Aufgaben wie Website-Analysen von Kunden und das Erstellen langer Texte von Stunden oder Tagen auf Minuten oder unter eine Stunde reduziert – während ich für Review und finale Entscheidungen im Loop bleibe. Es ist nach wie vor begrenzt durch den Modellkontext, gelegentliches Abweichen vom geschriebenen Plan und die Fragilität mancher Tool-Integrationen. Aber diese Grenzen sind beherrschbar und schrumpfen, je besser die Modelle werden.
Am wichtigsten: MAOS ist kein Produkt – es ist eine Arbeitsweise. Eine Philosophie, Multi-Agent-Systeme als Sammlungen lesbarer Dokumente zu bauen statt als undurchsichtige Backends oder komplexe Graphen. Deine Workflows bleiben anbieterflexibel und deine Daten bleiben auf deinem eigenen Rechner. Selbst wenn ein bestimmtes Modell oder ein Anbieter verschwindet, bleiben die Projekte und Dokumente nutzbar.
Wenn Multi-Agent-Systeme alltägliche Mitarbeiter werden sollen statt Forschungsprojekte, dann ist es vielleicht einer der einfachsten Wege, sie mit denselben Werkzeugen bearbeitbar zu machen, mit denen wir denken und schreiben.