Skip to content
UHPUHPDeveloper Guide
Independent developer guide. Not affiliated with HarnessRouter or the official UHP project.

Unified Harness Protocol, explained for builders

Build one client for complete agent runtimes. Understand the execution contract, choose an integration and check the evidence behind each capability.

Page reviewed 8 Nov 2026 Source and review policy

Learn the boundary

Understand what UHP standardizes and which responsibilities stay inside the agent runtime.

Understand UHP

Build an integration

Discover capabilities, negotiate a version and follow a task through its final result.

Run your first task

Compare interfaces

Choose between harness execution, tool connectivity and interactive client interfaces.

Choose a boundary

One execution boundary, distinct responsibilities

Section titled “One execution boundary, distinct responsibilities”
  1. ClientRequest + results
  2. UHP serverContract + authority
  3. HarnessLoop + session state
  4. Tools + modelActions + inference
Your client submits work to a UHP server. The complete harness owns its loop, tools and model calls.

A configured harness owns the agent loop. Your client uses the UHP contract to request work, observe results and continue a session. An adapter behind the server does not establish native upstream adoption.

Choose your integration

Start at the boundary you need to control. These interfaces can compose in one system.

Start with UHP. Discover the server's capabilities, choose a configured harness and track tasks and continuation. Build the smallest UHP workflow. Tools inside the harness may still use MCP.

Start with MCP. Connect the application to tools, resources and prompts. It does not replace complete-harness execution. Compare the two boundaries.

Evaluate Agent Client Protocol. Use the editor-to-agent interface when the client needs interactive coding sessions and permission exchange. Check ACP's scope and composition.

Evaluate A2A. Exchange work with an agent service, then decide whether it uses UHP internally to drive a harness. Compare delegation and execution.

Seven subjects; every guide has one primary home.

Harnesses & Platforms

Choose an execution gateway, coding harness, SDK or runtime service.

31 guides · browse this subject

Execution gateways

Coding assistants

Agent runtimes

Frameworks and SDKs

Runtime services & tooling

Protocols & Standards

Compare interfaces by their boundary, maturity and authority.

34 guides · browse this subject

Tools and extensions

Client and UI interfaces

Agent exchange and discovery

Identity and control

Events, trajectories and assets

Engineering Guides

Design orchestration, recovery and execution integrity.

18 guides · browse this subject

Orchestration and execution

State and recovery

Trust and execution integrity

Protocol2026-10-19Draft; optional Environments
Reference implementationv0.38.5Stable release; development main is separate
Conformance source104 checksPackage 2026.10.19.post5; source count, not a server result

The released backend set is now 30 offered bases. v0.37.0 added four harness families — Mistral Vibe, Docker Agent, fast-agent and Deep Agents Code — and v0.33.0 had added five, including Qoder Cloud Agent, the first remote runtime. Current stable is v0.38.5, which carries the UHP 2026-10-19 additions — input_history, per-turn created_at/completed_at, background answers reporting in_progress, and the deprecated models-view fallback — reports an interrupted or timed-out task as failed with a reason instead of ending silently, and answers a read that could not be made whole with an error rather than with whatever happened to be there. UHP itself published 2026-10-19, following the optional Memories chapter it added in 2026-10-04; CE gateway/app.py still advertises 2026-09-28, and it does not advertise memories or harness_retirement, so those two capabilities are not established in the reference implementation; from v0.36.0 it does advertise input_history: true, which the optional 2026-10-19 chapter now makes established, and from v0.37.11 it advertises harness_idempotency: true, so a retried harness create does not make a second harness. Read the release tracker for the exact version history, and the Environments guide before selecting reusable project state. The task override is metadata.environment; the specification’s drift note explains the conflicting upstream table.

The versioned UHP source, stable HarnessRouter release and conformance package underpin the status above. This independent publication’s source policy explains how current guidance and historical results are kept distinct.