ADW Orchestration
Merlino orchestration + Thorbit ADW

Your workforce directs.
ADW executes.

Ava intakes. Oliver plans and writes the score. A visual map of how the work gets signed off, conducted, checked, improved, and delivered inside Codex.

Follow the work ↓

One connected orchestra loop

  1. Avaintakes the request
  2. Oliverplans and writes the score
  3. Mikegives GO
  4. Dan + Codydual signoff before build
  5. Carlosconducts the leads only
  6. Domain leadsimplement bounded work
  7. Queenindependent output QA
  8. Peteyreviews process after delivery
No

Carlos routes findings to accountable owners → owners correct → Queen rechecks

Yes

Dan final engineering review + POWD → Oliver delivers to Mike

1 · IntakeEvery request has one front door

Ava intakes. Oliver plans and writes the score.

Ava intakes. Oliver plans and writes the score.INTAKEASK ARRIVES↓AVA: STRUCTURE↓ROUTE OR HANDLE↓TO OLIVER

Ava is the intake: she captures what Mike said, structures it, and handles the recurring EA work herself. Anything that is a new build, a multi-step project, or touches client deliverables gets handed to Oliver, who understands intent, plans the work, and writes the score.

  • Ava captures the ask and handles routine EA work directly.
  • Oliver takes anything that needs planning or a build.
  • Mike gives GO on the score Oliver writes.
Ava does not write blueprints or plans. She routes to Oliver, or she just handles it.
2 · DirectionCompose before anyone plays

Oliver writes the score and gets approval

Oliver writes the score and gets approvalSCOREOLIVER: INTENT↓DAN + LEADS: SECTIONS↓OLIVER: FINALIZE↓MIKE: GO

Oliver understands the intent behind the request, plans the work, and writes the score, pulling in Dan and the accountable domain leads for the sections they own. Mike reviews that score and gives GO before any build begins.

  • Oliver drafts the blueprint and reconciles every section.
  • Dan and domain leads contribute the sections they own.
  • Mike gives GO on the finalized score.
Carlos does not write or finalize the score. Carlos conducts the approved score.
3 · SignoffTwo signatures before a line of code

Dan and Cody dual signoff locks the score

Dan and Cody dual signoff locks the scoreSIGNOFFDAN: REVIEW↓CODY: REVIEW↓BOTH SIGN OFF↓SCORE LOCKED

Before build starts, Dan (head developer, the Claude coding lane) and Cody (the Codex coding lane) both review the approved score and sign off on it. That dual signoff is today's real gate ahead of execution, not a single reviewer's call.

  • Dan signs off from the Claude coding lane.
  • Cody signs off from the Codex coding lane.
  • Only a score both have signed becomes bounded work.
One signature is not enough. Build waits for both.
4 · ConductCarlos is conductor only

Carlos conducts the leads

Carlos conducts the leadsCONDUCTCARLOS: DISPATCH↓BOUNDED TASKS↓DOMAIN LEADS↓EVIDENCE

After dual signoff, Carlos dispatches the approved score to the accountable domain leads, sequences dependencies, collects evidence, and routes findings back to whoever owns them. Carlos never performs the implementation, the fix, the output QA, or the process QA himself.

  • Required reads and mutation boundaries travel with each task.
  • Domain leads implement and correct their own sections.
  • Carlos coordinates dependencies and evidence only.
Every claim points to a file, symbol, route, check, or artifact.
5 · VerificationOne independent verdict before delivery

Queen does the independent QA

Queen does the independent QAQA-LOOPIMPLEMENT↓REVIEW + TRACE↓QUEEN: VERDICT↻PDCA + DEBT

Queen owns output QA, verifying visible changes with real evidence: screenshots, browser tests, and accessibility checks against what the score actually asked for. Carlos waits for Queen's verdict and routes any correction back to the accountable owner before the work goes out.

  • Queen records expectations before observing results.
  • Queen returns an evidence-backed pass or fail verdict.
  • Carlos routes every finding to its accountable owner.
Queen checks the work. Petey is not part of this cycle.
6 · Learning + ProofThe process review happens after delivery

Petey reviews process after delivery. Oliver delivers.

Petey reviews process after delivery. Oliver delivers.PROCESSDELIVERED↓OLIVER: CONFIRM↓PETEY: PROCESS REVIEW↓IMPROVEMENT QUEUE

Once Queen's verdict passes, Dan completes final engineering review and proof, and Oliver confirms the result against the score and delivers to Mike. Only after that delivery does Petey step in, independently reviewing whether the score, prompts, skills, workflows, agents, validators, hooks, routing, or SOPs need to improve for next time.

  • Dan's final review and proof happen after Queen's pass.
  • Oliver confirms against the score and delivers to Mike.
  • Petey reviews process only after delivery, never as a gate.
Matteo Jr owns the Hermes runtime, which feeds Petey a daily ranked improvement queue for the next cycle. Hermes recommends, Petey evaluates, accountable owners change canonical sources.