Skip to content
UHPUHPDeveloper Guide
Independent resource · Not affiliated with HarnessRouter · Site data checked 13 Sep 2026

Concepts

What is the Unified Harness Protocol (UHP)?

UHP is an open execution protocol for products that want to run complete agent harnesses through a consistent interface rather than integrate every harness separately.

Verified: Protocol: 2026-09-12Static SSG

Direct definition

Section titled “Direct definition”

The Unified Harness Protocol (UHP) defines how a client drives a complete agent harness through a UHP server. It standardizes the execution boundary: select a configured harness, submit work, observe progress, continue related work, exchange files, cancel or delete lifecycle state, receive structured failures and collect final output.

A harness is the complete runtime around a model: agent loop, tools, skills, session state and working environment. UHP intentionally does not prescribe how that runtime is implemented internally.

The integration problem

Section titled “The integration problem”

Complete agent harnesses expose more than model completion. They maintain state, run tools, manipulate files, stream intermediate events and produce artifacts. Without a shared contract, a product needs a different adapter/lifecycle model for each harness.

Product / CLI / CI job
        │
        │  UHP over HTTP
        ▼
     UHP server
        │
        ├── Codex
        ├── Claude Code
        ├── Hermes
        └── other configured harnesses

Containers, subprocesses, queues and remote workers are implementation details outside the wire contract.

What UHP standardizes

Section titled “What UHP standardizes”
  • Protocol-version negotiation and capability discovery.
  • Harness discovery and Full-class harness lifecycle management.
  • One-shot and streaming task execution.
  • Session continuation, inspection and canonical session deletion at applicable classes.
  • Optional Full-class session sharing with publish/read/revoke semantics.
  • Cancellation and terminal task states.
  • File input, artifacts and downloads at higher classes.
  • Authentication/object scoping and a machine-readable error model.
  • In 2026-09-12, an optional Harness Plugins sub-protocol for binding Agent Plugins 1.0.0 packages to a hosted harness, including package retrieval, composition and export.

The current published date-version is 2026-09-12.

What UHP is not

Section titled “What UHP is not”

It is not a model API. It drives a harness, not raw inference. It is not MCP. MCP standardizes a different tool/resource/context boundary. It is not a new plugin package format. UHP 2026-09-12 deliberately reuses Agent Plugins 1.0.0 for its optional Harness Plugins surface.

The current source also preserves two compatibility/lifecycle boundaries introduced in the preceding version:

  • Request-level tools and include are accepted but reserved and ignored; carried fields are reported in response.metadata.ignored_fields rather than becoming per-task capability grants.
  • The canonical session-delete operation is DELETE /v1/sessions/{session_id}. The older /v1/traces/{session_id} route may remain as a compatibility alias; clients should use the session path.

For session sharing, bodyless POST publishes, a share has a required url, DELETE on /v1/sessions/{session_id}/share revokes, and revocation reaches every link minted for the session.

For Harness Plugins, the server derives visible manifest/MCP/skill state from the package, keeps direct harness mcpServers and skills separate, and can export a configured harness as an installable Agent Plugins package with credentials omitted and omissions recorded. See Harness Plugins.

Current status

Section titled “Current status”

As of 13 September 2026, UHP is 2026-09-12 Draft. PR #165 merged on 12 September at 23:40:40 UTC and publishes the Harness Plugins sub-protocol plus conformance package 2026.9.12. The suite now contains 74 checks: Core 40, Extended +8 and Full +25, including capability-gated plugin checks P-01 through P-10.

HarnessRouter Community Edition’s latest stable release remains v0.16.1, published 11 September with tag target 8f976f903683b928a6cb554188547b96fbbd4d74. Checked upstream main is a7406cbde6192a5bdd8943b012574fd3ee4ac38e, the protocol merge commit.

That does not establish that the reference gateway already serves the new plugin surface. PR #165 explicitly states that the Community Edition reference implementation at the merge point still serves 2026-08-11 and reports no plugins capability; gateway support is subsequent implementation work. Stable software release, protocol publication and runtime support are separate coordinates.

The checked-in HarnessRouter reference result remains the live 64/64 passed · 0 failed · 0 skipped · 0 errored Full run from 4 September under suite 2026.8.11.post1. It remains valid for that measured revision but is not a 74/74 result. A verified HarnessRouter 74/74 Full measurement is not established at this cutoff.

Public aenawi/uhp-go remains attributable 63/63 Full, zero-skipped evidence for its pinned earlier suite revision. It is not silently upgraded to 74 checks.

HarnessRouter’s released backend set remains ten: Claude Code, Codex, Hermes, Pi, DeepSeek Harness, OpenCode, Qwen Code, Cline, Gemini CLI and Oh My Pi. Backend integration is HarnessRouter implementation evidence, not native UHP adoption by the upstream projects.

The ecosystem also includes independent UHP clients such as AIWG, SuperQode and SourceShift mini-ork. Published cross-server client interoperability and native upstream-harness UHP adoption remain not established unless a primary source says otherwise.

Section titled “Read next”

Continue with architecture, Harness Plugins, conformance, UHP clients, uhp-go, HarnessRouter, and releases.

Primary sources

Section titled “Primary sources”