A2A CLI and UHP

Keep the three plugin contracts separate

A2A CLI v0.3.0 contains several extension seams. The tagged README and release notes establish different ownership for each:

Extension	What it adds	What it does not establish
Agent Plugins package	A skills-only installable unit for a plugin-aware coding host	A new A2A wire protocol or UHP backend
Transport plugin	a2a-transport-<name> child process on PATH with a framed JSON interface	Permission to access arbitrary remote agents
Command plugin	Additional CLI commands; disabled by default in this release	Automatic trust of discovered executable code

Begin with plain discovery/send before enabling an extension:

a2a card get https://agent.example.com
a2a send -a https://agent.example.com --stream "Summarize this document"

Replace the reserved example URL with your chosen agent endpoint and supply its documented authentication. These are source-checked commands, not a live request. A discoverable card describes a service; a successful transport connection does not prove the task completed or returned the desired artifact.

For a wrapper, preserve task/context IDs together with the endpoint/agent identity and inspect the terminal task outcome. Keep process exit success separate from a remote task that is still working, requests input or ends unsuccessfully. If a streaming connection drops, consult the task read/poll lifecycle before resubmitting.

The bundled v0.3.0 CLI behavior specification remains version 0.2, Status Review, tied to A2A v1.0; software release maturity and that document’s maturity are different. Use A2A comparison for the agent-exchange boundary and execution finality for wrapper result handling. A coding harness running this CLI is an A2A client through a tool, not a native UHP implementation.

Release check — 4 October 2026

The latest stable release observed in the upstream GitHub release API is v0.3.0, published 2026-09-24. The release adds file-part saving, an a2a skill command, config-driven global flags and a command-plugin framework. Command plugins are disabled by default. A command plugin is not the same contract as the Agent Plugins package discussed below.

Evidence scope: the integration details, commands, measurements and development-head references below preserve the 16 Sep 2026 source snapshot. They are not presented as a fresh test of this newer release. For the current UHP protocol, HarnessRouter release and suite coordinates, use the release tracker and conformance guide. Adapter support does not establish upstream-native UHP adoption.

Source snapshot — 16 Sep 2026

The A2A Project 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 bc7c6d25b1cffc6a89fc91ff83cba8e28cacade8 at this cutoff. The post-release line adds cookbook/example documentation, a packaged Agent Plugin for the CLI skill, WinGet automation and refreshed harness-facing README/demo wording. Those changes are post-tag: the latest stable binary release remains v0.2.0, and agent-plugin/plugin.json is not present in the v0.2.0 tag.

On 16 September 2026, A2A merged roadmap PR #2237. The current roadmap now lists “A2A CLI and Coding Harness Integration” as a near-term initiative alongside v1.1 protocol work, bidirectional streaming and elicitation/multi-turn workflows. That is meaningful direction-setting evidence from the A2A project, but it is a roadmap statement rather than shipped wire semantics.

Caution

Release maturity, specification maturity and roadmap maturity are different coordinates. GitHub marks v0.2.0 as a normal software release, but the bundled CLI behavior specification is still version 0.2, Status: Review — a pre-Proposed state. It applies to A2A Protocol v1.0 and explicitly says it constrains CLI behavior only; it does not modify A2A wire semantics. The A2A Protocol itself remains on the v1.0 line, with tagged specification release v1.0.1 tracked separately. Roadmap items do not become protocol requirements merely by appearing in the roadmap.

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 current README names the harness use case directly:

• AI coding assistants can delegate work to A2A agents through one command surface and an Agent Skill;
• 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-09-12 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.

Post-release Agent Plugin: a new package-format composition seam

A2A CLI main added a second distribution form after the v0.2.0 tag. Commit 5f99de41610327cd3d3f0588340dfe8a9c78fc46 adds agent-plugin/, whose manifest targets the Agent Plugins 1.0.0 schema and carries the a2a-cli skill as a skills-only plugin. The package contains no mcp.json, and its README explicitly says the a2a binary is not bundled; the binary must still be installed separately.

That matters to UHP because UHP 2026-09-12 added optional Harness Plugins using the Agent Plugins package format. The overlap is therefore real but narrow: A2A CLI now publishes a post-release package in the same package family that UHP Harness Plugins knows how to represent and bind. It does not mean the A2A CLI implements UHP, that A2A gained a UHP transport, or that any particular UHP server has been measured installing this package.

Agent Plugins 1.0.0 package
        │
        ├── skills/a2a-cli/SKILL.md
        │
        └── no MCP server

UHP Harness Plugins (optional)
        │
        └── can carry/bind Agent Plugins-format packages

The useful architectural conclusion is package-format composability, not protocol convergence. The A2A interaction still occurs through the a2a CLI and A2A wire protocol; UHP, where present, still governs the outer harness execution boundary.

A2A roadmap now names coding-harness integration

The A2A protocol roadmap merged on 16 September 2026 makes this direction explicit. Its near-term initiatives include A2A CLI and Coding Harness Integration and link issue #1929, describing the CLI as the bridge for adoption in coding-harness tools. The same roadmap separately lists v1.1 protocol enhancements, bidirectional streaming and elicitation/multi-turn workflows.

This distinction is important for implementation planning:

• the CLI and Agent Plugin exist today on the tooling/repository line;
• coding-harness integration is an explicit near-term A2A project initiative;
• future v1.1/BiDi/elicitation work is roadmap scope, not current v1.0 wire behavior;
• no roadmap item establishes a UHP↔A2A binding or native UHP adoption.

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:

1. Did the CLI successfully perform the requested protocol interaction?
2. 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 is 2026.9.28.post3 with 85 checks, and nothing in a2a-cli v0.2.0, its post-release Agent Plugin or the A2A roadmap 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	Agent Skill in v0.2.0; post-release main also packages it as an Agent Plugins 1.0.0 skills-only plugin.	UHP 2026-09-12 optionally carries Agent Plugins-format Harness Plugins, but no A2A-specific binding is standardized.
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 85-check UHP conformance source (2026.9.28.post3).
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: bc7c6d25b1cffc6a89fc91ff83cba8e28cacade8; stable remains v0.2.0.
• Post-release Agent Plugin: added in commit 5f99de41610327cd3d3f0588340dfe8a9c78fc46; agent-plugin/plugin.json targets Agent Plugins 1.0.0, reports plugin version 0.2.0, and the package is skills-only. It is absent from the v0.2.0 tag.
• A2A roadmap: current main commit afda8316c64951a2ecb2a0d3d10867405d2b4095 after PR #2237; near-term scope explicitly includes A2A CLI and Coding Harness Integration. This is roadmap evidence, not released protocol behavior.
• 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.
• Native UHP adoption or UHP binding: not established.
• UHP: current normative version 2026-09-28; current conformance package 2026.9.28.post3 contains 85 checks. Historical A2A integration evidence above retains its original cutoff.

Related pages

Read UHP vs A2A for the protocol-layer comparison, Harness Plugins for UHP’s optional Agent Plugins package surface, UHP vs Agent Plugins for the package-format boundary, Harness composition for internal delegation topology, UHP vs MCP for tool/context interoperability, and UHP vs ACP for editor/client-to-agent integration.

Primary sources

• Current UHP source at v0.29.0

• Current conformance source at v0.29.0

• Official A2A CLI repository

• A2A CLI v0.2.0 release

• A2A CLI v0.2.0 README

• A2A CLI v0.2.0 changelog

• A2A CLI v0.2 specification

• A2A CLI compliance model

• Current A2A CLI README

• Agent Plugin addition commit 5f99de41

• A2A CLI Agent Plugin manifest

• A2A CLI Agent Plugin README

• A2A roadmap

• A2A roadmap PR #2237

• UHP 2026-09-12 normative specification

• UHP current conformance suite