Model: openai/gpt-5.4
Generated: 2026-04-01
Book: Claude Code VS OpenCode: Architecture, Design and The Road Ahead
Chapter: 10 — Oh-My-OpenCode’s Innovations
Token Usage: ~4,200 input + ~1,050 output

10.1 Three-Layer Orchestration

Oh-My-OpenCode’s most important innovation is not a single agent, a single hook, or a single model choice. It is the decision to organize coding work as a three-layer orchestration stack. In practical terms, OMO treats software work less like “one assistant answering a request” and more like “a small engineering organization with planning, management, and execution roles.” That distinction explains much of its architecture.

graph TB
    subgraph "Layer 1: Planning"
        P["Prometheus<br/>📝 Plan Generator"] 
        Met["Metis<br/>🔍 Pre-Analyzer"]
        Mom["Momus<br/>✅ Plan Reviewer"]
        Met -->|"hidden intentions"| P
        P -->|"plan draft"| Mom
        Mom -->|"approved plan"| Atlas
    end
    
    subgraph "Layer 2: Execution"
        Atlas["Atlas<br/>🎯 Conductor"]
    end
    
    subgraph "Layer 3: Workers"
        Atlas -->|"visual task"| SJ["Sisyphus-Junior<br/>⚡ Task Executor"]
        Atlas -->|"deep problem"| Hep["Hephaestus<br/>🔨 Deep Worker"]
        Atlas -->|"need advice"| Ora["Oracle<br/>👁️ Read-Only Consultant"]
        Atlas -->|"search external"| Lib["Librarian<br/>📚 External Search"]
        Atlas -->|"search codebase"| Exp["Explore<br/>🔎 Fast Search"]
    end
    
    Atlas -.->|"📓 wisdom"| NB["Notepad System<br/>learnings / decisions / issues"]
    NB -.->|"inject to all"| SJ
    NB -.->|"inject to all"| Hep
    
    style Atlas fill:#ff6b6b,color:#fff
    style P fill:#4a9eff,color:#fff
    style Ora fill:#ffd43b,color:#000

The first layer is Planning. Here the central agents are Prometheus, Metis, and Momus. Prometheus is not merely a planner that writes markdown checklists. Its prompt system is explicitly interview-driven. It asks questions, clarifies scope, and converts vague user requests into a structured plan. This matters because many agent failures begin before implementation: the system answers the wrong question because it never modeled the real problem well enough. Prometheus is designed to reduce that failure mode by acting like a strategic consultant rather than an eager coder.

But OMO does not trust a planner alone. Before Prometheus finalizes a work plan, Metis performs a pre-analysis pass. In Greek mythology, Metis represents wisdom and cunning; in OMO, that translates into catching hidden intentions, unspoken constraints, missing acceptance criteria, implicit assumptions, and likely failure points. This is a notable design move. In textbook CS terms, it resembles an additional validation phase inserted before a plan is committed. Instead of assuming the first plan is good, OMO introduces a dedicated agent whose job is to ask, “What did the planner miss?”

Then comes Momus, the critic. Momus is not optional window dressing. In high-accuracy mode, Prometheus must loop until Momus returns an approval verdict, typically the literal “OKAY.” This mandatory retry loop is one of OMO’s most revealing design choices. Many agent systems contain review prompts, but few make the review agent a real gate. OMO does. The result is that plan quality is treated as an enforceable constraint rather than a polite suggestion. That is a substantial difference from systems where planning and critique are merged into one model call.

The second layer is Execution, and the key figure is Atlas. If the planning layer decides what should happen, Atlas decides how it should happen operationally. Atlas decomposes plans into executable units, identifies which parts can run in parallel, dispatches work to specialized subagents, collects results, verifies completion, and maintains working memory through the notepad system. In distributed-systems language, Atlas acts like a runtime scheduler plus verifier. In management language, Atlas is the project lead. It does not simply hand out tasks once. It keeps checking whether the tasks were actually done, whether the evidence is good enough, and whether accumulated knowledge should be passed downstream.

This middle layer is crucial because it solves the gap between plan generation and real-world execution. A good plan alone does not guarantee a good run. Work must be chunked correctly, delegated to the right specialists, synchronized, and verified. Atlas is therefore the control plane of OMO’s organization model.

The third layer is the Worker layer, where specialized agents perform the actual task-level labor. The user-highlighted examples show the design clearly. Sisyphus-Junior, typically aligned with Sonnet 4.5, is the focused executor: narrow, disciplined, and meant to finish a bounded task without turning into a general coordinator. Oracle, commonly resolved toward GPT-5.2 or equivalent high-reasoning models, is intentionally read-only. It is the expensive consultant for debugging, architecture, and difficult judgment calls. Librarian, often mapped to GLM-4.7, searches external references and documentation. Explore, mapped through a fast search-oriented model such as Grok Code Fast or Haiku-class fallbacks, is optimized for codebase exploration. Hephaestus, associated with GPT-5.3 Codex, is the deep worker for hard engineering tasks requiring thorough autonomous execution.

Those are not the only agents in the system. OMO’s broader roster includes Sisyphus, Prometheus, Metis, Momus, Atlas, Oracle, Librarian, Explore, Hephaestus, Multimodal-Looker, and category-driven Sisyphus-Junior variants. The exact count is less important than the principle: OMO explicitly separates orchestration roles from execution roles.

This is what makes the architecture novel. Most coding agents still behave like a single polymath model that alternates between planning, searching, coding, and summarizing in one long context window. OMO instead distributes cognition across role-specific agents. That has several benefits.

First, it reduces role conflict. A planner can stay conservative while an executor stays action-oriented. Second, it allows model specialization. Different roles can use different fallback chains and effort levels. Third, it enables parallelism. Atlas can dispatch multiple workers at once rather than forcing a single sequential thought stream. Fourth, it improves auditability. Because the planner, critic, and executor are distinct, the system can reason about failure more clearly: was the problem misunderstanding, planning, execution, or verification?

There is also a philosophical implication. OMO is not merely adding more agents because more agents sound impressive. It is implementing a theory of software work: complex tasks should pass through distinct cognitive phases—intent extraction, pre-analysis, criticism, decomposition, execution, and verification. In classical software engineering, similar phase distinctions appear in requirements analysis, design review, implementation, and QA. OMO compresses those phases into an agent runtime.

That is why the three-layer architecture deserves to be seen as a real innovation. It is not just a multi-agent feature list. It is an argument that good coding agents should resemble organizations, not monologues.