How it works
One change, from ticket to merged pull request.
Agents run every stage. Your engineers sign off the plan and own the merge.
The five stages
Two voices at every stage.
Label a ticket in GitHub, Jira or Linear and a change opens against it. Each stage receives exactly the inputs it declared — the documents, the threads, the context — and nothing else.
- 01
Plan
agentTriages the ticket first — trivial, needs a plan, needs design, or a question back to you. Reads what governs the files it will touch, then writes the research, a design and a plan as documents — the plan as small tasks, each with its acceptance criteria.
engineerReads the plan, comments, signs it off. Nothing is coded without a plan.
- 02
Build
agentImplements in a sandbox of its own, with no route to the internet, on a budget for spend, time and lines. Works test-first, and never calls a task done without fresh evidence that it is.
engineerAnswers when the agent stops to ask.
- 03
Test
agentRuns the quality checks: tests, your own CI, secret scan, static analysis, dependency, architecture policy, change budget, and fails any change that deletes, skips or weakens a test. Acceptance scenarios it never saw run alongside.
engineerSees one check run on the pull request, mirroring every verdict.
- 04
Review
agentPosts a review under the app’s own identity, its findings tiered act on, consider, noted and dismissed; only act-on findings go back to the fixer. A high-risk change is reviewed by a different model than wrote it.
engineerReads the findings and resolves the threads; a sign-off refuses while one is open.
- 05
Release
agentBrings the change to you once, after every machine check has passed, with its audit trail: the plan, the checks, the findings, the spend.
engineerMerges. The agent never merges its own pull request.
Nothing is coded without a plan.
Research, design and plan are written first, as documents your engineers read and edit, and a person signs the plan off — except a trivial, low-risk change once the automation has earned that. A change that starts from a plan is a change you can review against something.
When the line stops
It stops and asks. It never spins.
A change that cannot continue does one of these, in the open, and a person decides what happens next.
It asks
An agent that needs an answer stops and asks — in Slack or on the plan — and waits for a person. A ticket that needs answers before planning gets them asked on the ticket itself, and parked work carries a reason and a date to come back.
It goes back a stage
A change can be sent back a stage, against a budget, when the plan turns out to be wrong. The review and fix loop runs three rounds at most, then once more on a stronger model, then it asks a person.
It says it is blocked
An agent that cannot do the work as specified says so, with its reasons, and a person re-scopes or unblocks it. It is never pushed into gaming the checks.
It escalates, with a reason
A change that cannot proceed escalates with a named reason rather than stalling silently.
It keeps its definition
A change runs the automation definition it started with; editing an automation never changes a run in flight.
It raises the risk
Change risk is computed from recorded signals, and the level decides how much oversight the change gets — trivial, simple or full, chosen at triage. A signal that cannot be computed raises it, never lowers it.
It earns unattended
An automation runs unattended only after its own record, at that risk level, has earned it. There is no switch. Automations →
Every pull request arrives with its audit trail: the plan that was signed off, the checks and their verdicts, the approvals with the name of the person who gave them, the spend, and the identity the change ran under. The pull request body says why, what changed, the scope, the trade-offs and the impact.
After the merge, the line keeps watching.
Your default branch’s CI, reverts and error alerts are watched after a merge. A severe regression gets a revert pull request that a person merges; anything else becomes a ticket, deduplicated, back through triage.
Run one change through the line this week.
Connect a repo and a tracker, label a ticket, sign off the plan. The pull request arrives with its audit trail.