Comparison
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.
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.