By name: delegation-matrix effort: low description: "Orchestrator/agent/Codex delegation matrix. Reference this when scoping a task to determine who owns what. Covers three Codex modes: reviewer-only (default), implementer+reviewer, and no Codex." triggers: ["who owns", "delegation", "codex or agent", "should codex", "task scoping", "who does this", "delegation matrix", "codex mode"]
Delegation Matrix
Reference when scoping any task. Dividing line: execution-heavy → Codex (if configured as implementer). Judgment-heavy → Agent always.
Codex is a configurable option. Pick the mode that matches your setup:
| Mode | Codex role | When to use |
|---|---|---|
| Mode 1 (default) | Reviewer only | Out of the box — Codex reviews Agent output before PR |
| Mode 2 | Implementer + reviewer | Codex is set up and trusted for implementation |
| Mode 3 | Not used | No Codex in your stack — Agent handles everything |
Ownership Matrix
| Work type | Orchestrator | Agent | Codex (Modes 1+2) |
|---|---|---|---|
| Requirement intake from user | owns | — | — |
| Task decomposition + dispatch | owns | consults | — |
| Briefings and status to user | owns | input | — |
| Architecture decisions | — | owns | — |
| Spec writing + acceptance criteria | — | owns | — |
| Security and domain modeling | — | owns | — |
| Ambiguous / judgment calls | routes | owns | — |
| PR decisions (file, scope, merge) | — | owns | — |
| First-pass implementation (clear spec) | — | owns (Modes 1+3) / delegates (Mode 2) | owns (Mode 2) |
| Mechanical refactors and migrations | — | owns (Modes 1+3) / delegates (Mode 2) | owns (Mode 2) |
| Repetitive multi-file edits | — | owns (Modes 1+3) / delegates (Mode 2) | owns (Mode 2) |
| Test drafting and fixture setup | — | owns (Modes 1+3) / delegates (Mode 2) | owns (Mode 2) |
| Code review before PR | — | owns (Mode 3) | owns (Modes 1+2) |
Contract-at-dispatch (load-bearing)
Every dispatch in this matrix — orchestrator → agent, agent → Codex, agent → another agent — must follow the 4-part structure from the durable spec at orgs/ascendops/docs/durable/subagent-prompt-structure-2026-05-24.md:
- Index-doc framing — files to read with "why" annotations, not inlined docs
- High-level workflow steps — outcome-oriented, not bash-by-bash
- Validation loop — proof-not-word baked in (exit codes, line counts,
git diff --stat) - Past + future contracts (KEYSTONE) — input shape + output shape + explicit ownership of edge cases
- Research artifact sub-bullet (v2): include
RESEARCH_ARTIFACT_PATH=<repo-relative-path>.mdwhen the dispatch involves research. Subagent writes raw facts there (URLs, code excerpts, line numbers, quotes); main-agent reads on demand. Keeps facts addressable without polluting context. See canonical spec §Part 4 sub-bullet for the artifact file format.
- Research artifact sub-bullet (v2): include
Receiver-side enforcement: if you RECEIVE a dispatch missing any of the 4 parts (especially past/future contracts), PUSH BACK and request them before starting. Refusal-to-start is the enforcement — neither agent needs the orchestrator to police it.
This applies equally to spawn-worker dispatches and peer-agent dispatches (orchestrator → agent, agent → Codex, agent → agent). The durable spec carries the worked example.
Default Coding Workflow by Mode
Mode 1 — Codex as reviewer (default, out of box)
- Orchestrator receives task, dispatches to Agent
- Agent implements
- Agent passes output to Codex for review
- Agent applies Codex feedback, opens PR
Mode 2 — Codex as implementer + reviewer
For tasks >~20 lines or touching multiple files:
- Orchestrator receives task, dispatches to Agent
- Agent designs the approach, writes a tight spec (what to build, file paths, expected behavior, edge cases)
- Agent calls Codex with the full spec — Codex implements
- Agent reviews Codex output for correctness and architectural fit
- Agent opens the PR
Mode 3 — No Codex
- Orchestrator receives task, dispatches to Agent
- Agent designs and implements directly
- Agent opens the PR
For one-liners and config changes: Agent writes directly in all modes.
When to Keep Implementation with Agent (Modes 1+2)
Even in Mode 2, some work stays with the Agent:
- Correct behavior is unclear and requires judgment
- Security, auth, or trust-boundary code
- Design is still open — spec isn't settled yet
- Output shown directly to users or external systems
Deployment note: replace "Orchestrator" / "Agent" with your actual agent names.