Subagentes OoO/especulación (Superscalar) + liveboard A2A entre agentes (Constellation) — dos módulos para operar agentes múltiples de codificación con IA

EstreGenesis, presentado en una publicación anterior, añadió dos módulos grandes a lo largo de las versiones 2.0~2.3.
Ambos son intentos de llevar la operación múltiple de agentes de codificación con IA a un nivel superior.

---

Constellation — comunicación en tiempo real entre ventanas de conversación de agentes (liveboard A2A por WebSocket)

El concepto existente de subagente seguía un modelo padre-hijo: el agente principal creaba (spawn) hijos y recibía sus resultados en una estructura unidireccional. No existía comunicación directa con la ventana de conversación de otros agentes.

Constellation rompe ese límite:

• Puente A2A (Agent-to-Agent) por WebSocket — cada agente (Claude Code · Codex · Cursor, etc.) mantiene su propia sesión de IDE tal cual, mientras un proceso daemon separado se conecta al liveboard por WebSocket y envía mensajes a las ventanas de conversación de otros agentes. Es un modelo peer-to-peer entre nodos iguales, no una dependencia padre-hijo. (Las pruebas reales solo se confirmaron hasta Claude/Codex. Para operar, cada agente requiere modo de aprobación automática, AutoMode.)
• Separación de roles — main (PM orquestador) / local (worker) / upstream (peer de agente autónomo como Hermes Agent) / collab (peer colaborador externo). Cuando main envía una Delegate (delegación) a un worker, el worker la ejecuta de inmediato en su propio IDE y responde con WorkerReport (reporte).
• Compatibilidad con agentes basados en turnos — patrón para runtimes como Claude Code, donde la conversación termina cuando termina un turno: el daemon puente (inbox/outbox por file I/O) conserva los mensajes, y un self-wake watcher (vigilante que se despierta a sí mismo) inicia el siguiente turno al llegar un mensaje. Puede quedar desacoplado de la sesión de shell y residente en segundo plano.
• Dashboard — el trabajo, los mensajes y el estado de todos los agentes se ven en una sola pantalla. Solo con el tablero ya es posible reconstruir el flujo.

Se incluye como especificación en Constellation.md + componentes constellation/*.eux,
y aun sin descargar un runtime privado, todo el protocolo está organizado en el propio texto.

---

Superscalar — llevar arquitectura de procesadores a la ejecución de agentes

El ultracode de Claude Opus 4.8, anunciado hoy (5/29), asume la operación de grandes cantidades de subagentes,
y para que eso sea realmente eficiente hace falta una planificación que decida qué tareas lanzar en paralelo y cuántas (dispatch).
Superscalar toma un problema que la arquitectura de CPU de los años 1960~80 ya había resuelto — ejecución simultánea de múltiples instrucciones (multi-issue / superscalar) · ejecución fuera de orden al cumplirse dependencias (out-of-order, OoO) · ejecución predictiva basada en resultados de bifurcación (speculation) — y lo incorpora tal cual a la planificación de tareas de agentes.

• 5 dimensiones formales de issue_width — la cantidad de subagentes que se lanzan al mismo tiempo se determina como el mínimo de cinco restricciones:
  1. effort band por dificultad de tarea propuesto por Anthropic (estimación del tamaño del trabajo)
  2. límite superior de pace_mode (modos de velocidad de ejecución Cautious · Proactive · Burst · Sprint)
  3. throughput según la Ley de Little (teoría de colas — velocidad de revisión del PM ÷ duración promedio de la tarea)
  4. límite WIP de Kanban (trabajo en curso al mismo tiempo ≈ tamaño del equipo + 1)
  5. autonomy_available_workers (cantidad de workers con modo de aprobación automática activado — si no, aparece una ventana de permiso del usuario en cada acción y el throughput colapsa)
• Ejecución OoO + garantía de orden en los resultados (patrón Tomasulo·ROB) — si se cumplen las dependencias, primero se ejecutan las tareas listas, ignorando el declared order (orden declarado). Aun así, el PM hace el retire (completado/merge) de los resultados en el orden original, por lo que desde la perspectiva del usuario se ven en el orden declarado. Sigue tal cual el patrón del paper Reorder Buffer de Smith-Pleszkun de 1988.
• Speculation (opt-in, aplicando las lecciones de Spectre) — anuncio en 2 etapas + ack: "consider X" → ack del usuario → "execute X (speculative lane)" → si la predicción falla, se descarta por completo el worktree (carpeta de trabajo aislada). Se fuerzan los tres elementos de Toyota Andon (visibilización Jidoka): señal visual · cordón de parada de emergencia · log de retrospectiva de errores.
• Compuerta de costo-beneficio — detecta automáticamente el punto donde el overhead de spawn pasa a ser menor que el beneficio del paralelismo, alrededor del crossover de horizonte de ~30-60k tokens. Las tareas pequeñas caen de forma natural a ejecución inline.

Fue validado con tres ejes de deep research (canon académico de arquitectura de procesadores / casos industriales de harness de agentes / comunicación de trabajo y administración),
y se complementó con el texto de Superscalar.md y los logs de prueba interna Stage 1 (dogfooding) en §11.

---

Base — principio absoluto de ejecución autónoma

Los dos módulos anteriores parten de la premisa de la operación autónoma.
Si "el throughput se derrumba esperando la confirmación del usuario", ninguno de los dos tiene sentido.
Por eso EstreGenesis 2.3 formalizó lo siguiente como principio absoluto:

Los siguientes pasos ya definidos —secuencia de fases, track planned, elementos liberados de blocked, cola de in-order retire— deben avanzar sin preguntar,
y las compuertas de usuario se limitan solo a estas cuatro:

1. Pérdida o publicación externa (push · deploy · send · delete)
2. Momento de una nueva decisión importante de bifurcación (etapa de decisión RRP/diseño; sin embargo, la ejecución de las fases A/B/C derivadas de eso es ejecución ya decidida)
3. Coordinación del momento de un deploy que requiere reinicio (la aplicación en sí es autónoma; solo se coordina el momento del reinicio)
4. Steering explícito del usuario (cuando el usuario indica directamente un cambio de dirección)

Patrones como "¿Comenzamos la Fase A?", que vuelven a preguntar por una ejecución ya decidida, se denominan una violación de la operación autónoma,
y esto quedó formalizado como principio clave en seis seeds, para que los proyectos downstream (que aplican esos seeds) puedan imponer por sí solos la operación autónoma.

---

Integrado en los seeds de bootstrap v2.0+

EstreGenesis es un harness de bootstrap y biblioteca de prompts seed;
permite copiar 6 archivos de 3 tiers, Master/Lite/Compact × EN/KO, a un proyecto nuevo,
realizar una entrevista de bootstrap + generar automáticamente AGENTS.md,
y los módulos v2.0 (Constellation) y v2.3 (Superscalar) también quedaron integrados en los 6 seeds,
de modo que con solo copiar los seeds ya se incluyen ambos módulos + el principio de ejecución autónoma.

• Master: texto completo del principio clave #12 (Constellation) + #13 (Superscalar) + #14 (ejecución autónoma) + § Constellation + § Execution Scheduling.
• Lite/Compact: compresión de los mismos principios + secciones clave.
• En todos los tiers, imposición consistente de operación autónoma verificable con grep.

---

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

Texto de los módulos:
Constellation.md
Superscalar.md

Changelog: CHANGELOG.md