Loop engineering with Stele Operator

What loop engineering means

A prompt asks for one result. A loop controls a sequence of attempts. It decides what enters the next iteration, what counts as progress, who may judge the output, and what happens when the work does not converge. That makes loop engineering a systems problem around the model, sitting alongside prompt and context engineering.

The label is new; the engineering concerns are not. Durable state, executable contracts, verifier integrity, bounded retries, and human approval are established reliability patterns. Stele uses “loop engineering” as a useful name for that combination, while building the product around those longer-lived ideas.

The five layers of an agent loop

The Operator design maps closely to the five-layer “Operator Loop Stack”: harness, loop contract, state, checker, and human checkpoint.

How Stele Operator runs, step by step

1. Authenticate and choose scope. Operator confirms the Stele session, project, focus area, and whether you want Auto, Batch, or Step-level checkpoints.
2. Read before choosing work. It loads repository rules, open tasks, dependencies, workspace scope, and the decisions and risks linked to the candidates. Priority and dependency order choose the work; having an easy check never makes a task more important.
3. Inspect the contract. A task with a checkcan be driven toward an executable result. It is loop-certified only when check_paths also name the tests, scripts, and fixtures that make up the oracle. Operator never guesses missing paths.
4. Plan a collision-safe batch. Small or serial work runs inline. Independent substantial tasks may run concurrently, but only when the harness can keep each worker inside its own Git worktree. Otherwise Operator stays sequential.
5. Execute and watch. A dispatched worker receives the full task contract, repository rules, lineage, worktree, and protected paths. Operator watches Git state and completion signals so a silent hang does not masquerade as progress.
6. Protect the oracle. Before trusting green output, Operator asks local Stele to compute the diff from Git and prove the worker did not modify its own declared check paths.
7. Run both quality gates. Operator runs the check itself and requires nonce-bound evidence that tests actually executed. A fresh reviewer then judges the diff against the task without seeing the worker's self-report. The deterministic result, reviewer verdict, and operator intent verdict are stored separately and must all pass.
8. Retry with information or stop. Rework includes the exact failure output and missed criterion. Execution attempts are bounded; the same failure twice is no progress, not permission to spend again. Reviewer-driven rework has its own tighter limit: two rounds, then a third rejection stops for human adjudication.
9. Merge, verify, and remember. Approved work is merged, the broader repository checks run, durable lessons are written back, and Operator leaves one clear handoff for the next session.

Review is binding, not endless

Independent review catches the class of failure a test cannot: green work that solves the wrong problem. Its rejection therefore binds, and the operator cannot silently overrule it. But a binding review is not an invitation to keep inventing improvements after every revision.

A reviewer may block only on a concrete correctness, security, data-loss, task-contract, or failing-test defect in the declared scope. It must cite evidence and batch every blocker it can see in one pass. Style preferences, naming taste, speculative hardening, optional refactors, and unrelated cleanup do not block the current task.

On re-review, the reviewer checks the requested fixes first. A new blocker can extend the loop only when the rework introduced it, or when it is a critical defect that would make shipping unsafe. Other late observations become follow-up work. After two automatic reviewer-driven rework rounds, a third rejection records the stop and sends the evidence to the operator or a human. The loop stops; it never turns rejection into approval just to finish.

One loop contract, available through MCP and CLI

Oracle protection and evidenced attempts are shared Stele capabilities, available well beyond the CLI. Local MCP exposes verify_loop, run_loop_attempt, and finalize_loop; the grouped inspect and task actions expose the same operations. The CLI equivalents are shown below.

The default MCP form is inspect(action="loop", node_id="TASK-12", base="main", branch="worktree-agent-12"). The flat tool accepts the same task and Git refs.

Both routes use trusted local Git state. Exit code 0 means the protected paths are untouched; 1 means the worker changed its oracle and the work is rejected; 2 means the result cannot be certified. Unknown fails closed.

An attempt first requires a clean registered Git worktree, binds its immutable commit and the approved command hash, then runs the task's declared check with credentials removed from the environment and a fresh STELE_LOOP_NONCE. It verifies the same clean snapshot again after execution. The check must print one STELE_LOOP_EVIDENCE={...} line using schema stele.loop.evidence.v1, echo that nonce, and report executed, passed, failed, and skipped counts. Missing, stale, malformed, or zero-execution evidence counts as unknown, never as green. The exact command, output excerpts, counts, failure signature, and verdict remain on the task.

What makes this loop effective

• It separates maker, checker, and reviewer. The worker supplies a patch and evidence, never its own verdict.
• It rejects verifier gaming mechanically. A passing test does not count if the patch changed the test or fixture that defines success.
• It treats zero execution as unknown. A cached result or silently skipped suite is not promoted to a pass.
• It makes retries learn. The next attempt receives the exact failure, while repeated failures trigger a brake.
• It bounds disagreement. Reviewers batch real blockers; bikeshedding becomes follow-up work, and a third rejection returns the decision to a person instead of starting another automatic round.
• It compounds project memory. The attempt trail stays on the task; only durable conclusions become knowledge that resurfaces on related work.

When should you use an autonomous agent loop?

Start with work whose finish line can be observed: a failing test, a build error, a migration with a validation command, or a measurable threshold. Keep architecture choices, security-sensitive changes, production deployment, and other judgment-heavy work under closer human supervision. Operator can still coordinate unchecked tasks, but it says plainly that a human is the gate, standing in for a deterministic oracle.

Further reading on loop engineering

• Anthropic: Loop engineering: getting started with loops covers the turn-based, goal-based, time-based, and proactive loop taxonomy.
• Jack Njoroge: The Operator Loop Stack covers the five-layer harness, contract, state, checker, and checkpoint model.
• Code as Agent Harness is a research survey of executable, verifiable, and stateful agent systems.
• SWE-Marathon is a benchmark and failure taxonomy for ultra-long-horizon software work.