Deep-Dive DD-06 — oh-my-opencode: Meta-Harness Architecture

Course: Master Course · Deep-Dive: DD-06 · Duration: 60 min · Prerequisites: Modules 0–12, DD-01–05

The canonical meta-harness. Sisyphus + Prometheus planner + Atlas orchestrator + Junior workers. Two-mode design (lazy vs precise). The subagent taxonomy is worth studying alone.


The Subject

oh-my-opencode is the meta-harness referenced throughout the course (Module 0.2, Module 1.3). It does not replace OpenCode — it layers a planning/orchestration hierarchy on top of it. The contribution is the subagent hierarchy, not the loop (which is inherited from OpenCode and so scores the same on Modules 1, 5, and 11 as DD-03). What changes is Module 10 (subagent orchestration) and, as a consequence, Module 9 (verification, in precise mode).

On Module 0.2's meta-harness taxonomy, oh-my-opencode is the reference example of a harness whose entire value-add sits above the base harness's loop. Pi is the loop; OpenCode is the loop + client/server; oh-my-opencode is OpenCode + a hierarchy that decomposes work before the loop sees it.

Architecture — The Hierarchy

Sisyphus (outer agent — the entry point)
  │
  ├── Prometheus (PLANNER — produces the plan)
  │     uses agents-as-tools: returns structured plan to Atlas
  │
  ├── Atlas (ORCHESTRATOR — decomposes plan into tasks)
  │     uses worktree: dispatches Juniors in parallel
  │
  └── Junior × N (WORKERS — execute tasks in parallel git worktrees)
        returns summaries (1-2k tokens) to Atlas

This is the mixed subagent pattern from Module 1.3: Prometheus→Atlas is agents-as-tools (synchronous, structured summary returns). Atlas→Junior is worktree (parallel, mergeable, isolated execution). The mix is itself the design decision — neither pure agents-as-tools nor pure worktree would be correct. The planner needs structured returns to reason; the workers need isolation to execute without clobbering each other. The hierarchy uses the right pattern at the right layer.

Per-Agent Model Assignment

oh-my-opencode assigns different models to different hierarchy levels: a strong model for Prometheus (planning needs reasoning depth), cheaper models for Juniors (execution is more mechanical). This is cost-aware routing (Module 1.4, Fleet F03) at the single-harness scale — the same idea CSI generalizes to the fleet level. The economic argument: a 5-task plan run on a cheap model throughout costs less but plans poorly; run on a strong model throughout plans well but overpays for execution. Per-tier routing captures both.

Key Design Decisions

  1. Mixed hierarchy, not pure. The deliberate combination of agents-as-tools at the top (Prometheus→Atlas) and worktree at the bottom (Atlas→Junior). Module 1.3's two patterns, applied where each is correct.
  2. Summary-bound returns. Junior summaries are bounded to 1-2k tokens. Unbounded returns (Module 1.3's failure mode) would let a Junior flood Atlas's context and break the orchestrator. The bound is the safety property.
  3. Two-mode design. Lazy vs precise, chosen at task intake. Matching verification-loop depth to task complexity (Module 9) rather than applying full verification to every task.

Two-Mode Design — The Verification Loop

The mode is chosen at task intake based on a complexity assessment. This is a real-world realization of the tight-vs-loose verification loop (Module 9) — lazy = loose, precise = tight/staged. The decision is itself a Module 9 feature: most harnesses apply one verification depth uniformly; oh-my-opencode adapts.

Phase 4 — Security Audit

The multiplied attack surface: each Junior is an independent agent with its own context and its own copy of OpenCode's permissions. A compromised Junior (via injection in its scoped context) can use its scoped permissions to attack Atlas — by returning a poisoned summary, by consuming the worktree in a way that propagates on merge, or by exhausting the parallel budget. This is Module 2.4's per-subagent capability filtering concern made concrete.

Per-agent capability filtering (Module 2.4) is essential: a Junior should never have the same permissions as Prometheus. A Junior that can write to the plan store, or call Prometheus's planning tools, breaks the hierarchy's isolation. The fix is per-tier permission scoping — Juniors get execution-only permissions; Prometheus gets planning-only; Atlas gets orchestration-only. As-built, oh-my-opencode inherits OpenCode's flat session-scoped permissions, which is the gap.

Score & Synthesize: 38/60 (+4 vs OpenCode)

Module Score Key decision vs OpenCode
1 Loop 4 inherited from OpenCode =
2 Tools 4 inherited =
3 Context 4 inherited =
4 Memory 4 inherited =
5 Sandbox 4 inherited (Docker) =
6 Permission 3 inherited (session-scoped) =
7 Errors 3 inherited =
8 State 3 inherited =
9 Verification 3 precise mode's verification loop +1
10 Subagents 5 mixed hierarchy (highest in roster) +3
11 Observability 3 inherited =
12 Prompt 4 inherited =
TOTAL 38/60 +4

The +4 comes entirely from the hierarchy: +3 Module 10 (subagent orchestration — the highest score in the roster), +1 Module 9 (precise mode's verification loop). oh-my-opencode is the highest-scoring harness on subagent orchestration — it is the reference.

Architect's Verdict

oh-my-opencode optimizes for task decomposition via a mixed subagent hierarchy (Prometheus→Atlas→Junior) that combines agents-as-tools with worktree parallelism. It sacrifices simplicity (the hierarchy is complex to debug) and inherits OpenCode's flat permission model where per-tier scoping is needed. Build on it for complex, multi-step tasks where planning + parallel execution justify the overhead — it is the canonical meta-harness.

MLSecOps Relevance

The subagent hierarchy multiplies the attack surface: each Junior is an independent agent with its own context, and a compromised Junior can use its scoped permissions to attack Atlas via poisoned summaries or worktree side effects. Per-agent capability filtering (Module 2.4) is essential — a Junior should never have the same permissions as Prometheus.

3 things oh-my-opencode does better

  1. Mixed subagent hierarchy: the only harness that combines agents-as-tools (top) with worktree (bottom) in a studied way. Module 1.3's two patterns, correctly placed.
  2. Two-mode design: lazy vs precise, matching verification-loop depth (Module 9) to task complexity instead of applying one depth uniformly.
  3. Per-agent model assignment: cost-aware routing (strong model for planning, cheap for execution). Module 1.4's principle at the single-harness scale.

3 things to fix

  1. Per-subagent tracing (Module 10) — debugging the hierarchy is hard; add per-subagent structured logs so a failed Junior is identifiable without replay.
  2. Enforce per-Junior capability scoping (Module 2.4) — currently inherits OpenCode's flat permissions; a Junior should be execution-only.
  3. Add unbounded-return prevention (Module 1.3) — enforce the 1-2k summary bound at the harness layer, not just as a prompt instruction, so a misbehaving Junior cannot flood Atlas.

References

  1. oh-my-opencode source — the canonical meta-harness.
  2. DD-03 (OpenCode) — the base harness whose loop oh-my-opencode inherits.
  3. Module 0.2 — meta-harness taxonomy; the lineage map.
  4. Module 1.3 — subagent patterns; the mixed hierarchy (agents-as-tools + worktree).
  5. Module 1.4 — cost-aware per-tier model routing.
  6. Module 2.4 — per-subagent capability filtering (the needed fix).
  7. Module 9 — verification; lazy vs precise as tight-vs-loose verification depth.
  8. Module 10 — subagent orchestration; oh-my-opencode as the reference scorer.
# Deep-Dive DD-06 — oh-my-opencode: Meta-Harness Architecture

**Course**: Master Course · **Deep-Dive**: DD-06 · **Duration**: 60 min · **Prerequisites**: Modules 0–12, DD-01–05

> *The canonical meta-harness. Sisyphus + Prometheus planner + Atlas orchestrator + Junior workers. Two-mode design (lazy vs precise). The subagent taxonomy is worth studying alone.*

---

## The Subject

oh-my-opencode is the meta-harness referenced throughout the course (Module 0.2, Module 1.3). It does not replace OpenCode — it layers a planning/orchestration hierarchy on top of it. The contribution is the **subagent hierarchy**, not the loop (which is inherited from OpenCode and so scores the same on Modules 1, 5, and 11 as DD-03). What changes is Module 10 (subagent orchestration) and, as a consequence, Module 9 (verification, in precise mode).

On Module 0.2's meta-harness taxonomy, oh-my-opencode is the reference example of a harness whose entire value-add sits *above* the base harness's loop. Pi is the loop; OpenCode is the loop + client/server; oh-my-opencode is OpenCode + a hierarchy that decomposes work before the loop sees it.

## Architecture — The Hierarchy

```
Sisyphus (outer agent — the entry point)
  │
  ├── Prometheus (PLANNER — produces the plan)
  │     uses agents-as-tools: returns structured plan to Atlas
  │
  ├── Atlas (ORCHESTRATOR — decomposes plan into tasks)
  │     uses worktree: dispatches Juniors in parallel
  │
  └── Junior × N (WORKERS — execute tasks in parallel git worktrees)
        returns summaries (1-2k tokens) to Atlas
```

This is the **mixed subagent pattern** from Module 1.3: Prometheus→Atlas is agents-as-tools (synchronous, structured summary returns). Atlas→Junior is worktree (parallel, mergeable, isolated execution). The mix is itself the design decision — neither pure agents-as-tools nor pure worktree would be correct. The planner needs structured returns to reason; the workers need isolation to execute without clobbering each other. The hierarchy uses the right pattern at the right layer.

### Per-Agent Model Assignment

oh-my-opencode assigns different models to different hierarchy levels: a strong model for Prometheus (planning needs reasoning depth), cheaper models for Juniors (execution is more mechanical). This is cost-aware routing (Module 1.4, Fleet F03) at the single-harness scale — the same idea CSI generalizes to the fleet level. The economic argument: a 5-task plan run on a cheap model throughout costs less but plans poorly; run on a strong model throughout plans well but overpays for execution. Per-tier routing captures both.

## Key Design Decisions

1. **Mixed hierarchy, not pure.** The deliberate combination of agents-as-tools at the top (Prometheus→Atlas) and worktree at the bottom (Atlas→Junior). Module 1.3's two patterns, applied where each is correct.
2. **Summary-bound returns.** Junior summaries are bounded to 1-2k tokens. Unbounded returns (Module 1.3's failure mode) would let a Junior flood Atlas's context and break the orchestrator. The bound is the safety property.
3. **Two-mode design.** Lazy vs precise, chosen at task intake. Matching verification-loop depth to task complexity (Module 9) rather than applying full verification to every task.

## Two-Mode Design — The Verification Loop

- **Lazy mode**: Sisyphus delegates minimally. One plan, one execution. Fast, less thorough. For simple tasks where the cost of verification exceeds the cost of a wrong first attempt.
- **Precise mode (ultrawork)**: Sisyphus iterates — plan, execute, verify, re-plan. Multi-pass with verification (Module 9). For complex tasks where a wrong first attempt is expensive.

The mode is chosen at task intake based on a complexity assessment. This is a real-world realization of the tight-vs-loose verification loop (Module 9) — lazy = loose, precise = tight/staged. The decision is itself a Module 9 feature: most harnesses apply one verification depth uniformly; oh-my-opencode adapts.

## Phase 4 — Security Audit

**The multiplied attack surface**: each Junior is an independent agent with its own context and its own copy of OpenCode's permissions. A compromised Junior (via injection in its scoped context) can use its scoped permissions to attack Atlas — by returning a poisoned summary, by consuming the worktree in a way that propagates on merge, or by exhausting the parallel budget. This is Module 2.4's per-subagent capability filtering concern made concrete.

**Per-agent capability filtering (Module 2.4) is essential**: a Junior should never have the same permissions as Prometheus. A Junior that can write to the plan store, or call Prometheus's planning tools, breaks the hierarchy's isolation. The fix is per-tier permission scoping — Juniors get execution-only permissions; Prometheus gets planning-only; Atlas gets orchestration-only. As-built, oh-my-opencode inherits OpenCode's flat session-scoped permissions, which is the gap.

## Score & Synthesize: 38/60 (+4 vs OpenCode)

| Module | Score | Key decision | vs OpenCode |
| --- | --- | --- | --- |
| 1 Loop | 4 | inherited from OpenCode | = |
| 2 Tools | 4 | inherited | = |
| 3 Context | 4 | inherited | = |
| 4 Memory | 4 | inherited | = |
| 5 Sandbox | 4 | inherited (Docker) | = |
| 6 Permission | 3 | inherited (session-scoped) | = |
| 7 Errors | 3 | inherited | = |
| 8 State | 3 | inherited | = |
| 9 Verification | 3 | precise mode's verification loop | +1 |
| 10 Subagents | 5 | mixed hierarchy (highest in roster) | +3 |
| 11 Observability | 3 | inherited | = |
| 12 Prompt | 4 | inherited | = |
| **TOTAL** | **38/60** | | **+4** |

The +4 comes entirely from the hierarchy: +3 Module 10 (subagent orchestration — the highest score in the roster), +1 Module 9 (precise mode's verification loop). oh-my-opencode is the highest-scoring harness on subagent orchestration — it is the reference.

### Architect's Verdict

> *oh-my-opencode optimizes for task decomposition via a mixed subagent hierarchy (Prometheus→Atlas→Junior) that combines agents-as-tools with worktree parallelism. It sacrifices simplicity (the hierarchy is complex to debug) and inherits OpenCode's flat permission model where per-tier scoping is needed. Build on it for complex, multi-step tasks where planning + parallel execution justify the overhead — it is the canonical meta-harness.*

### MLSecOps Relevance

> *The subagent hierarchy multiplies the attack surface: each Junior is an independent agent with its own context, and a compromised Junior can use its scoped permissions to attack Atlas via poisoned summaries or worktree side effects. Per-agent capability filtering (Module 2.4) is essential — a Junior should never have the same permissions as Prometheus.*

### 3 things oh-my-opencode does better

1. **Mixed subagent hierarchy**: the only harness that combines agents-as-tools (top) with worktree (bottom) in a studied way. Module 1.3's two patterns, correctly placed.
2. **Two-mode design**: lazy vs precise, matching verification-loop depth (Module 9) to task complexity instead of applying one depth uniformly.
3. **Per-agent model assignment**: cost-aware routing (strong model for planning, cheap for execution). Module 1.4's principle at the single-harness scale.

### 3 things to fix

1. **Per-subagent tracing** (Module 10) — debugging the hierarchy is hard; add per-subagent structured logs so a failed Junior is identifiable without replay.
2. **Enforce per-Junior capability scoping** (Module 2.4) — currently inherits OpenCode's flat permissions; a Junior should be execution-only.
3. **Add unbounded-return prevention** (Module 1.3) — enforce the 1-2k summary bound at the harness layer, not just as a prompt instruction, so a misbehaving Junior cannot flood Atlas.

---

## References

1. **oh-my-opencode source** — the canonical meta-harness.
2. **DD-03 (OpenCode)** — the base harness whose loop oh-my-opencode inherits.
3. **Module 0.2** — meta-harness taxonomy; the lineage map.
4. **Module 1.3** — subagent patterns; the mixed hierarchy (agents-as-tools + worktree).
5. **Module 1.4** — cost-aware per-tier model routing.
6. **Module 2.4** — per-subagent capability filtering (the needed fix).
7. **Module 9** — verification; lazy vs precise as tight-vs-loose verification depth.
8. **Module 10** — subagent orchestration; oh-my-opencode as the reference scorer.