Comparison
UHP vs Agent Host Protocol (AHP)
UHP and AHP both place a server between clients and agent runtimes, but they standardize different responsibilities. UHP makes complete harnesses interchangeable behind a task API; AHP makes shared agent-session state authoritative and synchronized across multiple clients.
The one-sentence difference
Section titled “The one-sentence difference”UHP standardizes how a client asks a server to run a selected, configured complete harness. AHP standardizes how an authoritative agent host synchronizes shared session state across multiple clients.
That difference matters because the two protocols can both appear near an agent runtime without being substitutes. UHP’s abstraction boundary is client → UHP server → harness. AHP’s abstraction boundary is one or more clients → agent host → shared sessions, with the host free to use ACP or another agent-specific interface below it.
Current AHP status
Section titled “Current AHP status”Microsoft’s Agent Host Protocol (AHP) repository describes AHP as a synchronized, multi-client state protocol for AI agent sessions. The project publishes a formal normative specification, generated schemas and client libraries for Rust, TypeScript, Kotlin, Go, Swift and .NET; the repository also identifies the VS Code agent host as its reference server implementation.
The latest published AHP specification observed in this review is 0.9.0, released 28 August 2026 under the tag spec/v0.9.0. AHP is still pre-1.0, so its versioning document explicitly allows breaking changes in minor releases. It also assigns stability per channel rather than treating the complete protocol surface as uniformly stable: Root, Session, Chat, Terminal, Telemetry and Resource Watch are currently marked Stable, while Changeset and MCP are Release Candidate, Annotations are Active Development, and Automation Catalogue / Automation Run are Early Development.
The current AHP main observed after 0.9.0 contains additional conformance work, including live TypeScript session conformance for .NET, but no later published AHP specification version was found in this review.
Architectural comparison
Section titled “Architectural comparison”| Dimension | UHP | AHP |
|---|---|---|
| Primary boundary | Product/client ↔ UHP server ↔ complete harness | Multiple clients ↔ authoritative agent host ↔ shared agent sessions |
| Main goal | Make configured harness execution interchangeable behind one server contract | Keep several clients synchronized on one authoritative session/state model |
| Work abstraction | A Response is one task; Responses chain into a Session | Channels expose synchronized state; Chat carries turns, while Automation Run can represent task-level automation execution |
| State authority | Server owns UHP objects and reports harness-produced progress/results | Host owns the authoritative state tree and sequences/reconciles client actions |
| Client multiplicity | A client/server execution contract; multi-client shared-state arbitration is not its core abstraction | Explicitly designed for N clients observing and participating in shared sessions |
| Message model | HTTP resources plus SSE event streaming | Bidirectional JSON-RPC 2.0 commands, responses, notifications and action envelopes |
| Routing model | Resource endpoints and typed object identifiers | Every command/notification carries a top-level channel URI such as ahp-root://, ahp-session: or ahp-chat: |
| Transport | HTTP over TLS; SSE for streaming | Transport-agnostic reliable, ordered, bidirectional stream; WebSocket is the common/reference choice |
| Reconnection | UHP defines replayable task events and session/response continuation | AHP sequences actions and provides reconnection/replay around the host’s shared state |
| Harness / agent boundary | Server-to-harness execution is implementation-defined | Agent implementation is out of scope; an AHP host can use ACP or another backend interface |
| Versioning | Date-based immutable protocol versions | SemVer with initialization-time version negotiation plus per-channel stability levels |
| Current reviewed version | 2026-08-11 Draft | 0.9.0, published 28 Aug 2026; pre-1.0 |
Why AHP is a distinct interoperability layer
Section titled “Why AHP is a distinct interoperability layer”AHP is not merely another client-to-agent RPC vocabulary. Its distinctive concern is shared state coordination. Every push-style interaction is scoped to a URI-identified channel, and the host sequences mutations against an authoritative state tree. That gives multiple clients a common view of sessions, chats, terminals, changesets, automation runs and other host resources.
The official AHP/ACP guide makes the layering explicit: ACP is a point-to-point communication layer between one client and one agent, while AHP is a coordination layer for multiple clients over shared agent sessions. An AHP host can translate an upstream AHP action into an ACP request, map ACP streaming updates back into AHP actions, assign server sequence numbers and broadcast the resulting shared state to subscribers.
This creates a useful three-way distinction:
- UHP — product/client drives an interchangeable complete harness through a server.
- AHP — multiple clients coordinate around host-authoritative shared agent sessions.
- ACP — one client communicates directly with one agent process through a bidirectional agent interface.
Those boundaries can compose, but composition does not merge their semantics.
AHP 0.9.0 makes the overlap easier to see
Section titled “AHP 0.9.0 makes the overlap easier to see”AHP 0.9.0 added Automation Catalogue and Automation Run channels. An automation run has its own lifecycle (pending, running, terminal states), durable trigger/manual origin, linked session catalogue and optional primary session. The host records the run before external side effects and records linked session URIs before sending their first message; retrying the automation command with the same request id returns the existing run URI.
That is real task-lifecycle machinery, but it is not the same object model as UHP. In AHP, the automation run coordinates host-managed workflow/session state and linked ahp-session: / ahp-chat: channels remain authoritative for conversation and tool activity. In UHP, a Response itself is one harness task, and continuation creates a server-owned Session chain through previous_response_id.
AHP 0.9.0 also made turn errors durable response parts and added resumable errors through chat/turnResume. These are AHP chat/session semantics; they do not redefine UHP’s failed, incomplete, continuation or response lifecycle.
Where the protocols can coexist
Section titled “Where the protocols can coexist”A product architecture could use these layers independently or together. For example, an IDE-facing host might use AHP to synchronize several front ends around the same agent session while a separate backend service uses UHP to launch work on configured harnesses. A bridge could also be built between them, but such a bridge would need an explicit mapping for task identity, session ownership, cancellation, streaming, files/artifacts and authority; the protocols do not define that mapping for each other.
No primary source reviewed here establishes a standardized UHP ↔ AHP binding, HarnessRouter support for AHP, or native UHP adoption by Microsoft’s AHP/VS Code implementation. Likewise, AHP’s documented ability to use ACP below the host does not make ACP part of UHP.
What not to infer
Section titled “What not to infer”Related pages
Section titled “Related pages”See UHP architecture, harness composition, UHP vs ACP, UHP vs MCP and UHP vs A2A for the neighboring boundaries.