Independent resource · Not affiliated with HarnessRouter · Site data checked 18 Sep 2026

Comparison

UHP vs A2A

UHP and A2A are complementary rather than direct competitors: one targets harness execution, the other communication between independent agentic systems.

Verified: 18 Sep 2026Protocol: 2026-09-12Static SSG

Short answer

UHP and A2A standardize different relationships. UHP defines how a product drives a complete agent harness as infrastructure. A2A defines how independent agentic systems discover capabilities, exchange messages, delegate work and track collaborative tasks across an interoperability boundary.

Product / IDE / service
        │
        │ UHP
        ▼
   Agent harness
   ├── MCP ──► tools / data
   └── A2A ──► remote agents

The diagram is conceptual. UHP does not require MCP or A2A, and A2A does not require UHP. The protocols can be composed because they operate at different boundaries.

UHP vs A2A

Question	UHP	A2A
Primary boundary	Product/client ↔ complete agent harness runtime	A2A client/agent ↔ independent remote agentic system
Main goal	Execute and control harness work consistently	Agent discovery, communication, delegation and collaboration
Typical unit of work	Harness task/response with sessions, progress and files	Messages and Tasks that can produce Artifacts
Discovery	Harness/capability discovery inside the UHP server contract	Agent Cards describe remote agent identity, interfaces, capabilities and skills
Long-running work	Task lifecycle, streaming, continuation and cancellation	Task states with polling, streaming and push-notification patterns
Current version checked	`2026-09-12` · Draft standard	Latest tagged release `v1.0.1`; current official docs remain on the `v1.0` protocol line
Governance context	Initiated and led by HarnessRouter	AAIF Growth Stage project under the Linux Foundation, with open multi-company governance

Governance update: A2A reaches AAIF Growth Stage

On 17 August 2026, the Agentic AI Foundation announced that A2A was joining AAIF as a hosted project. On 27 August 2026, the A2A Project’s own announcement stated that A2A had been officially accepted as a Growth Stage project at AAIF. AAIF is hosted by the Linux Foundation. This is a project-governance and maturity status; it is not a new A2A protocol version and does not by itself change A2A wire behavior.

AAIF’s 20 August ecosystem explanation positions A2A as the agent-to-agent collaboration layer alongside MCP for tools/context and other specialized protocols. The 27 August A2A announcement likewise describes A2A as the horizontal peer-to-peer collaboration layer and MCP as the vertical tool/data layer. That reinforces the layered comparison on this page: A2A’s neutral governance and Growth Stage status do not make it a UHP replacement, a UHP dependency, or evidence of UHP adoption.

Official roadmap: v1.1, bidirectional streaming and elicitation

The A2A Project updated its official protocol roadmap on 15 September 2026, and PR #2237 merged that roadmap into main on 16 September 2026 at afda8316. The near-term plan now explicitly names four workstreams:

v1.1 protocol enhancements and core robustness: refine task-timeline semantics, standardize event filtering for backward compatibility, and define how agent messages received while a task is in a working state should be handled.
Bidirectional (BiDi) streaming: pursue real-time artifact updates, role management and continuous multi-turn messaging while agents are actively executing tasks.
A2A CLI and coding-harness integration: continue the official CLI work specifically to reduce the adoption gap in coding-harness environments.
Elicitation and multi-turn workflows: explore structured human-in-the-loop interaction and multi-round negotiation patterns for longer collaborative exchanges.

The same roadmap keeps validation as a longer-term ecosystem priority through the A2A Inspector and A2A Protocol Technology Compatibility Kit (TCK), and records official SDK coverage across Python, Go, JavaScript, Java, .NET and Rust.

For UHP/A2A composition, the roadmap is useful because several planned A2A areas sit close to concerns UHP already exposes at the outer harness boundary—long-running task lifecycle, streaming and human interaction. That proximity should not be mistaken for semantic equivalence: any future A2A v1.1 behavior must be evaluated at the remote-agent boundary when it actually ships, rather than projected into UHP in advance.

Production lessons from an A2A deployment

An AAIF-hosted Eon engineering report published 26 August 2026 adds useful production evidence without changing A2A’s protocol status. Eon describes moving three specialist agents behind A2A in production and says it would choose A2A again, with Agent Cards proving especially useful for runtime capability routing.

The report also identifies several boundaries that adopters still have to handle above core A2A semantics:

End-user identity across a delegated hop is not a first-class A2A semantic field. A2A authenticates protocol participants and leaves identity/authorization to established protocol mechanisms, while Eon needed the remote agent to know which human user initiated the request. Because it controlled both ends, it carried user/session information through its own contextId convention. That is an implementation convention, not a portable A2A identity profile.
Provenance is extensible rather than standardized in the core message model. A2A provides generic metadata/extensions, but Eon wanted portable query semantics, lineage/freshness, confidence/caveats and governance. It therefore defined and negotiated a DataContext extension.
Remote context exhaustion needs an application-level reset convention today. When a remote agent’s context window filled, Eon advanced an epoch in its context identifier to establish a fresh context and calls out a standardized reset/new-context signal as a useful future primitive.
Streaming and error semantics matter operationally. Eon reports a 60-second gateway timeout with blocking message/send; switching to message/stream kept long work alive. It also found that remote error events without model-visible content could disappear from the receiving model’s context, so it synthesized text and argues for a portable retryability signal.

A2A multi-tenancy is routing, not end-user identity

Current A2A v1.0 documentation has an explicit multi-tenancy and multi-agent routing model that is easy to confuse with the end-user identity gap above. A single A2A endpoint can serve multiple agents or tenants through three complementary patterns: distinct URL paths, authentication-derived routing, or the optional tenant field carried in A2A requests.

The tenant field is an opaque routing identifier, not a standardized human-user identity. When a selected AgentInterface in the Agent Card declares a non-empty tenant, the normative client rule requires the client to echo that exact value in every request sent to that interface; when no tenant is declared, the field is omitted. Servers may interpret the opaque value as an agent identifier, workspace slug, organization ID or another routing discriminator. This routing contract therefore does not invalidate Eon’s separate observation that delegated end-user identity is not a first-class A2A semantic field.

The latest tagged A2A specification release observed is v1.0.1, published 28 May 2026. The project website still presents the active specification and examples as the v1.0 protocol line. The v1.0.1 patch includes HTTP-binding/error/status corrections; it does not create a new 1.1 protocol generation. The multi-tenancy guide and binding-agnostic tenant semantics were merged through PR #1848 / commit cd87b934 on 26 May 2026 and are present in the current official specification.

The official A2A Java SDK provides concrete implementation evidence for this boundary. Stable 1.3.0.Final added per-tenant routing via AgentExecutorRouter / AgentCardRouter and a tenant-bearing RequestContext, while also hardening server defaults: task authorization now fails closed when no TaskAuthorizationProvider is configured unless an operator explicitly disables that requirement; push-notification callback validation blocks SSRF-prone destinations and redirects; and HTTP auth handling restricts injected headers and disables automatic redirects to reduce credential leakage. Stable 1.3.1.Final, published 3 September 2026, then repaired multitenant module packaging, tenant extraction and public Agent Card behavior, including 404 for an unknown tenant. Stable 1.3.2.Final, published 8 September 2026, extends that redirect hardening to the shared POST-builder default: PostBuilder.followRedirects now defaults to false across JDK, Vert.x and Android clients specifically to prevent credential leakage on cross-origin redirects. Redirect following remains an explicit opt-in; the change adds shared redirect regression tests and manual Vert.x handling for enabled redirects.

For interoperability architecture, the important distinction is routing identity versus principal identity. A protocol can standardize which tenant/agent endpoint receives a request without thereby standardizing which human or workload principal ultimately authorized that delegated action. Systems that compose UHP and A2A should keep those trust domains explicit rather than overloading tenant, contextId, session identifiers or harness metadata as if they were interchangeable identity claims.

Official A2A Python SDK v1.1.4: callback and task-lifecycle hardening

The official A2A Python SDK v1.1.4, published 8 September 2026, adds a meaningful implementation-security and task-lifecycle hardening bundle without changing the A2A wire specification. The server now validates push-notification callback URLs both when configuration is created and again before dispatch; the release explicitly classifies the dispatch-time validation as SSRF hardening.

The same release tightens state and ownership behavior: cancellation and subscription operations are owner-scoped, cancellation writes a terminal task state, list-tasks responses omit artifacts, failed-task producer errors are surfaced, saturated subscriber taps evict rather than wedging dispatch, and the in-memory stores avoid losing the first owner write.

For a UHP-controlled harness that delegates to A2A agents, these fixes are operationally relevant because callback validation, terminal cancellation state and subscription ownership sit on the inner remote-agent boundary. They still do not establish a standardized UHP↔A2A binding or native UHP adoption by the Python SDK.

Hermes stable v0.21.3 includes the native A2A hardening chain

Nous Research published v2026.9.14 / Hermes Agent v0.21.3 on 14 September 2026. The A2A reliability and multiplex-profile identity hardening chain below first landed after v0.21.2; fresh ancestry verification shows its latest listed commit, 8c58e4f9, is an ancestor of the v2026.9.14 tag. The chain is therefore stable v0.21.3 behavior, not merely post-release main evidence. These are upstream Hermes implementation changes, not an A2A protocol-version change.

Task ownership now survives until final settlement (9c728ec3): Hermes tracks active request ownership separately from reply Futures. The orphan watchdog therefore excludes a task while a local request is finalizing or a synchronous cross-profile forward still owns it, instead of being able to race the legitimate completion path and mark live work failed.
SSE disconnects settle the task (36f43c27): if a message/stream client disconnects while a task is still pending, the adapter now records terminal failure with a client-disconnected result and clears pending/active ownership rather than leaving the task stranded as live work.
Orphan cleanup is bounded and reconnect-safe (138e426f): the orphan grace is clamped to a finite 300-second-to-24-hour range, and adapter disconnect clears the active-task ownership set so stale ids cannot survive reconnect and remain permanently excluded from orphan cleanup.
Multiplex Agent Cards keep the owning profile’s public URL (8c58e4f9): A2A_PUBLIC_URL is captured when the adapter is constructed inside the profile scope. Threaded HTTP request handlers no longer re-read a process-global/default profile environment value and accidentally advertise the default profile’s A2A URL for a secondary profile; profiles without an explicit public URL fall back to request host information.

For UHP/A2A composition, the useful lesson is that inner A2A task finality and discovery identity remain the responsibility of the harness implementing that inner boundary. A UHP server driving Hermes does not inherit these semantics from UHP, and these Hermes fixes do not create a standardized UHP↔A2A binding, native Hermes UHP adoption, or evidence that HarnessRouter has revalidated its released Hermes backend against this stable v0.21.3 A2A path.

When you might use both

Consider an application that lets a user choose a coding harness and then asks that running harness to delegate a specialized task to a remote research agent. UHP can normalize how the application starts and controls the harness. A2A can normalize how that harness or its surrounding agent system communicates with the remote agent.

Official A2A CLI: stable software, reviewed CLI specification

The A2A Project now maintains the official A2A CLI (a2a) as a standardized command-line client for discovering, invoking and managing A2A agents. The project published its first observed stable standalone software release, v0.2.0, on 9 September 2026 at 11:54:50 UTC.

The maturity boundary is important: the bundled CLI behavior specification remains version 0.2, Status: Review — pre-Proposed, applies to A2A Protocol v1.0, and explicitly constrains CLI behavior without modifying A2A wire semantics. A stable CLI binary release therefore does not promote the A2A protocol to v0.2.0 or make the CLI specification Final.

The release gives coding harnesses a concrete common client surface. It bundles skills/a2a-cli/SKILL.md, treats AI coding agents as first-class consumers, negotiates JSON-RPC, HTTP+JSON or gRPC from Agent Cards, supports executable custom transport plugins, structured errors and programmatic JSON output, and reconciles implementation behavior toward the reviewed capability tiers.

That makes the conceptual UHP/A2A stack more concrete without merging the protocols. A UHP-served coding harness may invoke a2a internally to reach a remote A2A agent; in that topology UHP governs the outer client-to-harness execution boundary, while A2A governs the inner remote-agent interaction. The A2A CLI does not create a standardized UHP↔A2A binding and its compliance model is not UHP conformance.

See the dedicated A2A CLI and UHP page for the release, transport-plugin, Agent Skill, stateless-identifier and compliance boundaries, and Harness composition and subagent delegation for the internal-topology view.

Gemini CLI ships a first-party experimental A2A server

Google’s stable Gemini CLI v0.58.0, published 1 September 2026, contains a first-party package named @google/gemini-cli-a2a-server. The tagged package is version 0.58.0, installs the gemini-cli-a2a-server binary, depends on the official @a2a-js/sdk, and describes itself as an experimental Agent-to-Agent server exposing Gemini CLI capabilities over HTTP.

The maturity boundary matters. The server’s tagged Agent Card advertises protocolVersion: "0.3.0", not current A2A v1.0; it exposes streaming and uses the A2A JavaScript SDK’s server request-handler/app surfaces. A2A v1.0 deliberately supports staged migration from v0.3, but this evidence does not establish that Gemini CLI’s server itself has been upgraded to, or independently validated for, A2A v1.0.

v0.58.0 also includes PR #28940, which fixes a real continuation defect in this A2A surface: after an abort or explicit cancellation, a cached task could retain a stale cancellationError, causing the next user prompt on that task to fail immediately with Execution aborted. The fix clears that stale state when a new user message is accepted and adds regression coverage. That is useful implementation evidence for an actively maintained A2A task lifecycle; it is not an A2A conformance result.

Concrete coexistence evidence: SuperQode

SuperQode now provides a concrete independent example of the two boundaries existing in the same product without becoming the same protocol. The official UHP implementations source lists SuperQode in both Client and Server roles for UHP 2026-09-12: superqode connect uhp drives a UHP server, while superqode serve uhp exposes one configured HarnessSpec behind the UHP server contract. The public 2026.9.12 conformance report against uhp.superqode.dev establishes Core 40/40 as the highest fully passed class; the requested-Full report is 42/74 passed, 9 failed, 23 skipped and 0 errored.

Separately, SuperQode’s current A2A documentation describes an A2A server exposed with superqode serve a2a. Its changelog records 0.2.110 on 24 Aug 2026 as the point where the A2A surface became customer-facing, adding JSON-RPC alongside HTTP+JSON, A2A 1.0 plus 0.3 compatibility, a published Agent Card, per-customer signed API keys, request limits and safer remote-bind defaults. 0.2.111 on 25 Aug adds an in-memory task-store option for ephemeral deployments plus A2A key/documentation fixes. SuperQode’s own docs still label its public hosted A2A pilot experimental; this guide does not upgrade that pilot to a production-SLA claim.

Why A2A is a useful comparison for UHP

Searches for “agent interoperability” often collapse several layers into one. MCP standardizes tool/context access, A2A standardizes agent-to-agent interoperability, and UHP targets harness execution. Comparing the boundaries is more useful than asking which single protocol “wins.”

Common mistakes

“UHP replaces A2A.” No; they solve different interoperability problems.
“A2A is a harness API.” Its core model is remote agent interoperability, not selecting and operating local or hosted harness runtimes as a shared execution layer.
“A2A tenant is the delegated user’s identity.” No. It is an opaque routing discriminator associated with the selected Agent Interface; deployments still need an appropriate principal/authentication/authorization model for the initiating user or workload.
“The official A2A CLI v0.2.0 is a new A2A wire version.” No. It is a CLI software release; its v0.2 CLI specification applies to A2A v1.0 and explicitly does not modify protocol wire semantics.
“A stable A2A CLI release means its CLI specification is Final.” No. The bundled specification remains Review/pre-Proposed at this cutoff.
“Gemini CLI’s A2A server is already a native A2A v1.0 server.” Not established. The tagged v0.58.0 Agent Card still advertises A2A 0.3.0.
“One stack must use all three protocols.” No. Use only the boundaries your system needs.
“A product supporting both protocols proves they are integrated standards.” No. SuperQode demonstrates product-level coexistence while keeping its UHP-client/UHP-server and A2A-server roles separate.

Primary sources

Related: the dedicated A2A CLI page covers the official client tool; independent UHP clients are catalogued on UHP clients; internal delegation topologies are covered on Harness composition; editor/UI-to-agent integration is compared in UHP vs ACP.