Loop Engineering and UHP

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.

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-08-11 does not define a loop scheduler or recursive-goal engine. It does provide several execution primitives that 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.

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.

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.
• 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 or goal system a loop does not establish UHP adoption.

Related pages

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

Primary sources

• Addy Osmani — Loop Engineering, 7 Jun 2026
• IBM — What is loop engineering?, 17 Jul 2026
• Addy Osmani — Software Factories, Light and Dark, 20 Jul 2026
• Addy Osmani — Practical Loop Engineering, 14 Aug 2026
• UHP 2026-08-11 specification source