What loopexec does not do

Serious tools say no clearly. A boundary you can read is worth more than a feature you can’t trust.

loopexec is a deterministic runtime for loop engineering. It governs how work is executed, recorded, and resumed: it runs a bounded loop that halts on a computed halt reason, and it leaves a receipt. That is the whole job. Everything below is outside it - on purpose.

What loopexec is not

These are category boundaries, not a roadmap. They hold at every status.

loopexec is not	Because	Who owns that
an AI model or agent	it has no weights and makes no edits; it runs an external agent and governs the loop around it (the model lives in your --exec - see Models and Agents)	your model / agent
an agent framework or multi-agent chatroom	it orchestrates no personas; one executor runs, with at most one advisory cross-lab judge that can veto a green iteration but never promote a red one	role governance (Musketeer)
a prompt-automation tool	it does not author, template, or tune prompts	you
a CI replacement	CI gates a push; loopexec runs a bounded check_fixpoint loop until a check passes, a guard trips, a budget is spent, or a human is required	your CI
a task runner	make, just, and npm run a DAG to completion; loopexec iterates until an external check reaches fixpoint and emits a computed halt reason	make / just / npm
a state definition system	it reads state from disk and the CLI; it never defines the schema	SMALL
the application oracle	it runs YOUR check and records the exit code; it never decides application correctness	your external check

Note

The mode is explicit and recorded in every receipt. check_fixpoint halts when an external check passes; task_list iterates a SMALL plan and still requires a per-task acceptance oracle. State hygiene alone is not an oracle - it cannot decide application correctness. See Loop Engineering.

It runs your check - it is not your check

The most important “no” is the oracle boundary. The check MUST be an external process returning an exit code, independent of the agent. The agent’s self-assessment is not a check. loopexec never grades the work; your external process does. A loop runs until that check passes - never because an agent reports it is done.

When the check goes green, the contract requires guards to be evaluated first: guards dominate success. A suite that passed only because a test was weakened is specified to halt as a guard reason, not as success. loopexec does not decide what “correct” means. It refuses to let a green verdict stand on a hollowed-out check.

Limits it keeps even at full spec

Three things loopexec will not do for you even after every mechanism in the spec ships. These are permanent, not pending.

It does not make a non-deterministic check trustworthy

Determinism is a property of (check x codebase), not a flag loopexec can set. The contract specifies probe-check to report an achieved confidence bound on the flake rate, and an in-loop monitor that halts check_not_deterministic when stability drops below the confidence target. If your check is flaky, loopexec is specified to halt and name the dimension that broke - order, seed, clock, concurrency, or load. It will not loop on an untrustworthy oracle and call the result green. Making the check deterministic is your engineering: hermeticity. See Determinism.

It cannot guarantee convergence on an infeasible goal

A fixpoint check tells you when you have arrived; it exerts no force toward a fixpoint that does not exist. Under contradictory constraints, no green state exists, and loopexec cannot conjure one. The contract requires a known-feasible reference as an existence proof, and specifies explain-halt to separate “still improving at the cap - raise the limit” from “stalled or infeasible - do not retry.” loopexec bounds the damage with max_iterations and a run-total budget, and tells you which case you are in. It does not promise to solve an unsolvable task.

It does not prove comprehension - it forces review

The comprehension gate tracks diffs_merged_unread and is specified to halt comprehension_debt_exceeded past a threshold, cleared by a signed ack. This is a forcing and visibility gate. It makes unread merged diffs impossible to ignore. It does not read the diff for you, and a signed ack is evidence that review was demanded, not proof that you understood the change.

Status, honestly

The boundaries above are permanent and true today. As of v0.2.0 the engine is complete through Slice 7, so the mechanisms that enforce them ship; a few named sub-parts of those shipped cores stay Planned, and the docs render that distinction rather than hide it.

Capability	Status
CLI contract: --json, stable exit codes, deterministic output	Shipped
init / status / check / step commands	Shipped
run as a real iterating loop, computed halt reasons, typed receipt	Shipped
probe-check confidence bound	Shipped (core) - perturbation + in-loop monitor Planned
doctor precondition gate, isolation preflight	Shipped (core) - hermeticity + adequacy coverage-delta tier Planned (mutation canary ships)
Metric-integrity gate (guards dominate success)	Shipped (core) - assertion-count / manifest-hash / coverage-floor Planned
Two-zone isolation + per-run minted key	Shipped (core) - container engine / egress proxy / key API are operator hooks
replay / reexecute, attest / ack	Shipped
escalate / watch + comprehension gate	Shipped (core) - github/slack channels + kill-PID actuator Planned

Where the limits above say loopexec “is specified to” halt or gate, those mechanisms ship as of v0.2.0 - the probe-check confidence bound, the feasibility split in explain-halt, and the comprehension gate are all in the binary, with named sub-parts still Planned. The full capability matrix is normative in SPEC section 11; the binary tests and these pages both reference it.

Tip

The claim is gated on the mechanics. loopexec leaves a receipt you can verify offline without re-running the agent - replayable verdicts, not replayable runs. A live-LLM trajectory is not reproducible; only the verdict is. That capability ships as of v0.2.0 - it is the moat, not the slogan.

Read next: Halt Reasons for the computed stop conditions, Determinism for how the check is held to a confidence bound, and Loop Engineering for the discipline this runtime enforces.