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

Interoperability tooling

A2A CLI and UHP

The official A2A CLI is a standardized command-line client for discovering, invoking and managing A2A agents. Stable software v0.2.0 now gives coding harnesses and automation a common A2A client surface, while its CLI specification remains Review/pre-Proposed and does not create a UHP↔A2A binding.

Verified: 9 Sep 2026Observed stable: v0.2.0Protocol baseline: A2A v1.0

Status first

The A2A Project now ships an official stable A2A CLI software release. a2aproject/a2a-cli published v0.2.0 on 9 September 2026 at 11:54:50 UTC, targeting commit cacb1e2c3155555bbdb50717c58052f9c19c7b2f. The repository describes a2a as the official standardized command-line client for discovering, interacting with and managing A2A agents.

Checked upstream main is c8622f9b58abe4a55db308bb5faad51619305cff at this cutoff. The only observed post-release commit updates the Homebrew formula for v0.2.0, so the release behavior described here remains bounded to the v0.2.0 tag.

Why the A2A CLI matters to harness interoperability

The official CLI creates a common harness-facing client surface for an interoperability layer that previously had multiple ad-hoc command-line implementations. Its README names three consumers directly:

AI coding agents can delegate work to A2A agents through one command surface and a bundled Agent Skill descriptor;
human developers can inspect Agent Cards, send work, stream updates and manage tasks from a terminal;
automation and CI can use protocol-native JSON output and predictable exit behavior without embedding a language SDK.

That is materially relevant to UHP architecture because a complete coding harness can use the CLI internally while UHP remains the outer execution boundary:

Product / IDE / service
        │
        │ UHP
        ▼
   Coding harness
        │
        │ a2a CLI
        ▼
   Remote A2A agent

The composition is architectural, not normative. Neither UHP 2026-08-11 nor A2A CLI v0.2.0 defines a standardized UHP↔A2A binding.

`v0.2.0` release boundary

The first observed stable standalone release is more than packaging. Its changelog records the following integration-relevant work:

the A2A Go CLI becomes the base of the official standalone CLI;
CLI behavior is reconciled against the reviewed v0.2 specification, including Tier 1 work;
custom transport plugins are supported;
Agent Cards can be supplied from a file path;
get --wait supports polling-simulated blocking;
configuration can load from .env files;
structured CLI errors are introduced;
using --insecure together with credentials produces a warning;
file parts render name, type and size information;
polling no longer ignores AUTH_REQUIRED state.

Those are CLI implementation/tooling behaviors. They are not a new A2A protocol version and they do not change UHP task, session, discovery or conformance semantics.

Command and transport surface

The v0.2.0 README presents a small common path:

a2a card get https://agent.example.com
a2a send -a https://agent.example.com "Hello, what can you do?"
a2a send -a https://agent.example.com --stream "Summarize this document"

The CLI negotiates among built-in JSON-RPC, HTTP+JSON/REST and gRPC bindings from the Agent Card. The reviewed CLI specification requires transport behavior to remain language-agnostic and defines the default as the first mutually supported interface in the Agent Card’s server-preference order, with an explicit override available to the caller.

Pluggable transports

v0.2.0 also exposes a durable extension seam: additional transport bindings can be installed as executables named a2a-transport-<name> on PATH. The CLI launches such a plugin as a local proxy and presents it through the same --transport selection surface.

This plugin contract is a CLI extensibility mechanism. It does not make an arbitrary transport part of the A2A wire specification, and it does not make UHP one of the A2A protocol’s native transports.

Agent Skill: a deliberate coding-harness surface

The release tree contains skills/a2a-cli/SKILL.md. The CLI specification treats AI coding agents as first-class consumers and defines a standardized Agent Skill descriptor so a harness can learn how to drive A2A through the CLI instead of requiring a harness-specific plugin for every remote A2A agent.

This is the most direct overlap with agent-harness engineering:

Layer	Responsibility
Coding harness	Owns its reasoning/model/tool loop and decides when remote delegation is appropriate.
A2A CLI skill	Teaches the harness the command surface it can invoke.
`a2a` process	Resolves the Agent Card, selects a transport, sends/streams work and renders protocol results.
Remote A2A agent	Owns the delegated task and A2A server-side lifecycle.
UHP, if present	Can remain the outer product↔harness execution/lifecycle boundary.

The Agent Skill therefore improves composability without collapsing the layers into one protocol.

Stateless continuation and identifier ownership

The reviewed v0.2 CLI specification is intentionally stateless between invocations. It says the CLI must not invent server-owned taskId or contextId values, must not silently store the last identifiers and replay them later, and must expose identifiers needed for continuation so callers can pass them explicitly.

That choice is relevant to harnesses and automation because concurrent commands do not depend on hidden local “current session” state. It also keeps ownership aligned with A2A: message identity is client-side, while task and context identifiers are server-side protocol objects.

This should not be projected onto UHP. UHP has its own task/session contract; similar words such as task, session, context or continuation do not imply identical lifecycle semantics.

Output, task outcome and process success

The CLI specification separates two questions:

Did the CLI successfully perform the requested protocol interaction?
What outcome did the remote agent/task reach?

Its exit-code model is intended to answer the first question, while the A2A task state/output answers the second. A correctly transported task that ends FAILED, REJECTED, INPUT_REQUIRED or AUTH_REQUIRED is not automatically equivalent to a CLI transport/process failure.

That separation is useful for CI and harness orchestration because a caller can distinguish a broken command path from a valid remote-agent verdict. It remains A2A CLI behavior, not a UHP response-status rule.

Capability tiers and compliance

The standalone specification organizes CLI scope into cumulative tiers:

Tier 1 — Core: card discovery, sending, task get/cancel, polling, output/exit behavior, basic auth, transport/version handling and the Agent Skill condition;
Tier 2 — Standard: adds task listing/subscription, OAuth login, multiple transports, configuration scoping, push-config operations, download/debug/conformance/completion surfaces;
Tier 3 — Advanced: adds webhook receiving, interactive chat, gRPC, extended-card verification, mTLS/OIDC, demo/mock server, registry/catalog and extension behavior.

The repository keeps a separate COMPLIANCE.md for how implementations demonstrate those CLI requirements. A2A CLI compliance is not UHP conformance. UHP’s current conformance package remains 2026.8.11.post1 with 64 checks, and nothing in a2a-cli v0.2.0 changes that evidence.

Protocol-direction map

Boundary	A2A CLI relationship	UHP relationship
Product/client ↔ coding harness	Not the CLI’s primary contract.	UHP’s target boundary.
Harness ↔ remote A2A agent	The CLI can provide a common executable A2A client surface.	Possible internal composition, not standardized by UHP.
Agent discovery	Resolves A2A Agent Cards.	Separate UHP discovery semantics for harness capabilities.
Remote task lifecycle	Drives A2A messages/tasks/artifacts over selected bindings.	Separate UHP task/session lifecycle.
Coding-agent integration	Bundled `skills/a2a-cli/SKILL.md`.	UHP does not require Agent Skills.
Transport extensibility	Built-in JSON-RPC/HTTP+JSON/gRPC plus executable transport plugins.	No verified UHP transport plugin or binding is established.
Conformance/compliance	A2A CLI’s own reviewed behavior specification and compliance model.	Separate 64-check UHP conformance suite.
Native UHP adoption	Not established.	No A2A CLI UHP implementation or UHP conformance evidence verified.

Evidence boundaries

A2A CLI software release: v0.2.0, published 9 Sep 2026 at 11:54:50 UTC; tag target cacb1e2c3155555bbdb50717c58052f9c19c7b2f.
Checked A2A CLI current main: c8622f9b58abe4a55db308bb5faad51619305cff; observed post-tag change updates the Homebrew formula.
CLI specification: version 0.2, Review / pre-Proposed, applies to A2A Protocol v1.0 and does not alter wire semantics.
A2A Protocol: separate protocol line; this CLI release is not A2A Protocol v0.2.0.
Agent Skill: present at skills/a2a-cli/SKILL.md in the release tree.
Native UHP adoption or UHP binding: not established.
UHP conformance: unchanged; no A2A CLI result is reclassified as UHP conformance evidence.

Read UHP vs A2A for the protocol-layer comparison, Harness composition for internal delegation topology, UHP vs MCP for tool/context interoperability, and UHP vs ACP for editor/client-to-agent integration.

Status first

Why the A2A CLI matters to harness interoperability

v0.2.0 release boundary

Command and transport surface

Pluggable transports

Agent Skill: a deliberate coding-harness surface

Stateless continuation and identifier ownership

Output, task outcome and process success

Capability tiers and compliance

Protocol-direction map

Evidence boundaries

Related pages

Primary sources

`v0.2.0` release boundary