Independent developer guide. Not affiliated with HarnessRouter or the official UHP project.

Loop Engineering and UHP

Loop engineering is the emerging practice of designing autonomous feedback cycles that repeatedly discover or receive work, run an agent, evaluate evidence and decide whether to continue, retry, escalate or stop. It sits above the execution harness: the loop owns recurrence and completion policy, while the harness owns the runtime in which an agent turn executes.

Page reviewed 4 Oct 2026 Source and review policy

Concept: emerging engineering practiceCase-study protocol scope: 2026-09-12

Short answer

Loop engineering is the practice of designing an autonomous, feedback-driven control cycle around an agent instead of manually prompting that agent turn by turn. A loop normally has a goal or recurring trigger, an execution step, observable evidence, an evaluator or deterministic check, persisted state and an explicit rule for whether to continue, retry, escalate or stop.

The term is emerging engineering terminology, not a protocol standard. Addy Osmani published an explicit definition on 7 June 2026, describing a shift from personally prompting an agent toward designing the system that prompts and checks it. IBM published a separate definition on 17 July 2026, describing loop engineering as the design of agentic workflows that repeatedly act, observe, decide and adjust until a goal is complete. Osmani’s later practical guidance and software-factory model make the architectural distinction clearer: the loop is the behavior and feedback cycle; the harness is the environment and control boundary in which that behavior runs.

That distinction makes loop engineering directly relevant to UHP, but it does not make loop engineering part of UHP.

Define one iteration receipt before enabling recurrence

A recurring loop should persist an iteration receipt that survives the scheduler or process: trigger identity, goal revision, admitted execution ID, artifact revision, verifier result, remaining budget and next decision. The Qwen recovery implementation and Hermes trigger work below are implementation examples, not a shared loop protocol.

trigger → claim iteration → execute → verify artifact → persist decision
           ↑                                             │
           └──────── new iteration only after settlement ┘

Evidence at iteration end	Decision
Acceptance checks pass on identified artifact	Complete this goal revision
Deterministic failure and recoverable defect	Continue with one bounded repair brief
Agent stopped but effect/result uncertain	Reconcile original execution before retry
Budget exhausted or required human decision	Persist gap and escalate
Same unchanged failure repeatedly recurs	Stop automatic repetition; retain diagnosis

For a scheduled documentation update, “agent returned normally” is weaker than a validated source change. Attach the validator result to the exact revision, then persist the decision before the next tick can claim work. A restart must inspect that receipt instead of interpreting the last prompt as new authorization.

Keep recurrence separate from runtime capacity: a valid schedule does not grant an available process slot. Likewise, Harness-of-Harness supplies a research workflow for carrying project evidence, not an automatic guarantee that any unattended loop is safe or complete.

The architectural boundary

A useful decomposition is:

Outer loop controller
  ├─ trigger / schedule / queue
  ├─ goal and stopping condition
  ├─ persisted loop state
  ├─ verifier / eval / policy gate
  │
  └─ execute one unit of agent work
        │
        │ optional UHP client boundary
        ▼
      UHP server
        │
        ▼
      configured harness
        ├─ model
        ├─ tools / MCP
        ├─ files / sandbox
        ├─ session state
        └─ subagents / internal orchestration
        │
        ▼
      events, outputs, artifacts, status
        │
        └──────────────► verifier decides: continue / retry / escalate / stop

The outer loop decides when and why another iteration should happen. The harness decides how an agent iteration actually executes. UHP can normalize the boundary used to invoke and observe the harness without owning the surrounding recurrence policy.

Loop versus harness versus orchestration versus protocol

Layer	Primary responsibility	Typical concerns
Loop	Repeated progress toward a goal or recurring operational task	trigger, goal, stop condition, retry, evaluation, persisted progress
Harness	Safe and capable execution environment around the model	tools, sandbox, context, memory/session, permissions, skills, subagents
Orchestration	Coordination of multiple workers, tasks or execution paths	fan-out/fan-in, queues, dependencies, concurrency, routing
Protocol	Interoperability contract between independently implemented systems	request/response semantics, lifecycle, events, capabilities, errors

These layers can overlap inside one product, but they should not be collapsed conceptually. A coding agent may ship its own loop primitive, its own harness runtime and its own orchestration features. That still does not make those product-specific controls a portable wire protocol.

Likewise, a loop can invoke several different harnesses. A protocol such as UHP is valuable precisely because the loop controller can target a stable execution contract while the backing harness implementation changes.

What UHP can contribute to a loop

UHP 2026-09-12 still does not define a loop scheduler or recursive-goal engine. The version is additive to 2026-08-11: it adds the optional Harness Plugins sub-protocol for carrying Agent Plugins packages — including packaged skills and MCP servers — into configured harnesses, but it does not move trigger cadence, goal evaluation, retry policy or stopping rules into UHP. The execution primitives below remain the parts an external loop controller can use as building blocks:

Loop concern	UHP relationship
Trigger / cadence	Not defined by UHP. A scheduler, queue, webhook or human initiates work.
Goal / stopping rule	Not defined as an outer-loop primitive. The client or loop controller owns the completion policy.
Execute agent work	UHP provides a stable client→server→configured-harness execution boundary.
Observe progress	UHP events and response/task state can provide machine-readable execution evidence.
Preserve continuity	UHP sessions can preserve conversation/workspace continuity across related work.
Retrieve outputs	Files/artifacts are available according to the server’s supported conformance capabilities.
Cancel work	UHP lifecycle controls can stop an in-flight unit of work.
Evaluate quality	Not automatically provided. Tests, evals, policy checks or independent reviewers remain external unless the harness itself implements them.
Decide next iteration	Not defined by UHP. The outer controller consumes evidence and decides what happens next.

This separation is deliberate. A protocol can standardize execution without prescribing whether the caller uses a one-shot request, a scheduled maintenance loop, a CI remediation loop, a queue-driven software factory or a human-supervised workflow.

Event-driven triggers are a different loop contract from schedules

A recurring agent task does not have to wake up on a clock. It can also be push-driven: an external event arrives, a trusted ingress validates and deduplicates it, and that event causes an existing durable job definition to run immediately. This can remove wasteful polling when the source system already emits a reliable event, but it shifts correctness pressure from calendar arithmetic toward authentication, replay protection, delivery identity, deduplication and owner scope.

Hermes PR #95262, merged on 14 September 2026 and now included in stable v2026.9.14 / v0.21.3, makes that distinction concrete. A webhook route can name an existing cron_job; after the normal webhook authentication, rate-limit, filter, script and idempotency path, Hermes returns HTTP 202 Accepted and runs the referenced job through the same claimed-run body used by scheduler/manual execution. The job’s own prompt, skills, model and delivery configuration remain authoritative, while the rendered webhook payload is transient per-run context. CLI subscription creation validates and canonicalizes the job reference up front, and cron_job is mutually exclusive with deliver_only.

The implementation also exposes a less obvious invariant: trigger identity must not replace execution ownership. The event-trigger path explicitly re-enters the routed profile’s runtime scope before resolving cron/jobs.json and executing the job, because a /p/<profile>/ route otherwise risks resolving job state, configuration or secrets from the gateway’s default profile. Route-level webhook skills are also skipped in cron_job mode so an ingress route cannot silently override the durable job’s own skill policy.

Upstream reports 6/6 new adapter/unit tests, 3/3 new CLI tests, 60/60 sibling webhook tests, a temporary-home E2E covering fire/unknown-reference/paused-job behavior, and a zero-mock live HTTP POST that fired a real script job and recorded last_status: ok. This is strong implementation evidence for the trigger boundary and is now released in Hermes v0.21.3; it is not a new UHP, MCP, ACP or A2A wire rule.

The reusable trigger contracts can therefore be separated cleanly:

Trigger model	Typical source	Main correctness questions
Wall-clock schedule	cron / calendar	timezone, DST, repeated-hour policy, strictly-later next fire
Elapsed duration	interval / delay	real elapsed time, monotonic/absolute timeline
Event-driven	webhook / queue / callback	authentication, replay/idempotency, claim/dedupe, durable owner scope
Manual / operator	human or control API	authorization, approval boundary, duplicate submission

UHP does not standardize those trigger mechanisms. An event-driven controller can still invoke UHP after it decides that work should run, just as a scheduler can; webhook subscription semantics, ingress authentication and event deduplication remain outside the current UHP execution contract.

Why the term matters for harness interoperability

Loop engineering shifts the integration pressure from a human-facing chat surface toward a machine-operated execution boundary. A durable loop needs more than a model response: it needs reliable lifecycle state, resumability, machine-readable progress, stable error semantics, artifacts and a clear terminal outcome. Those are exactly the kinds of surfaces that determine whether an agent runtime can participate safely in unattended or semi-autonomous workflows.

For UHP research, this creates a useful test question:

Can an outer loop replace one harness with another without rewriting its entire execution-control path?

UHP is intended to make that substitution more practical by normalizing the client-to-harness boundary. It does not guarantee that two harnesses have identical internal tools, subagents, permission models, model behavior or quality characteristics.

Safety and completion are part of loop design

A loop that can continue automatically also needs a reason to stop. Current loop-engineering guidance consistently emphasizes explicit goals, deterministic or independently checked completion criteria, bounded iterations and retained evidence. Osmani’s practical guidance adds an important operational constraint: the evaluator behind an automated goal is not equivalent to human judgment about whether the resulting change is actually desirable.

For long-running engineering loops, useful controls include:

explicit iteration, time, token or financial budgets;
deterministic checks where possible instead of self-assessed completion;
a separate verifier or review gate for consequential changes;
persisted state outside a single model context so the next iteration can recover what was tried;
isolated workspaces when iterations or workers run concurrently;
idempotent or replay-aware external actions;
escalation when evidence is ambiguous rather than infinite retry;
human approval for irreversible, production, security-sensitive or high-impact actions.

Those controls belong to the loop/harness policy layer. UHP may transport execution state used by the policy, but the current protocol does not declare that a passing UHP task is semantically correct, safe to deploy or sufficient to terminate an outer engineering loop.

Process death needs a recovery contract, not just persistence

Persisting a transcript or journal is not enough to make a long-running workflow recoverable. After a crash or forced exit, the next process also needs a trustworthy way to distinguish unfinished live intent from settled history, prove that the former writer is no longer authoritative, and expose the interrupted work without pretending that it completed or automatically resumed.

Qwen Code PR #12159, merged 18 September 2026 at 06:42:17 UTC as 0417f0d2, makes that boundary concrete for its Workflow runtime. Every registered workflow run now writes a small checkpoint.json beside the durable journal and removes the checkpoint when the run settles. The checkpoint records writer identity (pid, hostname), script/workflow identity, metadata, arguments, source reference and lineage. A later process may claim an abandoned checkpoint only on the same host and only after the prior writer is no longer running; it then takes the run lock, re-reads the checkpoint, and refuses to overwrite a checkpoint that changed or a same-or-later settled snapshot that already exists.

A valid claim does not invent continuation. Qwen writes an ordinary historical snapshot with status: failed and error: "interrupted: the process running this workflow exited before it finished", derives finished-agent counts from the journal, retains the run arguments up to a 256 KiB limit, and removes the checkpoint. The recovered history can then drive an explicit resume that replays already-finished agents from the journal and dispatches only unfinished work. Automatic resumption remains out of scope in this merge.

The recovery surface is intentionally host-specific:

ACP session startup claims abandoned runs before reading workflow history, so an interrupted run becomes a failed historical task instead of disappearing from the session task list.
Interactive CLI startup reports interrupted runs and gives the user the explicit Workflow(..., resumeFromRunId) call needed to continue.
Headless mode does not claim abandoned runs; a later interactive or ACP start performs recovery instead.

The reusable design is a three-record separation:

Record	Role after a crash
Checkpoint	Small liveness/ownership record showing that a run had not yet settled.
Journal	Durable execution evidence from which completed sub-work can be replayed or counted.
Settled snapshot/history	Authoritative terminal representation presented to users and integrations.

The important invariant is claim before classification: recovery must establish that the previous writer has lost authority, re-check under the relevant lock, and only then translate abandoned live intent into a truthful terminal history record. That prevents a restarted controller from silently losing work, double-owning a still-live run, or labelling an already-settled run as interrupted.

This is Qwen host/runtime behavior, not a new ACP or UHP wire rule. UHP’s five normative task states and session-continuation semantics remain unchanged; a harness’s internal workflow checkpoint/journal machinery sits behind that protocol boundary. Likewise, Qwen’s ACP task-list exposure here is an integration behavior of its ACP host, not an ACP protocol revision.

Time semantics are part of unattended-loop correctness

A scheduled loop has at least two different time contracts that should not be implemented as if they were the same thing:

wall-clock schedules such as “09:00 every day”, where the intended local clock time should normally survive a UTC-offset change; and
elapsed durations such as “run again in two hours”, where two real hours should elapse even if a daylight-saving transition occurs in between.

Recent Qwen Code and Hermes fixes expose why that distinction matters. Qwen Code PR #11723, merged on 12 September 2026 as b5c7635f, changed its cron next-fire scan from local Date mutation to epoch-time traversal while retaining local-field matching. The motivating fall-back cases could otherwise return a next fire time in the past, skip the second occurrence of the repeated hour, make a healthy durable task look missed, or leave a negative next-run countdown. The focused upstream suite records 36/36 cases passing after the change, including five new DST regressions.

Hermes PR #109532, merged on 13 September 2026 at 23:46:45 UTC as ee445299, closes the corresponding class across a broader scheduler surface. It keeps cron jobs anchored to the configured IANA timezone’s wall clock, performs interval and relative-delay arithmetic in UTC so real elapsed durations survive spring-forward/fall-back, and adds a fold-aware guard so a candidate inside the repeated autumn hour is strictly later than the base instant. Upstream reports 1,275 cron tests passing across 106 test files plus a fresh-interpreter E2E for persisted next_run_at.

The reusable scheduler invariants are therefore stronger than “the cron expression parsed”:

Scheduling concern	Failure mode	Useful invariant
Daily wall-clock job	Fires an hour early/late after offset change	Resolve against the configured timezone, not a fixed historical UTC offset
Interval / `in Nh` delay	Elapsed time becomes one hour shorter/longer across DST	Perform duration arithmetic on an absolute timeline, then convert for display
Fall-back ambiguity	`next_run_at` can be earlier than the base and immediately re-fire	The computed next instant must be strictly later than the scheduling anchor
Repeated local hour	Scheduler-specific duplicate/skip behavior is assumed rather than specified	Define and regression-test the product’s repeated-hour policy explicitly

The last row matters because the two upstream schedulers do not document the repeated-hour policy identically. Qwen’s PR explicitly traverses both occurrences of the fall-back hour for matching fixed-hour jobs, while the Hermes PR describes its wall-clock behavior in its own once-per-repeated-hour terms. A portable outer loop should therefore treat repeated-hour behavior as scheduler policy, not infer one universal cron rule from a local timestamp.

This evidence does not move scheduling into UHP. UHP still begins at the execution boundary after some external scheduler, queue, webhook or operator decides to start work. A UHP task can report that one invocation executed correctly while the surrounding loop still has a timing bug that skipped, duplicated or immediately retriggered that invocation.

From loop to software factory

Osmani’s July 2026 software-factory framing expresses the progression as loop → harness → factory. In that model, a software factory is many harnessed loops consuming a queue of work and feeding automated checks plus a review/deployment gate. The important architectural point is not the metaphor; it is the separation of responsibility:

the loop supplies repeated behavior and feedback;
the harness supplies the bounded execution environment;
the factory coordinates many such loops and the production flow around them;
human or organizational policy still owns the consequences of approval and release.

UHP fits, when useful, at the repeatable execution seam between the outer controller/factory and a configured harness. It is not itself the factory, scheduler, evaluator or deployment gate.

Evidence boundaries

Emerging term: established in public engineering usage during 2026; not a standards-body protocol term.
Early explicit definition reviewed here: Addy Osmani, 7 Jun 2026.
Independent enterprise definition: IBM, 17 Jul 2026.
Practical expansion: Osmani, 14 Aug 2026, covering goal-, time- and schedule-driven loops and verification boundaries.
Current UHP boundary (4 October 2026): 2026-09-28 retains optional Harness Plugins and adds Environments but no normative outer-loop scheduler, event-subscription primitive, recursive-goal, evaluator or stopping-policy primitive.
Event-trigger evidence: Hermes PR #95262 demonstrates a push-triggered durable-job path with shared claim/dedupe semantics and routed-profile ownership; it is included in stable v2026.9.14 / v0.21.3, not a UHP/webhook standard.
Process-restart evidence: Qwen Code PR #12159 demonstrates checkpoint/journal/snapshot separation for workflow process death, with same-host dead-writer claiming and explicit failed/interrupted history before user-directed resume; it is current-main Qwen runtime behavior, not ACP/UHP lifecycle semantics.
Scheduler evidence: Qwen Code PR #11723 and Hermes PR #109532 independently demonstrate that unattended-loop correctness includes timezone, elapsed-duration and strictly-later next-fire invariants; their repeated-hour policies should not be collapsed into one assumed semantic.
UHP relationship: architectural inference from UHP’s execution/lifecycle boundary; no reviewed UHP source defines a normative “loop engineering” primitive.
Native adoption claim: none. Calling a product’s recurring automation, webhook trigger or goal system a loop does not establish UHP adoption.

Read harness composition for child-agent and cross-harness topology, Harness-of-Harness for higher-order harness control, remote harness execution for network placement, profile isolation for owner-scope invariants across deferred work, UHP lifecycle for the protocol execution lifecycle, and conformance for what a UHP server is actually required to implement.

Short answer

Define one iteration receipt before enabling recurrence

The architectural boundary

Loop versus harness versus orchestration versus protocol

What UHP can contribute to a loop

Event-driven triggers are a different loop contract from schedules

Why the term matters for harness interoperability

Safety and completion are part of loop design

Process death needs a recovery contract, not just persistence

Time semantics are part of unattended-loop correctness

From loop to software factory

Evidence boundaries

Related pages

Primary sources