Two different projects
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 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 and permissions.
| Question | UHP | Harness Protocol |
|---|---|---|
| What is portable? | How a client executes work through harnesses | How harness configuration is represented |
| Primary artifact | HTTP API + object/event semantics | harness.yaml profile and schema |
| Runtime lifecycle? | Yes: tasks, sessions, files, streaming, cancellation | Not its primary v1 purpose |
| Configuration portability? | Configured harness object exists, but UHP is not a portable YAML profile standard | Yes, this is the core problem |
| Could they coexist? | Conceptually yes: a portable profile could configure a runtime that is then driven through an execution protocol. | |
Why this matters
“Harness interoperability” is not a single problem. Teams may need portable configuration, runtime execution, tool connectivity, policy supervision and cross-agent communication. A useful architecture chooses a standard for each boundary rather than expecting one protocol to own the entire stack.
Status as of 15 August 2026
UHP's published protocol version is 2026-08-11. Harness Protocol describes its v1 Schema layer as a candidate/current layer, with Exchange and Registry layers planned or drafted beyond it. Treat the two projects as independent unless their maintainers announce explicit interoperability.