UHP vs AC2 (Agentic Communication and Control Protocol)

The one-sentence difference

UHP is a live execution contract between a product/client and a server that runs complete agent harnesses; AC2 is a peer-to-peer authenticated communication and control protocol between a human controller and an AI agent, with explicit user approval for digital-signing operations.

The two therefore address different boundaries: UHP normalizes harness execution; AC2 keeps signing authority and private keys with the human controller while the agent requests approved actions.

Status first

• UHP is 2026-08-11, a Draft standard with a runnable 52-check conformance suite (2026.8.11.post1).
• AC2 is an Algorand Foundation Draft specification created 1 Apr 2026 and publicly launched on 25 Aug 2026 for community review. Its specification says changes are expected as it matures.
• AC2’s specification currently lists Conformance: TBD. It should not be described as having a completed conformance model or interoperable certification regime.
• The repository published ac2-open-claw-reference@1.0.0 on 25 Aug 2026. That is the version of the OpenClaw reference package, not an AC2 protocol v1.0 specification release.

Architectural comparison

Dimension	UHP	AC2
Primary boundary	Product/client ↔ UHP server ↔ complete harness runtime	Controller/user ↔ AI agent
Main purpose	Execute and control work consistently across harness runtimes	Authenticated controller-agent communication and human-controlled signing delegation
Core transport	HTTP; SSE for streaming	Liquid Auth connection establishment using FIDO2/WebAuthn and WebRTC DataChannels
Identity/authentication	UHP server authentication plus per-principal object scoping	DIDs and passkey-based credentials through Liquid Auth
Message model	UHP responses, sessions, events, files and artifacts	DIDComm v2-compatible message shapes extended for streaming and signing workflows
Human signing approval	No protocol-level controller-to-agent digital-signing approval channel	Signing requests are presented to the controller; the controller signs locally and returns a delegated signature
Private-key model	Outside UHP’s harness-execution contract	Designed so the agent does not receive the controller’s private key
Streaming	SSE events within UHP task execution	Real-time voice/text streaming over the authenticated P2P channel
Relationship to MCP/A2A	Can coexist with other protocols, but does not require them	AC2’s own spec states no direct relationship to MCP or A2A; it targets owner/controller-to-agent communication
Conformance	52-check Core/Extended/Full suite	TBD in the current Draft specification
Maturity snapshot	Draft protocol with reference implementation and conformance suite	Draft protocol with SDK/CLI/OpenClaw reference implementation; conformance not yet defined

What AC2 standardizes

AC2’s architecture has two principal participants:

• the Controller, normally a user’s wallet or identity-capable application; and
• the Agent, which can request communication or signing operations while remaining unable to access the controller’s private keys.

The required AC2 transport layer is Liquid Auth. The specification describes a signaling service for initial connection establishment, FIDO2/WebAuthn-based authentication, and direct WebRTC DataChannels for the end-to-end encrypted peer channel. The signaling service is not the message relay: after establishment, AC2 messages travel peer to peer.

For a signing flow, the agent sends a request containing the operation context, the controller reviews and approves it locally, and the resulting signature is returned to the agent for the approved operation. The specification uses payments, Git commit signing and document signatures as examples, while keeping the protocol use-case agnostic.

AC2, A2A and MCP are different boundaries

The AC2 specification explicitly describes no direct relationship with A2A or MCP. That is useful because all three can otherwise be grouped too loosely as “agent protocols”:

• AC2: human/controller ↔ agent authenticated communication and signing control;
• A2A: independent agentic system ↔ independent agentic system collaboration;
• MCP: AI application ↔ external tools, resources and prompts;
• UHP: product/client ↔ server ↔ complete harness runtime execution.

A system may use more than one of these boundaries without one protocol subsuming the others.

How UHP and AC2 could coexist

A UHP-driven harness could, in principle, use AC2 internally when an operation requires a human-controlled digital signature. For example:

Product / client
      │
      │ UHP — start and control harness work
      ▼
UHP server → selected harness / agent
                     │
                     │ AC2 — request user-controlled signature
                     ▼
                 Controller

The UHP client could continue to observe the outer task/session lifecycle while the running harness uses AC2 for the separate controller-approval boundary.

Caution

No standardized UHP↔AC2 binding is established by the current evidence. The current UHP specification does not define AC2 messages, Liquid Auth, DIDComm mappings or an AC2 signing field, and the AC2 specification does not name UHP. The composition above is an architectural possibility, not a native-adoption or interoperability claim.

Security and authority boundary

AC2 assumes a semi-trusted agent. Its stated model keeps controller private keys outside the agent, requires signing requests rather than direct key access, and places approval in the controller application. This is a different control plane from UHP’s server authentication and object-scoping rules.

Using both protocols would therefore require both trust models to remain intact: UHP authorization controls access to harness tasks, sessions, files and artifacts, while AC2 controls the separate controller-agent channel and signing authority. An AC2 approval should not be treated as automatically authorizing unrelated UHP objects, and UHP authentication should not be treated as a substitute for a user’s signing approval.

Maturity boundaries that matter

The 25 Aug public launch is a meaningful implementation milestone, but several claims would be premature:

• AC2 is not a finalized formal standard. Its own status is Draft.
• Conformance is not defined yet. The current specification says TBD.
• ac2-open-claw-reference@1.0.0 is not “AC2 protocol v1.0”. It is a reference-package release.
• The OpenClaw reference implementation does not prove cross-vendor interoperability. It proves that the protocol has a working implementation path.
• AC2 does not establish UHP adoption. Neither current specification names the other.

What AC2 does not replace

• It does not replace UHP’s harness discovery, task/session lifecycle, streaming-event contract, cancellation, files or artifacts.
• It does not replace A2A’s agent-to-agent collaboration model.
• It does not replace MCP’s tool/resource/prompt capability boundary.
• It does not make every controller-approved signature safe or correct; the controller still has to understand and approve the requested operation.
• It does not give a UHP server or harness a standardized AC2 capability automatically.

Related pages

Read UHP security, UHP vs A2A, UHP vs MCP, Harness composition, and the ecosystem map for neighboring execution, delegation and trust boundaries.

Primary sources

• AC2 Draft specification
• Algorand Foundation AC2 repository
• AC2 OpenClaw reference package 1.0.0 release
• Algorand Foundation: public AC2 launch announcement (25 Aug 2026)
• UHP 2026-08-11 architecture