# Build an agent loop that can prove its work

> Turn an ambiguous agent task into a chain of inspectable decisions. Define done, make the change, exercise it, review from fresh context, and keep release authority with a person.

**Playbook · Agent operations**  
By Mitchell Keller · September 3, 2026 · 9 min read

## Key answer

- Use distinct roles for deciding, making, proving, checking, and releasing work.
- Ask each role for an artifact another person can inspect, rather than a confident status update.
- Give the checker a context independent of the maker’s conversation; this reduces agreement pressure, not bias.
- Stop on a declared success condition, a real blocker, or a bounded iteration limit. A person still decides whether to release.

## One long prompt cannot review itself

A long prompt can contain a plan, instructions to build, and a request to “double-check everything.” That does not create an independent review. The same context that chose the approach also frames the evidence, interprets failures, and decides whether its own output is good enough.

For a small task, that may be acceptable. For work that changes a customer-facing page, a data path, or a reusable operating system, it is easy to confuse completion language with proof. A useful loop changes the question at each handoff: what should be true, what changed, what actually happened when exercised, and what does an independent reader conclude from the artifacts?

> **What this does not prove:** Separating roles does not guarantee correctness, eliminate model bias, or replace senior judgment. It makes the basis for a decision easier to inspect and gives a human a clearer point to intervene.

## Five jobs, five kinds of evidence

The Loop Engineer release describes a five-agent sequence. Treat the labels as jobs, not as a requirement to use five different tools or five simultaneous sessions.

```text
Planner → Maker → Prover → Checker → Shipper
intent    change   observation fresh review human release authority
```

Keep the loop sequential when one output is necessary for the next role. Parallelize only independent discovery or review questions. More agents are not automatically more reliable; a role is useful only when it changes what can be known.

## Planner: define done

**Need:** turn a request into an observable outcome before someone starts changing files.

**Input:** approved scope, constraints, current behavior, and a way to tell whether the result works.

**How it works:** write a brief and a phase plan. Each phase should name a user-visible result, its owner, its dependencies, and a mechanical gate. “Update the page” is activity; “the article offers a working Markdown copy action and a visible result” is a testable outcome.

**Output:** a plan that another operator can challenge without reading a private conversation.

**Impact and human review:** a person approves the scope before execution. Newly discovered work belongs in a follow-up decision, not as a quiet expansion of the original task.

## Maker: make the smallest sufficient change

**Need:** produce the planned artifact while preserving the work that was not approved for change.

**Input:** the approved plan, an exact file boundary, and the current working state.

**How it works:** make one bounded slice at a time, run the named mechanical check, and leave evidence with the change. In the Loop Engineer release, the maker captures the worktree state before editing, stages only the slice boundary, and records command output rather than a self-authored success claim.

**Output:** a small diff and a proof record that point to the same intended change.

**Impact and human review:** narrow changes make review cheaper. If the task requires a wider change than the approved boundary, pause for a decision instead of normalizing a broad edit.

## Prover: exercise the result

**Need:** distinguish a file that looks plausible from behavior a user can actually reach.

**Input:** acceptance criteria and a running interface, API, or command.

**How it works:** drive the feature once with a realistic input and capture what happened. For a browser surface, that might be a screenshot, keyboard exercise, and route response. For a command, it is raw stdout and stderr. If the app is unavailable, record that as a failed proof condition; do not substitute a claim that it probably works.

**Output:** a binary, observable verdict with the command or screenshot that produced it.

**Impact and human review:** proof narrows uncertainty. It does not decide whether the observed behavior is appropriate for the product or safe to release.

## Checker: judge from fresh context

**Need:** assess the delivered artifacts without inheriting the maker’s rationale or its tool transcript.

**Input:** the final files, explicit rubric, and narrow process proof needed to validate mechanical facts.

**How it works:** give the checker a fresh context and ask it to cite file-and-line evidence for every score. In the release, the checker is deliberately limited to reading final artifacts and named proof, rather than replaying the maker’s reasoning. That separation is a practical guard against grading the work by intent.

**Output:** a pass, iterate, or plateau decision with a specific weakest dimension.

**Impact and human review:** fresh context is an independence tool, not a guarantee of neutrality. Use a reviewer with the right domain authority when the work’s risks demand it.

## Shipper: preserve human authority

**Need:** make a release decision distinct from building and scoring the work.

**Input:** a passing checker result, the change set, and separate authorization to ship.

**How it works:** the release evidence is checked one more time against the chosen delivery path. The release contract states that a checker pass does not itself authorize shipping; the shipper requires separate approval.

**Output:** a prepared release, a returned change, or a documented blocker.

**Impact and human review:** the person with release authority decides whether the result belongs in production. This is especially important when consequences extend beyond the repository.

## Keep four durable artifacts

Artifacts let a later operator reconstruct the decision without having access to an ephemeral chat. Keep them small enough to remain current.

| Artifact | Question it answers | Owner |
| --- | --- | --- |
| Brief and plan | What outcome, constraints, and stop conditions were approved? | Planner + approver |
| Change record | What was changed, and what narrow gate ran? | Maker |
| Proof record | What happened when the feature or command was exercised? | Prover |
| Review and release record | What did an independent reader find, and who authorized the next step? | Checker + human owner |

Do not store credentials, private prompts, or customer material merely to make a log feel complete. Record a safe reference and the decision it supported.

## Know when the loop should stop

Choose a clear end before the run starts. Stop when the acceptance criteria and mechanical gate pass. Also stop when an outside dependency needs owner input, the iteration budget is used, or repeated reviews point to the same unresolved constraint.

The release uses a bounded evaluation cycle and recognizes a plateau when repeated scores do not materially move. Your exact threshold can differ. Preserve the best inspected state and state why the loop stopped instead of making “one more pass” the default.

## Carry the protocol between Codex and Claude

Codex and Claude can support this protocol when their environment provides separate task contexts, readable files, and a way to run the relevant checks. The portable part is the contract: roles, artifacts, a fresh evaluator, a bounded stop rule, and human release authority.

The runtime-specific part is implementation. Tool availability, isolation behavior, permissions, worktree handling, and review interfaces differ. Do not assume a workflow designed for one environment has identical controls in another. Reconfirm the actual boundaries before treating a role name as a safety feature.

## Start with one small loop

1. Choose one task with a visible result, such as adding a resource page or correcting one API response.
2. Write a one-paragraph brief with exact files, an acceptance check, and a clear person who may release it.
3. Have the maker produce the smallest change and attach raw check output.
4. Exercise the result from the user’s path; save the observation.
5. Ask a fresh reviewer to assess the final files against the brief, then decide whether to release, revise, or stop.

If you cannot name the proof or the release owner, shrink the task until you can. A compact loop that leaves usable evidence is a better starting point than a large ritual with unclear authority.

## Source notes

This guide is based on Legion’s local Loop Engineer release: its `README.md`, role contracts for planner, maker, prover, checker, and shipper, and the completed resources harness contract. These sources establish the described role separation, fresh-context review boundary, proof protocol, protected-work posture, and explicit shipping approval boundary.

The current [Legion waitlist](https://waitlist.joinlegion.io/g/legion-waitlist) is the only contextual next step linked here. This article does not represent the giveaway as a public repository, a download, or a promise of a particular outcome.

## Keep the operator in the loop

Join the Legion waitlist for updates on practical operator systems.

[Join the Legion waitlist](https://waitlist.joinlegion.io/g/legion-waitlist)

## Related resources

- [From market signals to operator-ready opportunities](from-signals-to-opportunities.html): use evidence and review boundaries in a signal workflow.
- [A 15-stage video workflow that survives handoffs](video-workflow-that-survives-handoffs.html): apply durable artifacts to recurring creative work.
- [Back to resources](index.html)