Level 3 · Loop Engineering

Design the Harness Before You Write the Prompt

Unattended agents become reliable when the prompt is only one component inside a deterministic harness that owns state, verification, retries, cost, and shutdown.

Start With the State Machine

The central mistake in long-running agent work is treating autonomy as a longer chat session. A frontier-grade loop is closer to a production workflow: every run has an explicit trigger, a bounded execution step, a verifier, a durable output, retry rules, escalation rules, and a stopping condition. The model can reason inside a state, but the harness decides which state comes next.

Design the state machine before the prompt. A useful skeleton is `queued -> prepared -> executing -> verifying -> repairing -> reviewing -> complete`, with terminal states for `blocked`, `skipped`, and `failed_budget`. Each transition should be caused by observable evidence, not by the agent saying it is done. A test artifact, benchmark number, changed file list, review score, deployment URL, or structured error is a transition input. Natural language summaries are logs, not control signals.

This changes how you specify work. Instead of asking an agent to “refactor the billing module,” create a job record with scope, allowed files, expected artifacts, verifier commands, max attempts, maximum spend, and escalation criteria. The execution prompt becomes narrower because the harness carries the operational contract. That makes the loop easier to resume, parallelize, audit, and kill.

Make Verification the Loop Boundary

Once the harness owns state, verification becomes the real definition of done. Do not let the same agent that implemented the change decide whether the change is correct. Route outputs through code-based gates: unit tests, type checks, linters, migrations on a branched database, Playwright traces, benchmark comparisons, snapshot diffs, security scanners, or custom assertions. For subjective review, force a reviewer skill to emit a score, binary decision, and cited evidence.

Advanced loops should require proof of work. Store test output hashes, video paths, screenshots, coverage deltas, benchmark JSON, and exact command transcripts. The point is not bureaucracy. It prevents the common failure where an agent claims it ran a check, summarizes imaginary results, and proceeds. If the verifier cannot produce an artifact, the state machine should not advance.

Verification also defines the retry policy. A formatting failure can trigger an automatic fix and one rerun. A flaky integration test might rerun twice before marking `needs_human`. A semantic regression should fork to a repair agent with the failing evidence attached. A failed asset generation step might skip that asset if the job contract allows degraded output. Without these rules, long loops either spin until they burn money or stop at recoverable errors.

Keep Context External and Small

After verification, the next bottleneck is context bloat. Long loops fail when every iteration drags the full story forward. The harness should persist state outside the model: markdown ledgers for simple workflows, SQLite or Postgres for durable queues, and object storage for large artifacts. Each agent invocation should receive a compact job packet, relevant gotchas, current state, and pointers to artifacts. It should not inherit the entire transcript unless the transcript is itself evidence.

Memory should be curated, not comprehensive. Large skill libraries and auto-generated manuals often reduce accuracy because the model spends attention on irrelevant policy. Maintain short files of project-specific gotchas: commands that must be run from a subdirectory, migration hazards, flaky test names, local conventions, forbidden APIs, deployment footguns. A retrospective step can propose memory updates after failures, but commit only the rules that would have prevented a repeat.

Separate skills from routines. Skills describe how to perform a class of work: review a TypeScript change, triage a failing check, optimize a slow query. Routines decide when the skill runs, with which tools, and where the output goes. This separation matters because you will tune skills frequently while keeping scheduling, budgets, and state transitions stable.

Parallelize With Isolation, Not Hope

Once state and verification are explicit, concurrency stops being chaos. Break a project into jobs with clear inputs and outputs, then run specialist agents in isolated worktrees, containers, or sandboxes. For database-backed systems, pair each branch with a branched database or disposable schema. For browser work, isolate ports, storage state, and artifacts. Parallel agents should never share a mutable checkout, live database, or single scratch file unless the harness serializes access.

The useful unit of parallelism is not “more agents.” It is independently verifiable work. Code review can fan out by subsystem. Bug triage can fan out by failing test file. Research can fan out by hypothesis, then converge through a synthesis verifier. Implementation can fan out only when interfaces are already stable. If interface design is unresolved, parallel coding creates merge debt faster than it creates value.

Move human checkpoints late, but keep architectural control early. Use an adversarial planning pass before execution: have a model challenge assumptions, missing edge cases, state boundaries, and unverifiable requirements. Once the plan is crisp, let agents run AFK through implementation and deterministic repair. Human review should inspect evidence, diffs, and unresolved escalations, not babysit each command.

Route Models and Spend Like Infrastructure

A harness also gives you a cost model. Use cheap models for classification, queue grooming, log summarization, retry categorization, and simple planning. Reserve stronger models for ambiguous implementation, architectural critique, and repairs that require deep codebase reasoning. If your harness forces every state transition through a flagship model, you have built an expensive shell script with a large context window.

Measure dollars per accepted artifact, not tokens per request. High spend is rational when many isolated agents are completing verified work in parallel. It is waste when a single loop repeatedly re-reads the same files, ignores the same failing test, or retries without new evidence. Track per-job token use, wall time, verifier failures, repair attempts, model choice, and final disposition. Build a small dashboard or at least structured logs that let you identify which state burns money.

The final stopping condition should be boring and mechanical. Stop when all required artifacts pass verification, when a budget or attempt limit is reached, when the same failure class repeats, when a required dependency is unavailable, or when the job violates a pre-tool safety hook. That is the difference between an unattended agent and an unattended chat: the harness knows when continuing is no longer work.

Key takeaways

  • Treat the prompt as the execution payload inside a state machine, not as the workflow itself.
  • Advance loop state only on verifiable artifacts: tests, hashes, traces, benchmarks, diffs, scores, or structured errors.
  • Persist memory outside the model and keep each invocation small, current, and job-specific.
  • Parallelize only independently verifiable work, using isolated worktrees, sandboxes, and branched state.
  • Route cheap models to routine control tasks and stronger models to ambiguous implementation or repair.
  • Track cost per accepted artifact so higher spend reflects throughput rather than repeated failure.