Concepts

Loop engineering with Stele Operator

Loop engineering is the practice of designing the system that tells an AI agent what to do next, checks the result, retries with evidence, and knows when to stop. Stele Operator is our reference implementation: a task-driven agent loop with durable state, protected checks, independent review, and explicit human checkpoints.

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, not a replacement for prompt or 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.

Operator is the proof, memory is the substrate

Stele does not require every team to adopt our runner. The graph can provide contract, state, and cross-iteration learning to a loop you already run. Operator shows how those pieces fit together in one complete implementation workflow.

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.

Layer	How Stele Operator handles it
Harness	Your existing agent supplies tools, shell access, workers, and isolation. Operator does not require a vendor-specific teams mode.
Loop contract	The task carries its purpose, scope, success criteria, optional runnable `check`, and protected `check_paths`.
State	Tasks, claims, attempts, comments, decisions, lessons, risks, and handoffs survive sessions in the project graph.
Checker	Local MCP or CLI protects the oracle; Operator then runs the declared check and reads what actually executed.
Human checkpoint	You choose the autonomy level. Shared-infrastructure pushes always require confirmation, and ambiguous or failed gates come back with evidence.

How Stele Operator runs, step by step

Authenticate and choose scope. Operator confirms the Stele session, project, focus area, and whether you want Auto, Batch, or Step-level checkpoints.
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.
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.
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.
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.
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.
Run both quality gates. Operator runs the check itself with caches defeated and confirms that tests actually executed. A fresh reviewer then judges the diff against the task without seeing the worker's self-report. Mechanical correctness and intent review must both pass.
Retry with information or stop. Rework includes the exact failure output and missed criterion. Attempts are bounded; the same failure twice is no progress, not permission to spend again.
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.

One verifier, available through MCP and CLI

Oracle protection is a shared Stele capability, not CLI-only behavior. A local MCP client can call the loop inspect action or the flat verify_loop tool. When that surface is unavailable, Operator runs the equivalent command:

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.

terminal

$stele loop verify --task TASK-12 --base main --branch worktree-agent-12

oracle untouched · 2 implementation files changed

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.

Why hosted MCP cannot certify a local diff

The hosted server can read the task contract, but it cannot inspect your local repository. It therefore returns an unknown result and directs the agent to local MCP or the CLI. That boundary is deliberate: a verifier that cannot see the evidence must not claim a pass.

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 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—not a deterministic oracle—is the gate.