Comparison
UHP vs Agentic Hypercall Protocol (AHP)
UHP standardizes complete-harness execution. Agentic Hypercall Protocol is a new individual Internet-Draft for agents to discover, invoke, pay for and rate tools over HTTP.
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; Agentic Hypercall Protocol standardizes a proposed HTTP convention for an agent to discover, invoke, pay for and rate individual tools and services.
The boundaries can coexist without being substitutes. UHP owns task/session execution around a complete harness. Agentic Hypercall Protocol (AHP) focuses on a market-facing tool interaction: discovery, invocation, identity, payment, blind relay settlement, receipts and portable reputation.
Current status
Section titled “Current status”The current observed revision is draft-campbell-agentic-market-00, dated 6 September 2026. The IETF Datatracker classifies it as an active individual Internet-Draft and explicitly states that it is not endorsed by the IETF and has no formal standing in the IETF standards process. The document itself names intended status Experimental and expires 10 March 2027 unless updated or replaced.
The draft replaces draft-campbell-agentic-http-00 in its entirety. It retains the earlier pattern of tools as HTTP paths, parameters in query strings and cost declared through HTTP 402, then adds a stronger payment, privacy and reputation model.
Discovery and invocation stay close to ordinary HTTP
Section titled “Discovery and invocation stay close to ordinary HTTP”The proposal intentionally treats HTTP itself as the agent-facing substrate rather than defining a new transport stack.
An AHP service publishes a manifest at /.well-known/ahp.json. The manifest identifies the protocol version, provider principal and keys, OpenAPI description, supported payment rails and optional gateway/reputation endpoints. Its openapi member points to an OpenAPI 3.1 document describing tools, and operations can carry x-ahp pricing metadata.
The draft’s core invocation pattern is deliberately simple: a tool is an HTTP path and ordinary request semantics carry the call. This is materially different from UHP. A UHP request selects a configured complete harness and creates a server-owned execution object; an Agentic Hypercall request addresses an individual provider tool or service.
HTTP 402 becomes an in-band economic layer
Section titled “HTTP 402 becomes an in-band economic layer”The draft gives HTTP 402 Payment Required concrete agent-facing semantics. A provider requiring payment returns 402, machine-readable WWW-Authenticate challenges for accepted payment rails and a Problem Details offer. The consumer pays through a supported rail and retries the original request with proof of payment.
Revision -00 names three rails:
- Lightning L402;
- Cashu ecash;
- prepaid balance.
The economic exchange is therefore designed to be per request and in band, rather than requiring every provider to establish a separate account, SDK or billing contract with every agent operator.
UHP does not define a comparable payment or marketplace reputation layer. A UHP implementation can impose product-level quotas or budgets, but those controls are not an Agentic Hypercall payment protocol and do not turn a UHP Response into a paid hypercall.
Blind settlement separates relay functions from payload visibility
Section titled “Blind settlement separates relay functions from payload visibility”The draft also specifies an optional Gateway for blind settlement. In that topology, a consumer and provider establish an end-to-end encrypted interaction while the relay verifies identity, performs settlement and forwards sealed payloads it cannot read.
That is a distinct concern from UHP’s execution boundary. UHP defines the contract between a client and UHP server and leaves the server-to-harness execution mechanism implementation-defined. Agentic Hypercall’s Gateway is instead a proposed economic/privacy intermediary between tool consumers and providers.
Receipts and reputation are transaction-bound
Section titled “Receipts and reputation are transaction-bound”A provider can issue a signed receipt describing what was requested, what was returned and what was paid. The draft treats receipts as the accountability unit used by provenance, disputes and ratings.
A signed rating attestation references a settlement and identifies the provider and rater. The reputation design is intended to weight standing by settled economic activity rather than an unbound token/vote count, and to associate the result with the provider’s key so it can move across relays.
This evidence is still protocol-proposal semantics, not proof that a provider actually delivered correct or safe work. A valid receipt establishes a signed transaction statement under the draft’s rules; it does not establish UHP conformance, model quality, policy compliance or successful containment.
Architectural comparison
Section titled “Architectural comparison”| Dimension | UHP | Agentic Hypercall Protocol |
|---|---|---|
| Primary concern | Execute a configured complete harness through one server contract | Discover, invoke, pay for and rate individual tools/services over HTTP |
| Current status | UHP 2026-08-11 Draft | draft-campbell-agentic-market-00, active individual Internet-Draft; intended Experimental |
| Main boundary | Product/client ↔ UHP server ↔ complete harness | Agent/consumer ↔ tool provider, optionally through a blind settlement Gateway |
| Primary execution object | Server-owned Responses and Sessions | HTTP tool request/response plus optional payment, settlement and receipt artifacts |
| Discovery | GET /v1/uhp and configured harness discovery | /.well-known/ahp.json, OpenAPI 3.1 and tool/search endpoints |
| Transport | HTTP over TLS; SSE for UHP event streaming | Ordinary HTTPS; optional encrypted Gateway session for blind relay mode |
| Payment | No protocol-native payment rail | HTTP 402 with L402, Cashu or prepaid-balance rails in this draft |
| Reputation | Not a UHP protocol object | Signed settlement/rating evidence and portable reputation feed |
| Lifecycle | Normative task/session continuation, cancellation, files/artifacts and replayable events | Tool-market interaction; does not replace a complete harness task/session lifecycle |
| Conformance relationship | Dedicated 64-check UHP suite | Separate proposal; AHP behavior does not count as UHP conformance |
Where the two could coexist
Section titled “Where the two could coexist”A deployment could compose these boundaries without redefining either protocol:
- A product creates a UHP Response against a configured harness.
- The UHP server owns the Response, Session, workspace, files and event lifecycle.
- During its work, the harness needs a downstream external capability.
- An adapter or local facade discovers an Agentic Hypercall provider, evaluates the price and performs the paid tool request.
- The resulting data becomes ordinary harness input/output while AHP receipts and settlement records remain evidence at the downstream market boundary.
That composition is only an architectural possibility. No standardized UHP ↔ Agentic Hypercall binding and no native HarnessRouter Agentic Hypercall integration are established by the primary sources reviewed here.
The draft itself describes a local-facade pattern for agents that speak another API: a loopback/sidecar proxy can perform discovery, key pinning, payment and encrypted sessions while keeping wallet and budget configuration outside the agent-facing interface. That pattern could sit near a harness, but it is not the same as the UHP server contract.
What not to infer
Section titled “What not to infer”Related pages
Section titled “Related pages”Read UHP vs Agent Host Protocol for Microsoft’s unrelated AHP acronym, UHP vs MCP for tool/context interoperability, UHP vs Agent Authorization Envelope for portable action authorization, tool-call execution finality for final-dispatch binding, and the ecosystem map for other adjacent standards.