UHP vs Harness Protocol
UHP standardizes client-to-harness execution. The harnessprotocol.io project standardizes portable harness configuration and now an accepted exchange layer. A separate SuperQode-internal contract also uses the name Harness Protocol v1 and should not be conflated with either.
Page reviewed 4 Oct 2026 Source and review policy
Review configuration before it reaches a runtime
Section titled “Review configuration before it reaches a runtime”The Harness Protocol changelog still records v1.1.0 and accepted Exchange work; its Exchange contract defines signed consent-first fragment sharing. The README’s Schema candidate label and changelog’s earlier stable-release wording remain distinct source scopes. UHP 2026-09-28 Draft governs execution. All were reopened 4 October 2026.
A useful import procedure is:
- Verify the offer identity, signature and expiry under the Exchange contract.
- Preview the exact fragment: instructions, permissions, plugins, MCP servers and environment requirements.
- Obtain the receiving host’s applicable approval and merge policy; a sender’s signature does not grant local authority.
- Apply the accepted configuration, then discover or inspect the effective runtime before submitting work.
| Artifact | What acceptance proves |
|---|---|
| Signed offer | Which sender attested to the offered bytes |
| Accepted configuration fragment | What the receiver chose to apply |
| Effective configured harness | What the actual runtime admitted |
| UHP Response | What work was submitted/executed under the UHP lifecycle |
A signed fragment that adds an MCP server can change both the tool surface and credential boundary. Follow tool-surface coherence and Harness Plugins when deciding how the host binds it. No standardized harness.yaml→UHP conversion is established; profile exchange and complete-harness execution remain separate contracts.
Two different interoperability problems
Section titled “Two different interoperability problems”Unified Harness Protocol (UHP) is initiated and led by HarnessRouter. Its primary contract is a common HTTP execution surface between a client and a server that drives complete harnesses.
Harness Protocol at harnessprotocol.io is a separate open specification centered on a vendor-neutral harness.yaml profile. Its current Schema layer captures operational configuration such as plugins, skills, MCP servers, environment requirements, instructions, permissions and governance policy. The project has also shipped an accepted Exchange layer for consent-first sharing of harness fragments.
| Question | UHP | Harness Protocol (harnessprotocol.io) |
|---|---|---|
| What is portable? | How a client executes work through complete harnesses | Harness configuration and signed exchange of harness fragments |
| Primary artifact | HTTP API + object/event semantics | harness.yaml, JSON Schemas and Exchange offer envelopes |
| Runtime task lifecycle? | Yes: tasks, sessions, files, streaming, cancellation | No UHP-style agent-work execution lifecycle; Exchange governs sharing/applying configuration fragments |
| Configuration portability? | Configured harness objects exist, but UHP is not a portable YAML profile standard | Yes; the v1 Schema layer is the core configuration format |
| Exchange/sharing? | Not a portable profile-exchange protocol | Accepted Exchange layer provides signed, consent-first Offer → Preview → Accept / Edit / Reject → Apply sharing |
| Could they coexist? | Yes in principle: a portable profile can configure a runtime that is then driven through UHP | Yes in principle: configuration/exchange can remain separate from execution |
Current Harness Protocol status
Section titled “Current Harness Protocol status”The current canonical repository records v1.1.0 on 27 July 2026. That release accepted HEP-7’s Exchange layer after both its format and runtime prototypes shipped in the harness-kit reference implementation.
The status needs to be read by layer rather than collapsed into one maturity label:
- Schema: v1 is the current configuration layer. The repository README still labels the Schema layer
v1 — candidate, while the changelog recordsv1.0.0as the first stable release. Theharness.yamlversionremains"1"and its v1 schema identifier is frozen. - Exchange: accepted and shipped with specification release
v1.1.0. It defines a signed offer envelope and consent-first peer-to-peer fragment exchange, with ed25519 sender identity and optional X25519 payload encryption. The reference runtime supportsharness exchange keygen/offer/accept. - Registry: HEP-8 remains in Review and unreleased. Its hosted registry/service prototype is explicitly still unstarted in the current changelog.
Name collision: SuperQode also has a “Harness Protocol v1”
Section titled “Name collision: SuperQode also has a “Harness Protocol v1””Current SuperQode documentation uses Harness Protocol v1 for a separate internal control-plane contract. It normalizes how SuperQode harness adapters are described, created, messaged, resumed, steered, cancelled, checkpointed and exported through one session/event/evidence model. Its reference adapters include SuperQode Core, direct Python harnesses and ACP.
That SuperQode contract is not the same artifact as the harnessprotocol.io specification described above. It also does not replace UHP: SuperQode separately implements a UHP client/adapter for connecting to UHP servers. When citing “Harness Protocol,” name the project or repository to avoid ambiguity.
Why this matters for UHP
Section titled “Why this matters for UHP”“Harness interoperability” is not a single problem. Teams may need portable configuration, configuration exchange, runtime execution, tool connectivity, policy supervision and cross-agent communication. A useful architecture chooses a contract for each boundary rather than assuming one similarly named protocol owns the whole stack.
For UHP specifically, the important boundary remains stable: UHP standardizes task/session/file/artifact execution through complete harness runtimes. The harnessprotocol.io project standardizes how harness configuration is represented and exchanged. SuperQode’s same-named internal contract standardizes its own adapter/session/evidence control plane.
Related reading
Section titled “Related reading”For adjacent portability boundaries, compare Agent Plugins and the UHP architecture. Configuration portability alone does not establish execution interoperability.