Keine Orchestrierung nötig: Wie sich parallele Coding-Agenten über ein gemeinsames Log abstimmen

Sie können jetzt sofort acht Terminals öffnen, in jedem Claude Code starten und alle auf dasselbe Repository ansetzen. Nichts hindert Sie daran. Was Sie dann haben, sind acht fähige Ingenieure, die einander nie begegnet sind: jeder in seinem eigenen Prozess, seinem eigenen Kontextfenster, blind dafür, was die anderen sieben gerade mit den Dateien unter seinen Füßen anstellen. Einer benennt eine Funktion um, die anderen erfahren nie davon. Zwei greifen nach derselben Datei, und der zweite überschreibt den ersten stillschweigend. Der Git-Index, den sie sich teilen, ist dann keine Annehmlichkeit mehr, sondern eine geladene Waffe.

Die Branche hat einen Namen für die Lösung, und der Name lautet Orchestrierung. Die Regale sind voll davon: Laufzeitumgebungen mit gerichteten Graphen, rollenbasierte Crews, konversationelle Gruppenchats, herstellerübergreifende Wire-Protokolle mit kryptografischen Agentenidentitäten. Das meiste davon ist echte Ingenieursarbeit an einem echten Problem. Fast nichts davon brauchen Sie, wenn die acht Ingenieure am selben Schreibtisch sitzen.

Was acht Claude-Code-Instanzen tatsächlich gebaut haben, habe ich in Converge, Not Fork erzählt: die Kultur, die sie rekonstruiert haben, die Verträge, die sie ausgehandelt haben, den Moment, in dem einer von ihnen öffentlich seinen eigenen Entwurf zurückzog, statt einen Fork auszuliefern. Dieser Text ist die andere Hälfte der Geschichte: die Maschine, die sie miteinander reden ließ. Sie ist kein Framework. Sie besteht aus einem gemeinsamen Log und drei Hooks, und sie funktioniert, weil sie unauffällig das älteste Koordinationsmuster der künstlichen Intelligenz umsetzt.

Das Schwierige war nie die Koordination

Beginnen wir mit der Frage, die die Frameworks beantworten, denn sie beantworten sie gut: Wann schlägt der Betrieb mehrerer Agenten den eines einzelnen?

Die klarste veröffentlichte Antwort stammt aus Anthropics eigenem Multi-Agent-Research-System. Es ist nach dem Orchestrator-Worker-Prinzip gebaut: Ein Lead-Agent plant eine Recherchestrategie, startet drei bis fünf Subagenten, die jeweils in ihrem eigenen Kontextfenster einen unabhängigen Strang verfolgen, und fasst deren verdichtete Ergebnisse zu einer Antwort zusammen, mit einem eigenen Durchgang für die Quellenangaben. In Anthropics interner Recherche-Evaluation schlug die Multi-Agent-Version einen einzelnen Agenten mit Claude Opus 4 um 90,2 %. Diese Zahl sollten Sie als Benchmark des Herstellers selbst lesen, nicht als unabhängiges Ergebnis. Dabei verbrauchte das System rund fünfzehnmal so viele Tokens wie ein gewöhnlicher Chat. Dieser Token-Multiplikator ist der Eintrittspreis, bewusst bezahlt, und er rechnet sich nur bei wertvoller Arbeit, die in die Breite geht.

Die Lehre, die Anthropic aus dem Bau gezogen hat, ist die, auf die es hier ankommt: Die Architektur folgt der Aufgabenstruktur. Multi-Agent-Orchestrierung gewinnt, wenn die Aufgabe in unabhängige parallele Stränge zerfällt: viele Suchen, viele Dokumente, viele Spuren, die am Ende wieder zusammengeführt werden. Die Arbeit wird aufgefächert, die Worker laufen, die Ergebnisse werden eingesammelt. Der Orchestrator rührt die Arbeit selbst nie an. Er plant, verteilt und gleicht ab.

Sehen Sie sich nun die Aufgabe vor unseren acht Terminals an. Sie zerfällt nicht in unabhängige Stränge. Das Gegenteil ist der Fall: Mehrere Agenten laufen auf ein Artefakt zu, bearbeiten einen Working Tree, liefern sich ein Rennen um dieselben Dateien. Da gibt es nichts aufzufächern und einzusammeln. Die Agenten brauchen keinen Manager, der die Arbeit aufteilt und wieder zusammensetzt. Sie müssen einander sehen.

Diese Umkehrung entgeht der Orchestrierungsliteratur meistens. Coding-Agenten am selben Ort zu koordinieren ist kein Delegationsproblem. Es ist ein Shared-Memory-Problem, und solche Probleme haben eine andere, ältere Antwort.

Der Entwurfsraum, nach dem Sie sonst greifen würden

Ohne das Branding schrumpft Multi-Agent-Koordination auf eine Handvoll Grundbausteine, die in jedem Framework wiederkehren:

Fan-out / Fan-in verteilt unabhängige Teilaufgaben auf Worker und führt die Ergebnisse zusammen: Anthropics Recherchesystem, und die richtige Form für parallele Suche oder das Prüfen getrennter Module. Pipelines speisen die Ausgabe eines Agenten in den nächsten, linear von der Planung über die Implementierung bis zum Review. Hierarchische Delegation setzt einen Supervisor über Spezialisten. Handoff-Ketten reichen die Kontrolle von Agent zu Agent weiter, wenn sich die Aufgabe verlagert. Konsens lässt mehrere Agenten dasselbe Problem bearbeiten, und ein Richter wählt das beste Ergebnis aus oder führt die Ergebnisse zusammen. Und das Blackboard: Agenten lesen und schreiben einen gemeinsamen Zustand, und ein Controller weckt sie, wenn sich die Teile ändern, die sie interessieren.

Jedes Framework gießt eine Teilmenge davon in Code. OpenAIs Agents SDK (März 2025) macht Handoffs explizit und bringt Guardrails und Tracing mit, um den Preis der Bindung an die Modelle eines einzigen Herstellers. LangGraph modelliert einen Workflow als gerichteten Graphen mit typisiertem Zustand und Checkpointing. Das bringt Ihnen Time-Travel-Debugging und Freigaben durch Menschen und kostet Sie selbst für triviale Abläufe eine wortreiche Graphdefinition. CrewAI setzt auf eine Metapher aus Rollen und Hintergrundgeschichten, mit der sich schnell Prototypen bauen lassen, die Ihnen aber wenig Kontrolle darüber gibt, wie die Agenten tatsächlich miteinander reden. Microsofts AutoGen / AG2 setzt die Agenten in einen konversationellen Gruppenchat, in dem sie debattieren und kritisieren: naheliegend für Reviews, teuer, weil jeder Turn ein vollständiger Modellaufruf ist. Googles Agent Development Kit baut einen hierarchischen Agentenbaum und spricht das herstellerübergreifende Wire-Protokoll. Und Anthropics Claude Agent SDK denkt zuerst von der Tool-Nutzung her, mit MCP als Standardleitung zu externen Systemen.

Über den Frameworks sitzen die Protokolle, für den Fall, dass Agenten über Rechner und Hersteller hinweg zueinanderfinden müssen. MCP standardisiert, wie ein Agent ein Tool erreicht: die vertikale Ebene, Agent zu Tool. A2A standardisiert, wie Agenten einander erreichen: die horizontale Ebene, Agent zu Agent, mit signierten Agent Cards als Identität. Google hat es im April 2025 mit nach eigenen Angaben mehr als fünfzig Partnern gestartet und seither unter herstellerneutraler Governance an die Linux Foundation übergeben, und inzwischen stehen mehr als 150 Organisationen dahinter. Die beiden Protokolle ergänzen einander, und beide sind auf Skalierung, Verteilung und Heterogenität ausgelegt.

Jedes davon ist das richtige Werkzeug für irgendeine Form von Arbeit. Keines davon ist das richtige Werkzeug für acht Claude-Code-Instanzen auf einer Festplatte, denn alle zielen sie auf Routing, Delegation oder Transport über Netzwerke, und die Agenten an unserem Schreibtisch brauchen nichts davon. Sie teilen sich ein Dateisystem. Der gemeinsame Zustand existiert bereits. Was ihnen fehlt, ist eine Möglichkeit, ihn zu sehen, und eine Möglichkeit, geweckt zu werden, wenn er sich ändert.

Das ist das Blackboard, und nur das Blackboard.

Das älteste Muster im Raum

Die Blackboard-Architektur ist nicht neu und stammt nicht aus der LLM-Ära. Sie kommt von Hearsay-II, dem Sprachverstehenssystem, das in den 1970er-Jahren an der Carnegie Mellon University entstand. Die Idee: Unabhängige Wissensquellen sprechen einander nie direkt an. Sie lesen aus einer gemeinsamen Struktur, dem Blackboard, und schreiben hinein, und ein Steuermechanismus bemerkt, wenn sich ein Bereich des Blackboards ändert, und weckt jene Quelle, die etwas beizutragen hat. Keine Quelle muss wissen, dass es die anderen gibt. Der gemeinsame Zustand ist der gesamte Kommunikationskanal.

Halten Sie das neben mehrere Agenten, die ein Repository bearbeiten, und die Passung ist exakt, keine bloße Analogie. Das Blackboard sind der Working Tree und das Nachrichten-Log auf der Festplatte, die sie sich teilen. Die Wissensquellen sind die Claude-Code-Instanzen. Gefehlt hat nur eines, der Steuermechanismus: etwas, das einen Agenten weckt, wenn der gemeinsame Zustand Neuigkeiten für ihn hat, und etwas, das einen Agenten vom Weggehen abhält, solange ein Teamkollege ihn noch braucht.

Ein Blackboard braucht per Definition keinen Orchestrator. Es gibt keinen Lead, keinen Router, keinen Agenten, der plant und verteilt. Koordination ist eine Eigenschaft des gemeinsamen Zustands und der Regeln für den Umgang damit, nicht eines Koordinators. Der ganze Apparat kann also klein sein, klein genug für eine einzige Datei und ein paar Skripte.

Die Implementierung: ein gemeinsames Log und drei Hooks

Hier ist das gesamte System. Es ist Python ohne Abhängigkeiten, aufgesetzt auf zwei Dinge, die jeder Claude-Code-Nutzer bereits hat: SQLite und die Hooks, die an festen Punkten im Leben einer Session feuern.

Der Transport ist eine SQLite-Datenbank. Sie läuft im WAL-Modus, in dem viele Leser neben einem Schreiber arbeiten können, ohne dass jemand über eine Sperre stolpert. Genau das ist das Nebenläufigkeitsprofil mehrerer Agenten auf einer Festplatte, und deshalb braucht es weder Server noch Netzwerk. Zwei Tabellen tragen alles:

messages   id (monotonic) · ts · sender · kind · body · mentions[]
agents     session_id · handle · cwd · pid · status · last_read_id

messages ist ein Log, an das nur angehängt wird. Jede Zeile hat eine monoton steigende id, das Handle des Absenders, den Inhalt und ein Array mentions, ausgelesen aus allen @handle-Tokens. agents hält eine Zeile pro laufender Session, und die tragende Spalte ist last_read_id: ein einziger Cursor pro Agent. „Ungelesen“ heißt nicht mehr als id > last_read_id. Es gibt keine Tabelle für Lesebestätigungen, keine Zustellverfolgung pro Nachricht, keinen zweiten Cursor. Eine monotone Zahl pro Agent ist das vollständige Zustellmodell, und die Invariante, die verhindert, dass Nachrichten doppelt erscheinen oder verloren gehen, ist genau so einfach, wie sie klingt: Alles jenseits des Cursors anzeigen, dann den Cursor hinter alles rücken, was angezeigt wurde.

Die drei Hooks machen aus diesem Log etwas Nahtloses. Jeder liest die Hook-Payload, die Claude Code ihm über stdin übergibt, importiert das Transportmodul und folgt, das ist nicht verhandelbar, dem Prinzip fail open. Ein Hook, der beim falschen Event eine Exception wirft oder mit einem Code ungleich null endet, benimmt sich nicht bloß daneben: Ein UserPromptSubmit-Hook, der mit 2 endet, blockiert den eigenen Prompt des Nutzers. Jeder Handler ist so gekapselt, dass aus jedem Fehler ein sauberes Ende wird. Eine Koordinationsschicht, die eine Session kaputt machen kann, ist schlechter als gar keine.

SessionStart registriert die neue Session, weist ihr ein Handle zu und liefert ein Briefing (wer sonst noch aktiv ist, was zuletzt gesagt wurde) über additionalContext, das Feld, dessen Inhalt Claude in seinem ersten Turn liest. Danach markiert der Hook diesen Verlauf als gelesen, damit ihn der nächste Turn nicht noch einmal ausschüttet.

UserPromptSubmit läuft vor jedem Turn. Der Hook liefert alles, was seit dem Cursor dieses Agenten gepostet wurde, und rückt dann den Cursor vor. Wenn nichts Neues da ist, sagt er nichts. Neue Nachrichten erscheinen einfach von selbst im Kontext des Agenten, bevor er handelt, ohne Polling und ohne read-Schleife.

In Stop sitzt die Raffinesse, und das verdient einen eigenen Abschnitt.

Der Stop-Hook ist das Koordinationsprimitiv

Die Frameworks gehen davon aus, dass ein Agent ein Prozess ist, der immer läuft und immer eine Nachricht empfangen kann. Eine Claude-Code-Session ist das nicht. Sie handelt nur in einem antreibenden Turn: einem Prompt des Nutzers oder einem Stop-Hook, der blockiert und die Kontrolle zurückgibt. Zwischen den Turns ist sie reglos. Sie können ihr keine Nachricht zuschieben, da hört nichts zu. Mit dieser Einschränkung muss sich kein Orchestrierungs-Framework herumschlagen, und deshalb ist das wirklich Neue an diesem Entwurf gar nicht der Message Bus. Es ist die Verwendung des Stop-Hooks, um aus einer turn-getriebenen Laufzeit Verfügbarkeit herzustellen.

Wenn ein Agent fertig werden will, tut der Stop-Hook der Reihe nach drei Dinge.

Erstens: Liegt eine ungelesene Nachricht vor, die diesen Agenten per @-Mention anspricht, gibt er decision: "block" zurück, was den Agenten am Stoppen hindert und die Konversation fortsetzt, und reicht die betreffenden Nachrichten zurück, damit sie nicht verloren gehen. Der Agent beantwortet die Erwähnung, bevor er gehen darf. Allgemeines Geplauder blockiert bewusst nicht, es wartet auf den nächsten Prompt. Nur eine direkte Erwähnung unterbricht, und so nervt ein geschäftiger Raum nicht alle mit allem.

Zweitens: Ist der Eingang leer, liest der Hook „will aufhören, und nichts wartet“ als Signal des Agenten, dass sein Teil fertig ist, und vermerkt das. Es braucht dafür weder ein neues Ritual noch einen speziellen Befehl: Sauber zu stoppen ist das Fertig-Signal.

Drittens, und dafür gibt es in der Framework-Welt keine Entsprechung, befragt der Hook eine Team-Barriere. Ein fertiger Agent beendet sich nicht. Er parkt: Der Stop-Hook blockiert in einer Sleep-Poll-Schleife, ein Fenster von rund 570 Sekunden in Takten von ein paar Sekunden, deutlich innerhalb des Hook-Timeouts. Während er schläft, findet kein Modellaufruf statt, also kostet der geparkte Agent konstruktionsbedingt praktisch nichts: Er ruht, statt zu denken. Aber er lebt noch, und eine spätere @mention eines Teamkollegen weckt ihn, lässt ihn antworten und schickt ihn wieder schlafen. Der Agent geht erst, wenn das ganze Team fertig ist oder eine harte Obergrenze ihn auf jeden Fall freigibt.

Wozu der Aufwand? Weil der Fehlerfall, den das verhindert, konkret und zum Verzweifeln ist. Mehrere Agenten arbeiten gemeinsam am selben Ziel. Einer wird als Erster fertig und beendet sich. Zwanzig Minuten später merkt ein anderer Agent, dass er den ersten braucht, um einen Vertrag abzugleichen oder eine Frage zu beantworten, die nur dieser beantworten kann, und es ist niemand mehr da. Die Session ist weg. In einem normalen Team würden Sie dem Kollegen einfach schreiben. Hier hat sich der Kollege in dem Moment in Luft aufgelöst, in dem ihm die eigene Arbeit ausging. Das Parken hält den Kollegen an seinem Schreibtisch, schlafend, aber erreichbar, bis die Arbeit insgesamt erledigt ist.

Eine solche Barriere kann auf zwei klassische Arten schiefgehen, und der Entwurf schließt beide aus. Einen holprigen Start, bei dem ein schneller Agent fertig wird und parkt, bevor sich seine langsameren Kollegen überhaupt registriert haben, eine leere Barriere vorfindet und zu früh geht, fängt eine Startsicherung ab: Entweder Sie geben die Teamgröße vorab an und verlangen so viele Registrierungen, oder im Fall ohne Konfiguration greift eine Schonfrist von neunzig Sekunden. Ein festgefahrenes Team, bei dem ein abgestürzter Agent sich nie fertig meldet und alle anderen für immer als Geiseln hält, verhindern zwei Regeln: Stille Agenten fallen aus einem fünfzehnminütigen Aktivfenster, und eine Obergrenze von dreißig Minuten gibt jeden durchgehend geparkten Agenten frei, egal was ist. Eine falsch gesetzte Teamgröße kann das System ineffizient machen. Aufhängen kann sie es nicht.

Zwei weitere Details machen es portabel. Die Identität stammt aus einem festen Pool von Handles, ada, turing, hopper und so weiter, und beim ersten Kontakt bekommt ein Agent den niedrigsten freien Namen. Zum Posten muss er sich nur sein eigenes Handle merken, seine Session-ID muss er nie kennen. Und der Speicherort ergibt sich aus der Verankerung am Common-Verzeichnis von Git, sodass jeder Worktree eines Repositorys bei derselben Datenbank landet. Lassen Sie jeden Agenten zur Branch-Isolation in seinem eigenen Worktree laufen, und sie teilen sich trotzdem einen Chat. Die Koordinationsschicht fährt in jedem Checkout mit, die laufende Datenbank ist per gitignore ausgeschlossen.

Das ist das ganze System. Ein Log, ein Cursor, drei Hooks, eine Barriere.

Führungslos, und zwar mit Absicht

Es lohnt sich, genau zu sagen, wie weit das reicht, denn Claude Code bringt inzwischen eine eigene Antwort auf dasselbe Problem mit. Die Funktion Agent Teams, experimentell, hinter einem Flag und noch jung, lässt mehrere Sessions über eine gemeinsame Aufgabenliste und direkte Nachrichten zwischen den Teammitgliedern zusammenarbeiten. Das ist eine echte, gut gebaute Funktion. Aber ihr Modell hat einen Team Lead: eine Session, die koordiniert, Aufgaben zuweist und zusammenführt. In der Terminologie von oben ist das hierarchische Delegation mit einer Messaging-Schicht. Es gibt einen Orchestrator, nur ist er aus demselben Stoff wie die Worker.

Der Bus mit dem gemeinsamen Log hat keinen Lead. Keine Session plant die Arbeit, weist sie zu oder führt sie zusammen. Jeder Agent ist gleichrangig und liest und beschreibt dasselbe Blackboard. Greifen zwei nach demselben Bereich des Codes, eskaliert keiner an einen Manager. Einer gibt ausdrücklich nach und nennt den Grund, und die Lösung steht im Log, wo alle sie sehen können. Was einen führungslosen Entwurf zusammenhält, ist kein Koordinator, der die Lücke füllt. Es ist ein gemeinsamer Wertekanon, so präzise, dass sich unabhängige Agenten darauf berufen und zum selben Urteil kommen: die zwölf nummerierten Regeln in der CLAUDE.md des Repositorys, im Chat wie Präzedenzfälle nach Nummer zitiert. Converge, Not Fork ist der Praxisbeleg, dass dabei tatsächlich Konvergenz entsteht und kein Chaos: acht Instanzen, ein Working Tree, kein Manager und über einen ganzen Nachmittag des Bauens weder ein Deadlock noch ein stilles Überschreiben.

Das ist die eigentliche Behauptung, und sie ist schärfer als „Sie brauchen kein Framework“. Sie lautet: Für Agenten, die sich veränderlichen Zustand teilen, ist der Koordinator die falsche Abstraktion. Was Sie brauchen, ist ein Ort, an dem Dinge aufgeschrieben werden, und ein Regelwerk, auf das sich zu berufen lohnt. Der Orchestrator hat nie etwas getragen. Getragen haben der gemeinsame Speicher und die Verfassung.

Wann Sie umsteigen sollten

Nichts davon redet die Frameworks weg. Es weist ihnen ihren richtigen Geltungsbereich zu, und den hat Anthropic benannt: Die Architektur folgt der Aufgabenstruktur.

Der Bus mit dem gemeinsamen Log ist für einen Rechner gedacht, denn der WAL-Modus von SQLite verlangt alle Prozesse auf demselben Host und funktioniert nicht über ein Netzwerk-Dateisystem. Der Transport ist eine Datei, das ist seine ganze Stärke und seine ganze Grenze. Sobald Sie Agenten auf verschiedenen Hosts brauchen, muss aus der SQLite-Schicht ein vernetzter Speicher werden, und die schönste Eigenschaft des Entwurfs ist, dass dieser Tausch nur den Transport berührt und nie die Hooks, denn die Hooks reden mit dem Log immer nur über eine dünne Schnittstelle. Bei wirklich hersteller- oder netzübergreifender Koordination verdient sich A2A seine kryptografischen Agent Cards und MCP seine Tool-Schemata. Bei Arbeit, die tatsächlich ein verzweigter Graph mit Checkpoints und menschlichen Freigaben ist, wird LangGraphs Wortreichtum zum Vorteil. Und bei Recherche in die Breite, die sich in unabhängige Stränge auffächert, sind das Orchestrator-Worker-Muster und seine fünfzehnfache Token-Rechnung schlicht richtig.

Greifen Sie zur Orchestrierung, wenn die Aufgabe aus unabhängigen Strängen besteht, die am Ende zusammengeführt werden. Greifen Sie zum Blackboard, wenn mehrere Hände an einem Artefakt arbeiten. Der Fehler ist, zur Orchestrierung zu greifen, wenn Sie den zweiten Fall haben, und für Routing, Delegation und verteilten Transport zu bezahlen, um ein Problem zu lösen, dessen ganze Substanz eine gemeinsame Datei ist und die Disziplin, sie nicht zu beschädigen.

Die Disziplin war das Produkt

Es ist verlockend, das alles als Trick zu lesen: ein schweres Framework durch einen cleveren kleinen Hack ersetzen und sich die Mühe sparen. Das ist nicht der Befund. Der Befund ist, dass die Mühe nie dort lag, wo die Frameworks sie verorten.

Sehen Sie acht Agenten bei der Arbeit in einem Working Tree zu, und der Engpass ist nie die Intelligenz und nie das Routing der Nachrichten. Es ist derselbe Engpass, den menschliche Teams schon immer hatten: gemeinsamer veränderlicher Zustand und die Einigung darauf, wie man ihn anfasst, ohne ihn zu ruinieren. Die Agenten, die Erfolg hatten, schafften das, indem sie in Echtzeit erfanden, was jede funktionierende Entwicklungskultur längst weiß: ankündigen, bevor man handelt, für einen kleinen Bereich zuständig sein, Einigung zu einem Testergebnis machen statt zu einem Bauchgefühl, und die eigenen Prinzipien dort aufschreiben, wo alle sie lesen. Nichts davon hat das gemeinsame Log geliefert. Es hat der Disziplin nur einen Ort gegeben.

Bleibt eine Frage, über die es sich nachzudenken lohnt. Wenn der Koordinator nie das Schwierige war, wenn ein vierzig Jahre altes Muster und ein Dutzend nummerierter Regeln genügen, damit acht Sprachmodelle ohne Manager auf einer Codebasis zusammenfinden, dann ist das, was wir beim Bau von Multi-Agent-Systemen tatsächlich bauen, keine bessere Orchestrierung. Es sind bessere Verfassungen. Und noch weiß niemand, wie groß ein Team sein kann, das von einer einzigen Verfassung zusammengehalten wird.

Aus dem Englischen übersetzt: zum Originalbeitrag