OoO/spéculation par sous-agents (Superscalar) + liveboard A2A entre agents (Constellation) — deux modules d’orchestration multi-agents pour le codage IA

EstreGenesis, présenté dans un article précédent, a ajouté deux gros modules au fil des versions 2.0 à 2.3.
Tous deux visent à faire passer à l’étape supérieure la gestion multi-agents d’agents de codage IA.

---

Constellation — communication en temps réel entre fenêtres de dialogue d’agents (liveboard WebSocket A2A)

Le concept existant de sous-agent reposait sur un modèle parent-enfant : l’agent principal créait (spawn) des enfants et recevait leurs résultats, dans une structure unidirectionnelle. Il n’y avait pas de communication directe avec la fenêtre de dialogue d’un autre agent.

Constellation fait sauter cette limite :

• Pont WebSocket A2A (Agent-to-Agent) — chaque agent (Claude Code · Codex · Cursor, etc.) conserve sa propre session IDE telle quelle, tandis qu’un processus démon séparé se connecte à un liveboard WebSocket pour envoyer des messages à la fenêtre de dialogue d’autres agents. Un modèle peer-to-peer entre nœuds égaux, et non une dépendance parent-enfant. (Les tests réels n’ont été confirmés que pour Claude/Codex. En exploitation, le mode d’approbation automatique (AutoMode) de chaque agent est indispensable.)
• Séparation des rôles — main (PM orchestrateur) / local (worker) / upstream (pair agent autonome comme Hermes Agent) / collab (pair collaborateur externe). Quand main envoie une Delegate (délégation) à un worker, celui-ci l’exécute immédiatement dans son IDE et répond via WorkerReport (rapport).
• Prise en charge des agents à base de tours — un pattern pour les runtimes où, comme avec Claude Code, la conversation se termine à la fin d’un tour (turn) : le démon de pont (inbox/outbox en file I/O) conserve les messages reçus, et un self-wake watcher (surveillant auto-réveil) lance le tour suivant dès l’arrivée d’un message. Il peut rester résident en arrière-plan, détaché de la session shell.
• Tableau de bord — les tâches, messages et états de tous les agents sont visibles sur un seul écran. Le simple board permet déjà de reconstituer le flux.

Le module est inclus sous forme de Constellation.md + spécifications de composants constellation/*.eux,
et l’ensemble du protocole est documenté dans le texte lui-même, sans téléchargement d’un runtime privé.

---

Superscalar — introduire l’architecture processeur dans l’exécution d’agents

L’ultracode de Claude Opus 4.8, annoncé aujourd’hui (29/05), part du principe d’une orchestration de nombreux sous-agents,
mais pour que cela soit réellement efficace, il faut un ordonnancement capable de décider quelles tâches lancer en parallèle et en quelle quantité (dispatch).
Superscalar applique tel quel à l’ordonnancement de tâches d’agents un problème déjà résolu par l’architecture CPU des années 1960 à 1980 — exécution simultanée de plusieurs instructions (multi-issue / superscalar) · exécution hors ordre quand les dépendances sont satisfaites (out-of-order, OoO) · exécution spéculative sur la base d’une prédiction de branchement (speculation).

• Les 5 dimensions officielles de issue_width — le nombre de sous-agents à lancer simultanément à un instant donné est déterminé par le minimum de cinq contraintes :
  1. la bande d’effort par difficulté de tâche proposée par Anthropic (estimation de la taille du travail)
  2. le plafond de pace_mode (modes de vitesse d’exécution Cautious · Proactive · Burst · Sprint)
  3. le throughput selon la loi de Little (théorie des files d’attente — vitesse de revue du PM ÷ durée moyenne des tâches)
  4. le plafond WIP du Kanban (nombre de tâches en cours en parallèle ≈ taille de l’équipe + 1)
  5. autonomy_available_workers (nombre de workers avec mode d’approbation automatique activé — sinon une fenêtre d’autorisation utilisateur apparaît à chaque action et le throughput s’effondre)
• Exécution OoO + garantie de l’ordre des résultats (pattern Tomasulo · ROB) — dès que les dépendances sont satisfaites, les tâches prêtes sont exécutées sans respecter le declared order (ordre déclaré). Mais le PM retire (fusionne définitivement) les résultats dans l’ordre d’origine, de sorte que pour l’utilisateur, tout apparaît dans le declared order. Reprise directe du pattern du papier de 1988 de Smith-Pleszkun sur le Reorder Buffer.
• Speculation (opt-in, avec application des leçons de Spectre) — annonce en 2 étapes + ack : "consider X" → ack utilisateur → "execute X (speculative lane)" → en cas de mauvaise prédiction, le worktree (dossier de travail isolé) est entièrement abandonné. Les 3 éléments du Toyota Andon (visualisation Jidoka) sont imposés — signal visuel · corde d’arrêt d’urgence · journal de rétrospective des erreurs.
• Cost-benefit gate — le système détermine automatiquement le point où l’overhead de spawn devient inférieur au gain du parallélisme, autour de l’horizon de 30 à 60k tokens. Les petites tâches retombent naturellement en inline.

Le tout a été validé selon trois axes de deep research (canon académique sur l’architecture processeur / cas industriels d’agent harness / communication du travail et management),
et complété par le texte de Superscalar.md et les logs de tests internes Stage 1 (dogfooding) (§11).

---

Base — principes absolus de l’exécution autonome

Ces deux modules supposent une opération autonome.
Si « le débit s’effondre à force d’attendre la confirmation de l’utilisateur », ils perdent tous deux leur sens.
EstreGenesis 2.3 a donc formalisé les éléments suivants comme principes absolus :

tout ce qui relève d’une étape suivante déjà définie — ordre des phases, piste planned, éléments blocked débloqués, file in-order retire — doit s’exécuter sans demander de confirmation,
et les points de passage côté utilisateur se limitent strictement aux quatre cas suivants :

1. perte ou publication externe (push · deploy · send · delete)
2. moment d’une nouvelle décision de branchement majeure (étape de décision RRP/conception ; en revanche, l’exécution des Phases A/B/C décidées à cette occasion reste une exécution décidée)
3. coordination du timing d’un deploy nécessitant un redémarrage (l’application elle-même est autonome, seul le moment du redémarrage est coordonné)
4. steering utilisateur explicite (l’utilisateur ordonne lui-même un changement de direction)

Le pattern consistant à redemander une exécution déjà décidée, comme « Dois-je lancer la Phase A ? », est explicitement qualifié de violation de l’exploitation autonome,
et ce principe a été inscrit comme règle clé dans les 6 seeds afin que les projets downstream (qui appliquent ces seeds) puissent imposer par eux-mêmes le fonctionnement autonome.

---

Intégration dans les bootstrap seeds v2.0+

EstreGenesis est une bibliothèque de prompts de seeds et de bootstrap pour harness,
dont les 6 fichiers EN/KO en 3 niveaux Master/Lite/Compact sont copiés dans un nouveau projet
pour piloter une interview de bootstrap et générer automatiquement AGENTS.md,
et les modules v2.0 (Constellation) et v2.3 (Superscalar) sont eux aussi intégrés dans les 6 seeds,
de sorte qu’en copiant simplement les seeds, on embarque déjà les deux modules ainsi que les principes d’exécution autonome.

• Master : texte complet du principe clé #12 (Constellation) + #13 (Superscalar) + #14 (exécution autonome) + § Constellation + § Execution Scheduling.
• Lite/Compact : version condensée des mêmes principes + sections essentielles.
• Sur tous les niveaux, une contrainte cohérente d’exploitation autonome, vérifiable avec grep.

---

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

Texte des modules :
Constellation.md
Superscalar.md

Changelog : CHANGELOG.md