How it works
How it works
A dispatch works on exactly one task in one target repo, on one agent branch. It ends in a pull request, a merge or a clean stop that asks a human for help.
- Step 1
Mark the task
A task is a GitHub Issue on the Project board. Add the
agent-readylabel and, optionally, an agent label such asagent:codex. No agent label means Claude. - Step 2
Move it to Next
Moving the task’s Status to Next is the go-signal. The Lambda relay confirms the label and calls
workflow_dispatchon the control repo with the task number, URL, target repo and agent. - Step 3
Grade the task
task-definition-eval reads the task text. BOUNCE stops the run before any file is edited and moves the task to Waiting+needs-you with what is missing.
- Step 4
Run the coding agent
The runner clones the target repo onto
agent/task-<id>, loads its knowledge base and conventions files, and hands the task to the coding agent. - Step 5
Grade the diff
completeness-eval grades the diff against the task, up to 3 tries. For a public-facing repo, publish-safety-eval runs last; HOLD pushes nothing.
- Step 6
Open the pull request
The pull request carries the eval verdicts. Dependency bumps and whitespace-only diffs with a DONE verdict and green CI may auto-merge; everything else is held for human merge. A merge moves the task to Done.
Revise by commenting on the pull request
A comment on an open agent-ops pull request goes through the Lambda relay to the revision workflow. The runner checks out the existing agent branch, re-runs the coding agent with the comment as context, re-runs completeness-eval, force-pushes and comments with the verdict.
Every stop that needs a human (BOUNCE, HOLD, completeness never passing, no file changes) moves the task to Waiting+needs-you. If that move fails, the comment says so, so nobody trusts a board that did not update.
Run your own control plane
One control repo, one Lambda relay, one self-hosted runner and a GitHub App, all under your own accounts. There is no hosted service and no account to sign up for.