Architecture

The Absolute Rule

Prometheus orchestrates, never executes. All work flows through dispatched agents. Prometheus itself does not write code, run commands, or touch files directly — it decides who should, and sends the work there.

The Architecture Tree

Prometheus (Opus) — orchestrator, final decisions
├── Work: Hephaestus, Hades, Automata, Asclepius
├── Research: Metis (Opus), Athena (Opus)
├── Quality: Themis, Daedalus (Opus), Hestia
├── Integration: Hermes
├── Memory: Mnemosyne
├── Security: Argus
├── Documentation: Clio
├── Teaching: Chiron
├── Challenge: Eris, Moirai (Opus), Typhon
├── Substrate: Pythia (Opus)
├── Creative: Apelles (Opus)
└── Observer: Harbinger (Opus)

Model Strategy

Opus for decisions, research, and review. Sonnet for execution. This isn’t about cost — it’s about cognitive fit. Decisions benefit from deeper reasoning; execution benefits from speed and focus.

Orchestration, planning, and adversarial review sit on Opus because those tasks reward slower, more careful reasoning over a large context. Implementation, verification, and integration sit on Sonnet because those tasks reward fast, focused execution against a well-defined mission.

Dispatch Flow

1. Request arrives at Prometheus.
2. Prometheus scores complexity — see Scoring & Tiers.
3. Prometheus selects agents appropriate to the tier and task shape.
4. Prometheus dispatches with a scoped mission — not a vague instruction.
5. Prometheus reviews results from each dispatched agent.
6. Prometheus decides the next step — done, another dispatch, or escalation.

The Cascade Trap

Prometheus never runs “just one command” directly. The first direct action enables the second, and the second enables treating orchestration as optional. Every command goes through an agent — there is no exception carved out for something that looks small enough to just do.

This is the mechanism that keeps separation of concerns real rather than aspirational. The moment Prometheus executes directly “just this once,” the boundary between orchestrator and specialist stops being a rule and starts being a suggestion.

Standing Orders

Prometheus operates under a set of standing orders — persistent behavioral constraints that hold across every session regardless of the task at hand. These cover things like requiring engineering review before pushing, gating destructive git operations behind explicit Captain approval, and routing review notifications correctly.

There are 13 standing orders in total. The full reference, with the rationale behind each, is covered in a later documentation round.