Work

An agent does not have a desk, a calendar, or a manager checking in on Tuesday. It has a session that starts, runs, and ends, and then a different instance picks up whatever it left behind. A work model built for a continuous person — sprints, story points, a board someone walks past every morning — does not fit that. What fits is a pipeline: one path from a problem to a merged, verified change, with a gate at every step that has to be earned rather than asserted.

Plan becomes issue

Work starts as a GitHub issue, filed and closed through legion’s own verbs so every action lands in the audit log rather than going around it. Turning a rough problem description into a real spec is not left to whoever happens to be filing it: the legion:issue-writer agent reads the repo’s own issue template and writes a body that matches it exactly — section order, acceptance criteria, and where the ask is genuinely unclear, a named UNCLEAR instead of a guessed answer. It also records uncertainty predictions about the work before anyone starts, so what the team expected going in is on the record before it is confirmed or contradicted.

Build

An implementer takes the issue up in an isolated worktree — one change, one branch, nothing bleeding in from whatever else is in flight. Which model builds it is not arbitrary: a vague spec routes to more capability, because the ambiguity has to get resolved in the agent’s head instead of on the page; a tight one can route to less.

Gates, not a board state

Nothing reaches done because an agent says it is done. It reaches done by clearing a chain of gates, each one recorded against the exact commit it was run on — HEAD-keyed, not repo-keyed, so a gate cannot quietly stay clean while the code underneath it moves on without it.

legion-simplify, first: a per-file articulation of what was checked and why the diff holds up, not a bare verdict. legion quality-gate check validates the articulation itself before recording it — a boilerplate “looks fine” does not clear the gate, only a substantive one does. Findings raised here land in a ledger, not a comment that scrolls away: each one resolves, gets dispositioned with a reason, or is batch-acknowledged, but it is never silently dropped.

legion-pr-write, second: before the PR opens, its body maps every acceptance criterion to the diff that satisfies it, in prose, with evidence, and says plainly what was deliberately left undone. pr write-check validates that mapping and refuses an empty or boilerplate one. Writing the mapping is itself a check: it makes the implementer re-read their own diff as a reader would, which is usually where the thing they talked past while coding gets caught.

Review, third: dimension reviewers run over the diff — fanned out separately or combined into one pass, depending on how much risk the change carries — and every HIGH-severity finding gets adversarially refuted before it is allowed to stand. A finding that does not survive scrutiny does not get to block anything either.

legion-verify, fourth: the issue’s acceptance criteria each get a verdict — pass, fail, or uncertain — and a pass needs cited evidence or the system downgrades it to uncertain automatically. Any fail blocks the close. Any uncertain routes to a human instead of getting rounded up to done.

The merge queue closes the loop

A PR that clears every gate still does not merge blind. It joins a merge queue that builds a speculative merge commit and re-runs the full CI suite against that commit, not just the branch in isolation — so what actually lands is what was actually tested, including whatever else landed on the base branch in the meantime. legion pr merge reports the PR as queued while that runs, not merged; the issue closes only once the queue’s own CI comes back green.

Why a pipeline instead of a board

A board tells you where a thing is. A pipeline tells you what has been proven about it. Trust already puts the failure mode on the table: an autonomous agent’s default move under pressure is to declare victory. A status column an agent can drag itself into does nothing to stop that. A gate that has to be earned — an articulation, a citation, a re-run CI result — does. The pipeline is not process for its own sake. It is where Trust’s abstract rule, verify instead of assert, becomes the actual sequence a change has to survive before it ships.