Agent Roles
Selectable Codex roles and the verification-first work loop.
LazyCodex (LZX) packages the OmO agent harness for Codex. Most users only need to remember commands such as $init-deep, $ulw-plan, $start-work, and $ulw-loop. Internally, Codex multi-agent tools and selectable roles split exploration, planning, review, and QA.
As of 4.12.1, installed roles include explorer, librarian, plan, momus, metis, lazycodex-executor, lazycodex-code-reviewer, lazycodex-qa-executor, lazycodex-gate-reviewer, and lazycodex-clone-fidelity-reviewer. If the Codex build exposes agent_type, LazyCodex can select those roles directly. If not, it falls back to describing the role inside the message.
Parent Session Ownership
Even with many roles, completion judgment is not handed wholesale to child agents. The parent Codex session keeps ownership of the goal, constraints, and final judgment. Child agents map terrain, find gaps, review, or help with QA.
| Role | Used for |
|---|---|
explorer | Internal context such as codebase structure, call flow, and test locations |
librarian | External docs, library contracts, and current API research |
plan | Draft plans and work breakdowns |
momus / metis | Missing decisions, edge cases, and risk review |
lazycodex-executor | Executing a specific unit of a plan |
lazycodex-code-reviewer | Post-implementation code quality review |
lazycodex-qa-executor | Hands-on QA against real surfaces |
lazycodex-gate-reviewer | Pre-completion verification gate |
lazycodex-clone-fidelity-reviewer | Fidelity review for clone or sync work |
Execution Loop
However roles are split, the basic loop for a unit of work is the same.
- Explore: map the terrain. Read code with tools instead of guessing, and launch read-only child agents in parallel when useful.
- Plan: choose the path. Record files, concrete changes, and dependencies in the active plan.
- Implement: build precisely. Match the existing codebase style even when a greenfield version would look different.
- Verify: prove it works. Run diagnostics, related tests, and build checks in parallel where possible.
- Manual QA: check the real surface, then write the final message.
Non-goals
- It does not trust child-agent self-reports. Completion is judged by independent verification.
- It does not stop at suggestions when code was requested. Unless the user explicitly asks for planning or brainstorming, it implements.
- It does not guess unread code. Exploration is cheap; assumptions are expensive.
- It does not leave work blurry at the end of a turn. Each plan step is reconciled as completed, blocked with a reason, or removed with a reason.
Orchestration and Delegation
LazyCodex uses child-agent roles inside Codex. It can use read-only roles for parallel exploration and reviewer roles for review or QA. Final reporting is still based on evidence collected by the parent session.
Boulder State
$start-work uses .omo/boulder.json to preserve progress and Stop-hook continuation to keep plan execution moving. This is the key user-visible durable behavior. When every checkbox is done, it prints ORCHESTRATION COMPLETE.
Related Docs
$ulw-plan: plans before implementation and writes.omo/plans/<slug>.md.$start-work: executes a plan with durable Boulder progress.$ulw-loop: keeps looping until evidence is verified.- Hooks & Lifecycle: how Stop-hook continuation and evidence gates keep long work moving.