| 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 your org internal docs:
- 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>.md when 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.
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.
