Verified relationship
HarnessRouter Community Edition lists Hermes as a supported harness backend and the UHP specification uses hermes as an example stable base string.
In the UHP model, the product does not need to speak a Hermes-specific product integration. It targets a configured harness through the UHP server. The server is responsible for driving the actual backend and translating its execution into UHP tasks, sessions, events, artifacts and errors.
What UHP tries to normalize
- Task submission and terminal status.
- Progress streaming.
- Session continuation.
- Files and artifacts where supported by the conformance class.
- Cancellation behavior.
- Structured errors and capability discovery.
What is not proven
Why the distinction matters
A reference implementation can adapt an existing harness without that harness vendor changing its own API. Native adoption would be a stronger ecosystem signal: it would mean a vendor, tool or independent runtime exposes or consumes UHP directly, reducing dependence on one adapter implementation.
Current developer implication
If you are evaluating UHP today, test the behavior you need through the official conformance suite and your target backend. Do not assume that every backend feature maps perfectly just because the common API exists. The protocol deliberately defines common semantics, while backend-specific capabilities may continue to differ.
Related pages
Read UHP architecture, conformance, and the adoption tracker.