Subagentes OoO/especulação (Superscalar) + liveboard A2A entre agentes (Constellation) — dois módulos de operação multiagente para codificação com IA

O EstreGenesis apresentado no post anterior adicionou dois grandes módulos ao longo das versões 2.0~2.3.
Ambos são tentativas de elevar em um nível a operação múltipla de agentes de codificação com IA.

---

Constellation — comunicação em tempo real entre janelas de conversa de agentes (liveboard A2A via WebSocket)

O conceito existente de subagente seguia um modelo pai-filho — o agente principal criava (spawn) filhos e recebia seus resultados, em uma estrutura unidirecional. Não havia comunicação direta com a janela de conversa de outros agentes.

O Constellation rompe esse limite:

• Bridge A2A (Agent-to-Agent) via WebSocket — cada agente (Claude Code · Codex · Cursor etc.) mantém sua própria sessão de IDE, enquanto um processo daemon separado se conecta ao liveboard via WebSocket e envia mensagens para a janela de conversa de outros agentes. É um modelo peer-to-peer entre nós equivalentes, e não uma dependência pai-filho. (Os testes reais foram confirmados apenas com Claude/Codex. Na operação, o modo de aprovação automática (AutoMode) de cada agente é obrigatório.)
• Separação de papéis — main (PM orquestrador) / local (worker) / upstream (peer autônomo como Hermes Agent) / collab (peer colaborador externo). Quando o main envia Delegate (delegação) ao worker, o worker executa imediatamente em sua própria IDE e responde com WorkerReport (relatório).
• Compatibilidade com agentes baseados em turnos — um padrão para runtimes como o Claude Code, nos quais a conversa termina quando o turno (turn) acaba: o daemon bridge (inbox/outbox por IO de arquivo) recebe e mantém as mensagens, e um self-wake watcher (observador que desperta sozinho) inicia o próximo turno quando a mensagem chega. Pode permanecer residente em segundo plano, desacoplado da sessão de shell (detached).
• Dashboard — tarefas, mensagens e estados de todos os agentes aparecem em uma única tela. Dá para reconstruir o fluxo olhando apenas para o board.

Ele é incluído como especificação em Constellation.md + componentes constellation/*.eux,
e, mesmo sem baixar um runtime privado, todo o protocolo está organizado no próprio texto.

---

Superscalar — trazendo arquitetura de processadores para a execução de agentes

O ultracode do Claude Opus 4.8, anunciado hoje (29/5), parte do princípio de operar grandes quantidades de subagentes;
para isso ser realmente eficiente, é preciso um agendamento que decida quantas tasks iniciar em paralelo e quais delas disparar (dispatch).
O Superscalar aplica diretamente ao agendamento de tasks de agentes um problema que a arquitetura de CPU das décadas de 1960~80 já havia resolvido — execução simultânea de várias instruções (multi-issue / superscalar) · execução fora de ordem quando as dependências são satisfeitas (out-of-order, OoO) · execução preditiva baseada em previsão de desvio (speculation).

• As 5 dimensões formais de issue_width — quantos subagentes podem ser iniciados ao mesmo tempo é determinado pelo menor valor entre cinco restrições:
  1. effort band por dificuldade de task proposto pela Anthropic (estimativa de tamanho do trabalho)
  2. limite do pace_mode (modos de velocidade de execução Cautious · Proactive · Burst · Sprint)
  3. throughput pela Lei de Little (teoria de filas — velocidade de revisão do PM ÷ comprimento médio da task)
  4. limite de WIP do Kanban (quantidade de trabalho em andamento ao mesmo tempo ≈ tamanho da equipe + 1)
  5. autonomy_available_workers (número de workers com modo de aprovação automática ativado — sem isso, uma janela de permissão do usuário aparece a cada ação e o throughput desaba)
• Execução OoO + garantia da ordem dos resultados (padrão Tomasulo·ROB) — desde que as dependências sejam satisfeitas, executa primeiro as tasks prontas, ignorando a declared order (ordem declarada). Mas o PM faz o retire (conclusão de merge) dos resultados na ordem original, de modo que, do ponto de vista do usuário, tudo aparece na declared order. É exatamente o padrão do artigo de 1988 sobre Reorder Buffer, de Smith-Pleszkun.
• Speculation (opt-in, aplicando as lições do Spectre) — announce + ack em 2 etapas: "consider X" → ack do usuário → "execute X (speculative lane)" → se a previsão falhar, o worktree (pasta isolada de trabalho) é descartado por inteiro. Impõe os 3 elementos do Andon da Toyota (visualização Jidoka): sinal visual · cordão de parada de emergência · log de retrospectiva de erro.
• Cost-benefit gate — identifica automaticamente o ponto em que o overhead de spawn passa a ser menor que o ganho de paralelismo, em um crossover de horizonte de ~30-60k tokens. Tasks pequenas naturalmente caem para inline.

Foi validado por três eixos de deep research (cânone acadêmico de arquitetura de processadores / casos industriais de harness de agentes / comunicação de trabalho e administração)
e complementado pelo texto principal de Superscalar.md e pelos logs de teste interno da Stage 1 (dogfooding, §11).

---

Base — princípio absoluto da execução autônoma

Os dois módulos acima partem do pressuposto de operação autônoma.
Se "o throughput desaba esperando confirmação do usuário", nenhum dos dois faz sentido.
Por isso, o EstreGenesis 2.3 formalizou o seguinte como princípio absoluto:

etapas seguintes já definidas — ordem das fases, trilha planned, itens liberados de blocked, fila de in-order retire — devem prosseguir sem perguntar,
e o gate do usuário existe apenas para os quatro casos abaixo:

1. perda ou emissão externa (push · deploy · send · delete)
2. momento de decidir uma nova bifurcação importante (etapa de decisão de RRP/projeto; porém, a execução das fases A/B/C definidas por esse resultado passa a ser execução decidida)
3. coordenação do timing de um deploy que exige reinício (a aplicação em si é autônoma; só o momento do reinício é coordenado)
4. steering explícito do usuário (quando o usuário manda mudar de direção diretamente)

O padrão de perguntar novamente sobre execuções já decididas, como "Posso começar a Fase A?", é definido como violação da operação autônoma,
e foi formalizado como princípio central nos 6 seeds, para que projetos downstream (que aplicam os seeds) consigam impor a operação autônoma por conta própria.

---

Integrado aos bootstrap seeds v2.0+

O EstreGenesis é uma biblioteca de prompts de harness bootstrap e seeds
que copia 6 arquivos em 3 tiers — Master/Lite/Compact × EN/KO — para um novo projeto,
executa uma entrevista de bootstrap + geração automática de AGENTS.md,
e os módulos v2.0 (Constellation) e v2.3 (Superscalar) também já estão integrados a todos os 6 seeds,
então basta copiar os seeds para incluir ambos os módulos + o princípio de execução autônoma.

• Master: texto completo do princípio central #12 (Constellation) + #13 (Superscalar) + #14 (execução autônoma) + § Constellation + § Execution Scheduling.
• Lite/Compact: versão condensada dos mesmos princípios + seções centrais.
• Imposição consistente de operação autônoma em todos os tiers, verificável com grep.

---

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

Texto dos módulos:
Constellation.md
Superscalar.md

Changelog: CHANGELOG.md