docs/guide/orchestration.md
Oh My OpenAgent's orchestration system transforms a simple AI agent into a coordinated development team through separation of planning and execution.
| Complexity | Approach | When to Use |
|---|---|---|
| Simple | Just prompt | Simple tasks, quick fixes, single-file changes |
| Complex + Lazy | Type ulw or ultrawork | Complex tasks where explaining context is tedious. Agent figures it out. |
| Complex + Precise | @plan → /start-work | Precise, multi-step work requiring true orchestration. Prometheus plans, Atlas executes. |
Decision Flow:
Is it a quick fix or simple task?
└─ YES → Just prompt normally
└─ NO → Is explaining the full context tedious?
└─ YES → Type "ulw" and let the agent figure it out
└─ NO → Do you need precise, verifiable execution?
└─ YES → Use @plan for Prometheus planning, then /start-work
└─ NO → Just use "ulw"
The orchestration system uses a three-layer architecture that solves context overload, cognitive drift, and verification gaps through specialization and delegation.
flowchart TB
subgraph Planning["Planning Layer (Human + Prometheus)"]
User[(" User")]
Prometheus[" Prometheus
(Planner)
claude-opus-4-7 / gpt-5.4 / glm-5"]
Metis[" Metis
(Consultant)
claude-opus-4-7 / gpt-5.4 / glm-5"]
Momus[" Momus
(Reviewer)
gpt-5.4 / claude-opus-4-7 / gemini-3.1-pro / glm-5"]
end
subgraph Execution["Execution Layer (Orchestrator)"]
Orchestrator[" Atlas
(Conductor)
claude-sonnet-4-6 / kimi-k2.5 / gpt-5.4 / minimax-m2.7"]
end
subgraph Workers["Worker Layer (Specialized Agents)"]
Junior[" Sisyphus-Junior
(Task Executor)
claude-sonnet-4-6 / kimi-k2.5 / gpt-5.4 / minimax-m2.7"]
Oracle[" Oracle
(Architecture)
gpt-5.4 / gemini-3.1-pro / claude-opus-4-7 / glm-5"]
Explore[" Explore
(Codebase Grep)
gpt-5.4-mini-fast / minimax-m2.7-highspeed / claude-haiku-4-5"]
Librarian[" Librarian
(Docs/OSS)
gpt-5.4-mini-fast / minimax-m2.7-highspeed / claude-haiku-4-5"]
Frontend[" visual-engineering
(category + frontend-ui-ux)
gemini-3.1-pro / glm-5 / claude-opus-4-7"]
end
User -->|"Describe work"| Prometheus
Prometheus -->|"Consult"| Metis
Prometheus -->|"Interview"| User
Prometheus -->|"Generate plan"| Plan[".sisyphus/plans/*.md"]
Plan -->|"High accuracy?"| Momus
Momus -->|"OKAY / REJECT"| Prometheus
User -->|"/start-work"| Orchestrator
Plan -->|"Read"| Orchestrator
Orchestrator -->|"task(category=deep/quick/unspecified-*)"| Junior
Orchestrator -->|"call_omo_agent(subagent_type=oracle)"| Oracle
Orchestrator -->|"call_omo_agent(subagent_type=explore)"| Explore
Orchestrator -->|"call_omo_agent(subagent_type=librarian)"| Librarian
Orchestrator -->|"task(category=visual-engineering, load_skills=[frontend-ui-ux])"| Frontend
Junior -->|"Results + Learnings"| Orchestrator
Oracle -->|"Advice"| Orchestrator
Explore -->|"Code patterns"| Orchestrator
Librarian -->|"Documentation"| Orchestrator
Frontend -->|"UI code"| Orchestrator
Model labels above show the current fallback stacks from src/shared/model-requirements.ts, not marketing names.
Prometheus is not just a planner, it's an intelligent interviewer that helps you think through what you actually need. It is READ-ONLY - can only create or modify markdown files within .sisyphus/ directory.
The Interview Process:
stateDiagram-v2
[*] --> Interview: User describes work
Interview --> Research: Launch explore/librarian agents
Research --> Interview: Gather codebase context
Interview --> ClearanceCheck: After each response
ClearanceCheck --> Interview: Requirements unclear
ClearanceCheck --> PlanGeneration: All requirements clear
state ClearanceCheck {
[*] --> Check
Check: Core objective defined?
Check: Scope boundaries established?
Check: No critical ambiguities?
Check: Technical approach decided?
Check: Test strategy confirmed?
}
PlanGeneration --> MetisConsult: Mandatory gap analysis
MetisConsult --> WritePlan: Incorporate findings
WritePlan --> HighAccuracyChoice: Present to user
HighAccuracyChoice --> MomusLoop: User wants high accuracy
HighAccuracyChoice --> Done: User accepts plan
MomusLoop --> WritePlan: REJECTED - fix issues
MomusLoop --> Done: OKAY - plan approved
Done --> [*]: Guide to /start-work
Intent-Specific Strategies:
Prometheus adapts its interview style based on what you're doing:
| Intent | Prometheus Focus | Example Questions |
|---|---|---|
| Refactoring | Safety - behavior preservation | "What tests verify current behavior?" "Rollback strategy?" |
| Build from Scratch | Discovery - patterns first | "Found pattern X in codebase. Follow it or deviate?" |
| Mid-sized Task | Guardrails - exact boundaries | "What must NOT be included? Hard constraints?" |
| Architecture | Strategic - long-term impact | "Expected lifespan? Scale requirements?" |
Before Prometheus writes the plan, Metis catches what Prometheus missed:
Why Metis Exists:
The plan author (Prometheus) has "ADHD working memory" - it makes connections that never make it onto the page. Metis forces externalization of implicit knowledge.
For high-accuracy mode, Momus validates plans against four core criteria:
The Momus Loop:
Momus only says "OKAY" when:
If REJECTED, Prometheus fixes issues and resubmits. No maximum retry limit.
Atlas is like an orchestra conductor: it doesn't play instruments, it ensures perfect harmony.
flowchart LR
subgraph Orchestrator["Atlas"]
Read["1. Read Plan"]
Analyze["2. Analyze Tasks"]
Wisdom["3. Accumulate Wisdom"]
Delegate["4. Delegate Tasks"]
Verify["5. Verify Results"]
Report["6. Final Report"]
end
Read --> Analyze
Analyze --> Wisdom
Wisdom --> Delegate
Delegate --> Verify
Verify -->|"More tasks"| Delegate
Verify -->|"All done"| Report
Delegate -->|"background=false"| Workers["Workers"]
Workers -->|"Results + Learnings"| Verify
What Atlas CAN do:
What Atlas MUST delegate:
The power of orchestration is cumulative learning. After each task:
This prevents repeating mistakes and ensures consistent patterns.
Notepad System:
.sisyphus/notepads/{plan-name}/
├── learnings.md # Patterns, conventions, successful approaches
├── decisions.md # Architectural choices and rationales
├── issues.md # Problems, blockers, gotchas encountered
├── verification.md # Test results, validation outcomes
└── problems.md # Unresolved issues, technical debt
Junior is the workhorse that actually writes code. Key characteristics:
Why the fallback chain is sufficient:
Junior doesn't need to be the smartest - it needs to be reliable. With:
Even a mid-tier execution model works when the harness is strict. The current fallback order is claude-sonnet-4-6 → kimi-k2.5 → gpt-5.4 → minimax-m2.7 → big-pickle. The intelligence is in the system, not a single worker model.
The hook system ensures Junior never stops halfway:
[SYSTEM REMINDER - TODO CONTINUATION]
You have incomplete todos! Complete ALL before responding:
- [ ] Implement user service ← IN PROGRESS
- [ ] Add validation
- [ ] Write tests
DO NOT respond until all todos are marked completed.
This "boulder pushing" mechanism is why the system is named after Sisyphus.
The Problem with Model Names:
// OLD: Model name creates distributional bias
task({ agent: "gpt-5.4", prompt: "..." }); // Model knows its limitations
task({ agent: "claude-opus-4-7", prompt: "..." }); // Different self-perception
The Solution: Semantic Categories:
// NEW: Category describes INTENT, not implementation
task({ category: "ultrabrain", prompt: "..." }); // "Think strategically"
task({ category: "visual-engineering", prompt: "..." }); // "Design beautifully"
task({ category: "quick", prompt: "..." }); // "Just get it done fast"
| Category | Default config | Runtime fallback order | When to Use |
|---|---|---|---|
visual-engineering | google/gemini-3.1-pro high | gemini-3.1-pro → glm-5 → claude-opus-4-7 → glm-5 → k2p5 | Frontend, UI/UX, design, styling, animation |
ultrabrain | openai/gpt-5.4 xhigh | gpt-5.4 → gemini-3.1-pro → claude-opus-4-7 → glm-5 | Deep logical reasoning, complex architecture decisions |
deep | openai/gpt-5.4 medium | gpt-5.4 → claude-opus-4-7 → gemini-3.1-pro | Goal-oriented autonomous problem-solving, thorough research |
artistry | google/gemini-3.1-pro high | gemini-3.1-pro → claude-opus-4-7 → gpt-5.4 | Highly creative or artistic tasks, novel ideas |
quick | openai/gpt-5.4-mini | gpt-5.4-mini → claude-haiku-4-5 → gemini-3-flash → minimax-m2.7 → gpt-5-nano | Trivial tasks, single file changes, typo fixes |
unspecified-low | anthropic/claude-sonnet-4-6 | claude-sonnet-4-6 → gpt-5.3-codex → kimi-k2.5 → gemini-3-flash → minimax-m2.7 | Tasks that don't fit other categories, low effort |
unspecified-high | anthropic/claude-opus-4-7 max | claude-opus-4-7 → gpt-5.4 → glm-5 → k2p5 → kimi-k2.5 | Tasks that don't fit other categories, high effort |
writing | kimi-for-coding/k2p5 | gemini-3-flash → kimi-k2.5 → claude-sonnet-4-6 → minimax-m2.7 | Documentation, prose, technical writing |
Skills prepend specialized instructions to subagent prompts:
// Category + Skill combination
task(
(category = "visual-engineering"),
(load_skills = ["frontend-ui-ux"]), // Adds UI/UX expertise
(prompt = "..."),
);
task(
(category = "deep"),
(load_skills = ["playwright"]), // Adds browser automation expertise
(prompt = "..."),
);
Method 1: Switch to Prometheus Agent (Tab → Select Prometheus)
1. Press Tab at the prompt
2. Select "Prometheus" from the agent list
3. Describe your work: "I want to refactor the auth system"
4. Answer interview questions
5. Prometheus creates plan in .sisyphus/plans/{name}.md
Method 2: Use @plan Command (in Sisyphus)
1. Stay in Sisyphus (default agent)
2. Type: @plan "I want to refactor the auth system"
3. The @plan command automatically switches to Prometheus
4. Answer interview questions
5. Prometheus creates plan in .sisyphus/plans/{name}.md
Which Should You Use?
| Scenario | Recommended Method | Why |
|---|---|---|
| New session, starting fresh | Switch to Prometheus agent | Clean mental model - you're entering "planning mode" |
| Already in Sisyphus, mid-work | Use @plan | Convenient, no agent switch needed |
| Want explicit control | Switch to Prometheus agent | Clear separation of planning vs execution contexts |
| Quick planning interrupt | Use @plan | Fastest path from current context |
Both methods trigger the same Prometheus planning flow. The @plan command is simply a convenience shortcut.
What Happens When You Run /start-work:
User: /start-work
↓
[start-work hook activates]
↓
Check: Does .sisyphus/boulder.json exist?
↓
├─ YES (existing work) → RESUME MODE
│ - Read the existing boulder state
│ - Calculate progress (checked vs unchecked boxes)
│ - Inject continuation prompt with remaining tasks
│ - Atlas continues where you left off
│
└─ NO (fresh start) → INIT MODE
- Find the most recent plan in .sisyphus/plans/
- Create new boulder.json tracking this plan
- Switch session agent to Atlas
- Begin execution from task 1
Session Continuity Explained:
The boulder.json file tracks:
Example Timeline:
Monday 9:00 AM
└─ @plan "Build user authentication"
└─ Prometheus interviews and creates plan
└─ User: /start-work
└─ Atlas begins execution, creates boulder.json
└─ Task 1 complete, Task 2 in progress...
└─ [Session ends - computer crash, user logout, etc.]
Monday 2:00 PM (NEW SESSION)
└─ User opens new session (agent = Sisyphus by default)
└─ User: /start-work
└─ [start-work hook reads boulder.json]
└─ "Resuming 'Build user authentication' - 3 of 8 tasks complete"
└─ Atlas continues from Task 3 (no context lost)
Atlas is automatically activated when you run /start-work. You don't need to manually switch to Atlas.
Quick Comparison:
| Aspect | Hephaestus | Sisyphus + ulw / ultrawork |
|---|---|---|
| Model | gpt-5.4 (medium) | claude-opus-4-7 / kimi-k2.5 / gpt-5.4 / glm-5 depending on setup |
| Approach | Autonomous deep worker | Keyword-activated ultrawork mode |
| Best For | Complex architectural work, deep reasoning | General complex tasks, "just do it" scenarios |
| Planning | Self-plans during execution | Uses Prometheus plans if available |
| Delegation | Heavy use of explore/librarian agents | Uses category-based delegation |
| Temperature | 0.1 | 0.1 |
When to Use Hephaestus:
Switch to Hephaestus (Tab → Select Hephaestus) when:
Deep architectural reasoning needed
Complex debugging requiring inference chains
Cross-domain knowledge synthesis
You specifically want GPT-5.4 reasoning
When to Use Sisyphus + ulw:
Use the ulw keyword in Sisyphus when:
You want the agent to figure it out
Complex but well-scoped tasks
You're feeling lazy (officially supported use case)
You want to leverage existing plans
ulw mode can use itRecommendation:
ulw keyword in Sisyphus. It's the default path and works excellently for 90% of complex tasks.You can control related features in oh-my-openagent.json:
{
"sisyphus_agent": {
"disabled": false, // Enable Atlas orchestration (default: false)
"planner_enabled": true, // Enable Prometheus (default: true)
"replace_plan": true, // Replace default plan agent with Prometheus (default: true)
},
// Hook settings (add to disable)
"disabled_hooks": [
// "start-work", // Disable execution trigger
// "prometheus-md-only" // Remove Prometheus write restrictions (not recommended)
],
}
Prometheus enters interview mode by default. It will ask you questions about your requirements. Answer them, then say "make it a plan" when ready.
Either:
.sisyphus/plans/ → Create one with Prometheus first.sisyphus/boulder.json and retryType exit or start a new session. Atlas is primarily entered via /start-work - you don't typically "switch to Atlas" manually.
Nothing functional. Both invoke Prometheus. @plan is a convenience command while switching agents is explicit control. Use whichever feels natural.
For most tasks: Type ulw in Sisyphus.
Use Hephaestus when: You specifically need GPT-5.4's reasoning style for deep architectural work or complex debugging.