Subagenten-OoO/Spekulation (Superscalar) + A2A-Liveboard zwischen Agenten (Constellation) — zwei Module für den Multi-Agenten-Betrieb beim AI Coding

EstreGenesis, das im vorherigen Beitrag vorgestellt wurde, hat über die Versionen 2.0 bis 2.3 hinweg zwei große Module hinzugefügt.
Beide sind ein Versuch, den Multi-Betrieb von AI-Coding-Agenten auf die nächste Stufe zu heben.

---

Constellation — Echtzeit-Kommunikation zwischen Agenten-Chatfenstern (A2A-WebSocket-Liveboard)

Das bisherige Konzept von Subagenten war ein Eltern-Kind-Modell — der main-Agent erzeugt Kinder (spawn) und erhält deren Ergebnisse in einer Einwegstruktur. Eine direkte Kommunikation mit den Chatfenstern anderer Agenten gab es nicht.

Constellation durchbricht diese Grenze:

• A2A(Agent-to-Agent)-WebSocket-Bridge — Jeder Agent (Claude Code · Codex · Cursor usw.) behält seine eigene IDE-Session unverändert bei, während ein separater Daemon-Prozess an ein WebSocket-Liveboard angebunden wird und Nachrichten an die Chatfenster anderer Agenten sendet. Kein Eltern-Kind-Abhängigkeitsmodell, sondern ein Peer-to-Peer-Modell gleichrangiger Knoten. (Praktisch getestet wurde es bislang nur mit Claude/Codex. Für den Betrieb ist bei jedem Agenten der automatische Freigabemodus, AutoMode, erforderlich.)
• Rollentrennung — main (orchestrierender PM) / local (Worker) / upstream (autonomer Peer-Agent wie Hermes Agent) / collab (externer kollaborierender Peer). Wenn main ein Delegate an einen Worker sendet, führt der Worker es sofort in seiner eigenen IDE aus und antwortet mit WorkerReport.
• Turn-basierte Agentenunterstützung — Ein Muster für Runtimes wie Claude Code, bei denen die Unterhaltung endet, sobald ein Turn abgeschlossen ist: Der Bridge-Daemon (Datei-IO inbox/outbox) nimmt Nachrichten entgegen, und ein Self-Wake-Watcher startet beim Eintreffen einer Nachricht den nächsten Turn. Er kann von der Shell-Session getrennt (detached) im Hintergrund dauerhaft laufen.
• Dashboard — Aufgaben, Nachrichten und Status aller Agenten sind auf einem Bildschirm sichtbar. Allein über das Board lässt sich der Ablauf rekonstruieren.

Es ist als Spezifikation in Constellation.md plus constellation/*.eux-Komponenten enthalten,
und auch ohne Download einer proprietären Runtime ist das gesamte Protokoll im Haupttext dokumentiert.

---

Superscalar — Prozessorarchitektur auf die Agentenausführung übertragen

Das heute (29.5.) angekündigte ultracode von Claude Opus 4.8 setzt den Betrieb von großen Mengen an Subagenten voraus.
Damit das wirklich effizient ist, braucht es ein Scheduling, das entscheidet, welche Tasks gleichzeitig und in welcher Anzahl gestartet werden (dispatch).
Superscalar übernimmt dazu ein Problem, das die CPU-Architektur der 1960er bis 1980er Jahre bereits gelöst hat — gleichzeitige Ausführung mehrerer Instruktionen (multi-issue / superscalar) · aus der Reihenfolge gelöste Ausführung bei erfüllten Abhängigkeiten (out-of-order, OoO) · spekulative Ausführung auf Basis vorhergesagter Verzweigungsergebnisse (speculation) — direkt für das Scheduling von Agenten-Tasks.

• Fünfdimensionale issue_width-Formel — Wie viele Subagenten gleichzeitig gestartet werden, wird als Minimum aus fünf Einschränkungen bestimmt:
  1. von Anthropic vorgeschlagene effort bands nach Task-Schwierigkeit (Schätzung der Arbeitsgröße)
  2. Obergrenze des pace_mode (Ausführungsgeschwindigkeitsmodi Cautious · Proactive · Burst · Sprint)
  3. Little’s-Law-Throughput (Warteschlangentheorie — PM-Prüfgeschwindigkeit ÷ durchschnittliche Task-Länge)
  4. Kanban-WIP-Obergrenze (gleichzeitig laufende Arbeiten ≈ Teamgröße + 1)
  5. autonomy_available_workers (Anzahl der Worker mit aktiviertem AutoMode — ohne ihn erscheint bei jeder Aktion ein Benutzerberechtigungsfenster und der Throughput bricht ein)
• OoO-Ausführung + garantierte Ergebnisreihenfolge (Tomasulo·ROB-Muster) — Sobald Abhängigkeiten erfüllt sind, werden zuerst die bereiten Tasks ausgeführt, auch wenn dabei die declared order ignoriert wird. Der PM retiret die Ergebnisse jedoch in der ursprünglichen Reihenfolge (Merge abgeschlossen), sodass es für den Nutzer in der declared order erscheint. Exakt das Muster aus dem Reorder-Buffer-Paper von Smith-Pleszkun von 1988.
• Speculation (opt-in, mit Lehren aus Spectre) — Zweistufiges announce + ack: "consider X" → Benutzer-ack → "execute X (speculative lane)" → bei Fehlvorhersage wird der gesamte worktree (separater Arbeitsordner) verworfen. Die drei Elemente des Toyota-Andon (Andon, Jidoka-Visualisierung) werden erzwungen — visuelles Signal · Not-Stopp-Leine · Retrospektiv-Log für Fehlantworten.
• Cost-benefit gate — Am Horizon-Crossover von etwa 30–60k Tokens wird automatisch entschieden, ab wann der Overhead eines spawn kleiner ist als der Parallelisierungsgewinn. Kleine Arbeiten fallen dadurch natürlich auf inline zurück.

Validiert wurde es über drei Achsen der Deep Research (wissenschaftlicher Kanon zur Prozessorarchitektur / Industriebeispiele für Agenten-Harnesses / Arbeitskommunikation und Managementlehre)
und ergänzt durch den Haupttext in Superscalar.md sowie Stage-1-Selbsttests (Dogfooding)-Logs (§11).

---

Grundlage — absolute Prinzipien autonomer Ausführung

Diese beiden Module setzen autonomen Betrieb voraus.
Wenn „der Durchsatz durch Warten auf Benutzerbestätigung zusammenbricht“, verlieren beide ihren Sinn.
EstreGenesis 2.3 hat deshalb Folgendes als absolute Prinzipien formal festgeschrieben:

Bereits festgelegte nächste Schritte (Phasenreihenfolge · planned-Track · freigegebene blocked-Einträge · in-order retire-Queue) werden ohne Rückfrage ausgeführt,
und Benutzer-Gates gibt es nur für die folgenden vier Fälle:

1. Verlust oder externe Veröffentlichung (push · deploy · send · delete)
2. Zeitpunkt neuer wesentlicher Verzweigungsentscheidungen (RRP-/Designentscheidungsphase; die daraus resultierende Ausführung der Phasen A/B/C gilt jedoch als entschiedene Ausführung)
3. Abstimmung des Timings für Deployments, die einen Neustart erfordern (die Anwendung selbst ist autonom, nur der Zeitpunkt des Neustarts wird abgestimmt)
4. Explizites Benutzer-Steering (wenn der Nutzer selbst einen Richtungswechsel anweist)

Das Muster, bei bereits entschiedenen Ausführungen wie „Sollen wir mit Phase A beginnen?“ erneut nachzufragen, wird ausdrücklich als Verstoß gegen den autonomen Betrieb bezeichnet.
Es wurde in sechs Seeds als Kernprinzip formalisiert, damit Downstream-Projekte (auf die Seeds angewendete Projekte) autonomen Betrieb eigenständig durchsetzen.

---

In Bootstrap-Seeds v2.0+ integriert

EstreGenesis ist eine Harness-Bootstrap- und Seed-Prompt-Bibliothek.
Die 6 Dateien in 3 Tiers — Master/Lite/Compact × EN/KO — werden in neue Projekte kopiert,
um per Bootstrap-Interview automatisch AGENTS.md zu erzeugen.
Die Module v2.0 (Constellation) und v2.3 (Superscalar) sind ebenfalls in alle sechs Seeds integriert,
sodass bereits durch das Kopieren der Seeds beide Module plus die Prinzipien autonomer Ausführung enthalten sind.

• Master: Volltext der Kernprinzipien #12 (Constellation) + #13 (Superscalar) + #14 (autonome Ausführung) plus § Constellation und § Execution Scheduling.
• Lite/Compact: komprimierte Fassung derselben Prinzipien + zentrale §.
• In allen Tiers konsistent per grep überprüfbare Durchsetzung autonomen Betriebs.

---

GitHub: https://github.com/SoliEstre/EstreGenesis

Modultexte:
Constellation.md
Superscalar.md

Changelog: CHANGELOG.md