PigeonStack: a Codex multi-agent workflow

Routine execution goes to Luna. Ordinary proposals, plans, local design, routine rule updates, upstream adaptations, and bounded consultations go directly to a fresh Sol Senior Executor at medium. Luna-failure takeovers also start at Sol medium. For the same unresolved problem, proceed through Sol high and xhigh before Astra high; an ordinary Sol medium or high assignment does not skip to Astra. Send master or system architecture, key interface and data-contract design, and consequential tradeoffs directly to Astra. Keep core architecture decisions out of Luna's scope. A technical-document label or Primary uncertainty alone does not trigger Astra. Optional read-only Astra consultation is available for a critical design question, a question that remains unresolved after Sol xhigh reports failure or reaches its 30-minute assessment, or an explicit task-specific user model request. Ordinary consultations start with Sol at medium. The Primary dispatches every consultation and child. Explicit task-specific user model and effort selections remain authoritative. Takeovers use the general execution role with an explicit model and effort. No role IDs or runtime permissions change. Actual model access depends on the Codex host and account.

When an executor reports that it cannot solve the problem, advance immediately to the next tier. Otherwise, the Primary assesses unresolved work 30 minutes after first dispatch at that model and effort tier. A retry or replacement at the same tier does not reset its clock. Carry evidence, failed attempts, and total elapsed time across upgrades. Existing waits are interruptible; 30 minutes is an assessment point, not a hard delay.

When routine work starts at Luna, the escalation path is Luna max, Sol medium, Sol high, Sol xhigh, Astra high, and a fresh Astra child at xhigh. Direct ordinary assignments start at Sol medium; critical design starts at Astra high. A successful tier ends the path. Each new task starts at its role's default unless the user explicitly selects a model or effort. Only a handoff for the same unresolved task advances to the next tier; same-tier retries or replacements keep that tier and its clock. The Senior Executor and Expert choose, implement, and verify a complete solution, then return the result and evidence to the Primary for final acceptance. User-selected Astra assignments follow the same high-to-xhigh limit. Ordinary webpage implementation and refactoring remain with Luna regardless of size. External blockers, including unavailable models or effort levels, credentials, access, permissions, or services, do not trigger reasoning escalation. If Astra at xhigh cannot resolve the problem or it remains unresolved at its 30-minute assessment, stop and report the actual limit or missing evidence. Do not automatically escalate Astra to max or ultra, or restart the cycle. A confirmed healthy long-running command is not a reasoning failure and continues through its existing observation loop. See MODELS.md for model IDs and role details.

ComputerUse actions stay with the Primary because child tools do not expose ComputerUse. Do not delegate actions requiring ComputerUse. A Senior Executor or Expert may request a named UI action and its observed result, then continue the same problem. This asks the Primary for an observation, not for a solution. Text, code, CLI, and API work remain delegable. The rule adds no tools or permission flow.

Prioritize the authorized normal business workflow through existing entry points. When an actual bug occurs or is reported, retain sufficient evidence, diagnose and repair the cause within scope, then rerun the affected real workflow and targeted regression checks. Address the bug when encountered, without waiting for the whole workflow to finish. Block only affected and dependent actions, and continue independent valid work. Report any outcome that an unavailable workflow prevents you from verifying. Targeted regression does not authorize a full test suite.

During normal task work, reuse existing scripts, CLIs, and business entry points. A minimal tool may help with repeated deterministic work only when the need is observed and authorized. Give the responsible agent a way to inspect the real result. Before escalating models, distinguish gaps in tools, feedback, or the environment from reasoning failures. At completion, use evidence already collected to identify recurring mistakes and improve the smallest relevant code, tool, skill, or rule within scope. Record unrelated findings in the existing project record. These habits add no mandatory project scan, report, skill, harness, validation gate, or automatic retrospective.

A validation gate is a mandatory check that must pass before an action can proceed. Add a new gate only for an evidence-confirmed problem or an explicit current requirement. An unverified hypothesis or hypothetical future failure cannot become a new gate or prerequisite. A confirmed bug does not automatically require a gate. If needed, scope the gate to the affected action and boundary, and verify that it catches the failure or enforces the requirement without unnecessarily blocking valid work. Existing required checks, explicit current requirements, and safety, permission, and data-integrity boundaries remain in force before any bug occurs.