Comparison
UHP vs GetAIP Agent Interoperability Protocol
UHP standardizes execution of a selected complete agent harness. GetAIP's Agent Interoperability Protocol (AIP 1.0) standardizes governed, durable actions across agents, tools and services, with MCP and A2A compatibility profiles at its edges.
The one-sentence difference
Section titled “The one-sentence difference”UHP is a client↔server contract for running a selected, configured complete agent harness; GetAIP AIP 1.0 is a broader coordination contract for durable governed actions across independently operated agents, applications, tools and services.
The systems overlap around long-running execution, identity, streaming and recovery, but their primary abstraction is different. UHP centers the harness execution and its Response/Session/workspace lifecycle. GetAIP centers an Action and the capability, authority, approval, transaction, replay and evidence state surrounding that action as it crosses system boundaries.
Current GetAIP coordinates
Section titled “Current GetAIP coordinates”| Coordinate | Verified state |
|---|---|
| Protocol | AIP 1.0 |
| Latest public GetAIP GitHub release | v2.1.0, published 8 Aug 2026 |
v2.1.0 release commit | e6222fc36ebd7d8a723d773606c073d5da9cd281 |
Checked repository main | 56ad07454360af5f0440629ad4a6f43a3842eee6 |
| License shown by the current repository | BUSL 1.1 |
The version surfaces must not be collapsed. AIP 1.0 is the protocol version; GetAIP 2.1.0 is an implementation/product release. The project documentation also contains revision-bound implementation and qualification pages that may describe an older software/source coordinate than the latest GitHub release. Use the protocol specification for normative AIP semantics and the exact release/source revision for implementation claims.
What GetAIP AIP 1.0 standardizes
Section titled “What GetAIP AIP 1.0 standardizes”The project describes a shared semantic core around signed envelopes, capability discovery, principals and tenant context, durable actions, approvals, transactions, delegation, streaming, cancellation, receipts and audit evidence. A stable action_id remains the identity of the work across disconnects or client restarts so callers can query status rather than guessing whether to create new work.
GetAIP also separates native AIP bindings from compatibility profiles. The reviewed profile reference lists:
aip.native.http.v1andaip.native.nats.v1for native request/broker bindings;aip.sse.stream.v1andaip.websocket.stream.v1for native streaming codecs;aip.mcp.compat.v1for projecting MCP requests onto AIP capabilities/actions;aip.a2a.compat.v1for projecting A2A discovery/tasks onto the AIP lifecycle; andaip.http.webhook.v1for verified webhook ingress.
A compatibility adapter does not turn its foreign protocol into native AIP. The GetAIP documentation explicitly keeps MCP/A2A session, DTO, lifecycle and error details at the profile boundary while the native gateway/runtime owns AIP admission, authorization and durable lifecycle state.
Architectural comparison
Section titled “Architectural comparison”| Dimension | UHP 2026-09-12 | GetAIP AIP 1.0 |
|---|---|---|
| Primary object | Configured harness execution expressed as Responses and Sessions | Durable governed Action against a declared capability |
| Primary boundary | Product/client ↔ UHP server ↔ complete harness | Participant/profile/transport ↔ gateway/runtime ↔ module or connector |
| Discovery | UHP server/harness capabilities via GET /v1/uhp | Manifests and typed capability contracts |
| State model | Response states, Session continuation, containers/files and event stream | Action lifecycle plus approvals, transactions, delegation, receipts and audit state |
| Transport | HTTP API with SSE event streaming | Native HTTP/NATS plus SSE/WebSocket streaming; compatibility profiles for MCP/A2A and webhook ingress |
| Identity/authority | Authenticated server boundary and principal-scoped UHP objects | Explicit principals, tenant context, delegated authority and trusted ingress boundaries |
| Retry/recovery | UHP task/session/idempotency and continuation rules | Distinguishes message replay, repeated intent, leases, provider uncertainty, reconciliation and compensation |
| Extension focus | Complete-harness execution and optional Harness Plugins | Cross-system action governance and compatibility projections |
The closest conceptual overlap is long-running state: both reject treating a transient connection as the identity of the work. The larger difference is ownership. UHP asks a server to drive a complete harness. GetAIP describes work that can cross a gateway, runtime and product connector while retaining one governed action identity.
MCP and A2A are compatibility edges, not replacements
Section titled “MCP and A2A are compatibility edges, not replacements”GetAIP’s current documentation says MCP and A2A are supported compatibility edges into the same native action lifecycle. For MCP, the adapter maps supported JSON-RPC/tool/resource/task operations to bounded native capabilities and actions. For A2A, Agent Cards, sends, tasks, cancellation, streaming and push configuration are projected onto native manifests/actions/results/events and profile state.
That is materially different from saying AIP replaces MCP or A2A. The project explicitly says compatibility profiles cannot weaken native admission rules, and its qualification guidance warns that source mappings/tests do not prove an arbitrary deployment has enabled or qualified the same providers, identity configuration, stores or external systems.
Where UHP and GetAIP can coexist
Section titled “Where UHP and GetAIP can coexist”A system could compose both layers. For example, a GetAIP capability could invoke a service that internally uses UHP to run a configured harness, or a UHP-served harness could call a GetAIP-backed service through a tool/integration boundary. In either case the two lifecycle objects remain distinct: the GetAIP action_id is not automatically a UHP Response or Session id.
No standardized UHP↔GetAIP binding, native GetAIP UHP implementation, or HarnessRouter GetAIP integration is established by the primary sources reviewed for this page. Treat any composition as deployment architecture unless a future source defines and tests a formal binding.
Maturity and evidence boundary
Section titled “Maturity and evidence boundary”The GetAIP documentation usefully separates normative, implemented, conformant, qualified and live verified claims. Its implementation-status material also records gaps: for example, A2A compatibility code/tests exist at the reviewed source revision, but that evidence is not presented as a dedicated independent A2A conformance suite; MCP conformance commands have narrower scopes than the full implementation surface.
That discipline matters when comparing GetAIP with UHP. A project exposing an MCP or A2A compatibility route does not automatically establish cross-product interoperability, and implementation tests should not be reported as protocol-wide production qualification.
What not to infer
Section titled “What not to infer”Related pages
Section titled “Related pages”Read UHP vs MCP for the tool/context boundary, UHP vs A2A for agent-to-agent communication, UHP vs Agent Identity Protocol for the unrelated identity proposals sharing the AIP acronym, and the ecosystem map for adjacent standards and implementations.