Checkwright

Agent orchestration: the verification layer beneath it

Agent orchestration frameworks answer who works on what, and when: they fan a job out across agents, sequence the hand-offs, and keep many writers moving at once. They do not answer whether the work is right. Every delegation hop is a place where “the agent said it passed” can stand in for verification, and drift compounds per hop, so orchestration without a verification layer parallelizes drift.

Checkwright is that second answer. It makes done mechanically decidable, so a supervisor (human or agent) can trust a completed unit of work without reading all of it: coordination is only worth scaling once each coordinated result is checkable. Checkwright therefore sits beneath an orchestrator, as the verification layer a coordination layer stacks on. It complements your orchestration setup; it does not replace it.

The mechanisms

  • Verification survives the adversary. After every commit a delegated agent makes, the supervisor re-runs the relevant gates and the validate battery rather than trusting the agent’s report, and diffs every gate change the commit carries. check-gate-tamper blocks the two commit shapes a gate is weakened by: a gate edit staged with the code it judges, and a new exemption that excuses a file in its own commit. It reads a commit’s shape, not its intent, so the diff review stays the supervisor’s. Owned by delegation-kit/SPEC.md §Verify after every agent commit.
  • Every dispatch can be metered. An optional per-dispatch budget guard, wired as a harness hook, reads the usage verdict before each delegated agent starts and blocks the dispatch when the budget says pause, so a fan-out cannot run away with the token budget. Owned by delegation-kit/SPEC.md §The delegation model.
  • Stage claims are auditable evidence, not assertions. Each lifecycle stage stamps a line into a committed state file when it runs, so a stateless supervisor can audit what happened by reading the stamps rather than re-reading the work. Owned by lifecycle-kit/SPEC.md §The state machine.
  • Every run leaves a committed receipt. A per-run evidence manifest is committed alongside the work, so “this passed” is a durable artifact in the history, checkable after the fact by anyone. Owned by evidence-kit/SPEC.md §Evidence manifest.

Together these make the delegation boundary trustworthy: work crosses it with a checkable receipt, not a promise.

Checkwright’s own coordination

Checkwright is a verification layer, not an orchestration layer: the prerequisite for unattended orchestration at scale, where no human reads each hop. It carries a small, checkable amount of its own coordination:

Within one iteration that is the extent of it: a lead dispatching its own verified stages. Across operators Checkwright coordinates nothing: it verifies, so whatever coordinates can be trusted to have coordinated correct work. Where the coordination layer goes next is the queue’s Deferred section, checkable in the tree.

Running an iteration under a lead

The lead is a role a session becomes, not a stage it runs — and running no lead is equally valid. Two model tiers carry the work: the judgment tier, the stronger and pricier model you trust with design decisions, and the routing tier, a cheaper model that is enough for dispatching sessions and passing messages between them. The recommended shape is the split posture: the lead rides the routing tier and only the judgment-heavy work pays premium prices. It is a trade: a routing-tier lead relays a class of question a judgment-tier one would settle itself, and the lead template’s Economics section states the trade and how to measure it.

Each tier is bound to a model once, in your delegation config: to a model alias, which follows the newest model the harness names by it, or to an exact model id, which pins it. What each binding costs, and how an upgrade or a bypassed pin shows, are delegation-kit/SPEC.md §The tier binding.

To drive an iteration under the split posture:

  1. /lead in a fresh session on the routing tier. The lead role writes no lifecycle state of its own; every stamp and commit stays in the stage sessions it dispatches, so the history reads identically whether or not a lead drove it.
  2. The lead dispatches /scope as a background stage session on the judgment tier. Scope chooses and names the iteration’s work and lands the commit that promotes it into the queue. Its agent stays resumable afterward as the iteration’s intent oracle: the one session that remembers why the iteration took its shape.
  3. When the iteration promotes a feature, the lead dispatches /spec — the trigger-gated amendment-authoring stage — as a background stage session on the judgment tier. It authors the promoted features’ design amendments and pairs each into the queue. A debt-only iteration skips it.
  4. The lead dispatches each remaining stage — /align, /build, /validate, /close — as a background stage session that runs its skill unchanged, on the tier your binding assigns its class. validate runs oracles and rides a cheaper tier; build is tiered per batch, so only the batches that carry design work stay on the judgment tier. A stage whose work splits into batches is one stage session per batch, each dispatched and verified by the lead; a stage session never dispatches its own siblings.
  5. A blocked stage escalates to the lead and resumes in place. The lead rules machinery questions itself; a question about the iteration’s intent it forwards to the intent oracle and relays the answer back. A question outside the classes the lead may rule reaches the operator. One case does not resume: a cheaper-tier session that finds a fix it must design itself escalates for a fresh judgment-tier session, since a resumed session keeps its model.
  6. If the oracle cannot be resumed, the lead answers from the governed surfaces the rulings already live in — the amendments, the queue entries — and hands anything not derivable there to the operator.

The unified posture — /scope in a live session, /compact, then /lead in that same session — is simpler when tiering is not a concern; every orchestration turn then re-reads scope’s context at scope’s prices. To stay hands-on, skip the lead and run each stage manually as an ordinary skill invocation, consulting the scope session when a stage raises a question. The postures and the escalation protocol, including which questions the lead may rule, are owned by lifecycle-kit/SPEC.md §templates/lead.md.

Two operators, one governed tree

A lead drives one iteration. When a second operator works the same repo at the same time, the coordination is git topology, not a new mechanism. Every rule below is owned by lifecycle-kit/SPEC.md §Multi-operator semantics.

Picture two iterations live at once — say surface-trust and docs-polish.

  1. Each iteration owns one branch. The first operator’s iteration lives on its home branch; the second operator cuts a branch at their own /scope entry. The integration branch is just the degenerate single-operator home, which is why a solo repo needs none of this.
  2. Each branch stamps its own state. surface-trust’s stage sessions append its evidence on its branch; docs-polish does the same on its. Neither reads the other’s state, so the state surfaces stay single-writer while two operators move, and operator attribution rides the git author on each stamp commit.
  3. At a merge, the iteration-scoped surfaces resolve to the arriving side. When one branch merges into another, the header line, the evidence file, and the other boundary-truncated surfaces take the checked-out iteration’s version wholesale; the other side’s copy is per-iteration scratch, and git history keeps the audit trail. The set is derived from what the iteration boundary already truncates and held by a merge=iteration-scoped driver and a parity gate. Shared backlog and lessons in the queue body merge like any prose; only its one header line is resolved by hand, and a wrong resolution reddens at the next commit under the stage evidence gate.
  4. Closes serialize at the integration branch. Each operator closes on their own iteration branch, reconciling by merging the integration branch in; the close-merges land one after another on the integration branch. No lock, no lease — the serialization is the merge order git already imposes.

The through-line: concurrency is isolation git already provides, and verification is unchanged on every branch. Whatever an operator’s branch merges passed the battery, so two operators parallelize checked work, never drift.

Where to go next

  • Why Checkwright — the delivery-methodology essay behind the mechanism.
  • The kits — one page per kit, in reading order.