--- title: "Build an agent loop that can prove its work" slug: loop-that-proves-its-work kind: Agent loop protocol source: https://www.joinlegion.io/resources/loop-that-proves-its-work published: 2026-09-03 --- # Build an agent loop that can prove its work Run one task through the five jobs. Each row is a handoff that must leave a different kind of evidence behind. 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. The steps below are the ones in the guide at https://www.joinlegion.io/resources/loop-that-proves-its-work. Read it for the reasoning; run this for the work. Nothing here is new: if the guide does not say it, this file does not either. ## 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? 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 - [ ] Planner intent and acceptance criteria - [ ] Maker bounded change and proof of completion - [ ] Prover observed runtime result - [ ] Checker fresh-context evaluation - [ ] Shipper human-approved release decision 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. Five jobs in order, and each handoff changes the evidence the next job needs. The planner writes intent and acceptance criteria. The maker produces a bounded change plus proof of completion. The prover exercises the result and records the observed runtime result, not a claim that it works. The checker evaluates the artifacts from a context independent of the maker's conversation. The shipper takes the human-approved release decision. A failed proof or a failed check sends the work back to the job that owns the missing artifact; no job approves its own work. 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. 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 - [ ] Choose one task with a visible result, such as adding a resource page or correcting one API response. - [ ] Write a one-paragraph brief with exact files, an acceptance check, and a clear person who may release it. - [ ] Have the maker produce the smallest change and attach raw check output. - [ ] Exercise the result from the user’s path; save the observation. - [ ] 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. ## Where the working files are The full protocol, role contracts and setup files for this system live in the Legion community: https://www.skool.com/legion/about