A2A agent interoperability needs failure contracts

A2A has crossed from announcement to infrastructure work

The Agent2Agent protocol is no longer only a Google launch artifact. The Linux Foundation reported broad organizational support and multi-cloud implementations in April 2026. In August, A2A moved into the Agentic AI Foundation, the focused home that already includes MCP. At the same time, the official A2A team began formalizing a cross-transport CLI and machine-readable conformance model.

Those events are meaningful because interoperability standards become useful through boring surfaces: stable discovery, predictable exit codes, version negotiation, cancellation, polling, streaming, authentication, and tests that different implementations can run. The new official CLI aims to expose the same command behavior for JSON-RPC, REST, and gRPC agents. Its specification is still under active review, so teams should treat today's interface as a maturing contract rather than a frozen universal tool.

Governance and tooling do not prove universal adoption. The focused last30days corpus was small: three Reddit threads, three Hacker News stories, and the new CLI repository. A current developer thread showed genuine demand for connecting Claude Code, Codex, Hermes, LangGraph, CrewAI, and other harnesses, but the discussion quickly moved beyond connectivity. One practitioner summarized the real boundary: the hard part is getting agents to agree on what “done” or “broken” means.

That is the thesis of this guide. A2A can make the task envelope portable. Your system must make the consequences portable. Without an explicit success oracle, evidence format, authority boundary, budget, retry rule, and unresolved-state owner, a second conforming agent is only a second source of ambiguous side effects.

What A2A v1.0 actually standardizes

A2A models an independent remote agent as a server and the calling orchestrator as a client. The server publishes an Agent Card at a well-known location or through a registry. That card describes identity, supported interfaces, protocol versions, skills, input and output modes, and security schemes. The client then obtains credentials out of band and sends a message to begin or continue work.

A message is a conversational turn. A task is the stateful unit of work. Tasks can move through submitted, working, input-required, authorization-required, completed, failed, canceled, or rejected states. Results arrive as artifacts composed of text, files, or structured data. Long-running work can stream status and artifact updates, accept polling, or deliver push notifications. The protocol also defines version signaling so a client and upgraded server can avoid silently assuming incompatible semantics.

{
  "name": "invoice-verifier",
  "description": "Checks one invoice packet against policy",
  "supportedInterfaces": [{
    "url": "https://agents.example.com/a2a",
    "protocolBinding": "HTTP+JSON",
    "protocolVersion": "1.0"
  }],
  "capabilities": {"streaming": true, "pushNotifications": true},
  "securitySchemes": {
    "workloadOidc": {"type": "openIdConnect", "openIdConnectUrl": "https://id.example.com/.well-known/openid-configuration"}
  },
  "skills": [{
    "id": "verify-invoice-v3",
    "name": "Verify invoice evidence",
    "inputModes": ["application/json"],
    "outputModes": ["application/json"]
  }]
}

This is a real improvement over bespoke endpoints. The caller can discover what an agent claims to support, initiate a task, observe progress, cancel it, and receive structured output without importing that agent's private framework. Opaque execution is deliberate: the remote system does not need to reveal chain-of-thought, internal prompts, model vendor, or tool implementation.

Opacity also creates the central risk. A completed task says the remote agent reached its own terminal state. It does not prove that your business acceptance criteria were met, that hidden tool calls stayed within authority, that every claimed source existed, or that the artifact can be reproduced. Treat completed as a transport fact, not a release decision.

A2A and MCP solve different seams

A common architecture is an orchestrator using A2A to delegate a bounded task to a specialist agent, while that specialist uses MCP or native APIs to access its tools. This separation is useful because the orchestrator does not need the specialist's internal tool inventory. It is dangerous if authority is inherited implicitly: the orchestrator's credential, the remote agent's credential, and each tool's credential may authorize different consequences.

The A2A specification supports an authorization-required state and recommends secure out-of-band credential delivery. It warns that in-band credentials can propagate through chains of agents. Yet the protocol cannot decide whether a particular payment, file deletion, candidate rejection, production deployment, or employee-data read is authorized. That decision belongs in policy outside the model, bound to exact parameters and the current task state.

Semantic interoperability is the other gap. “Verify this patch” might mean unit tests to one agent, full integration tests plus security review to another, and an LLM critique to a third. If the caller accepts the first completed response, the same A2A message can produce materially different assurance. Portable verbs require portable acceptance criteria.

Put a failure contract beside every delegated skill

A failure contract is a versioned manifest that tells the orchestrator how to decide what happens after every terminal and ambiguous state. It is not a prompt. It is executable policy and test data. Keep it outside the remote agent so the caller can evaluate a replacement implementation against the same consequences.

contract: verify-invoice-v3
input_schema: schemas/invoice-packet-v3.json
input_digest: required
authority:
  allowed: [read_packet, read_policy, write_review_artifact]
  denied: [approve_payment, modify_ledger, contact_vendor]
success_oracle:
  required_artifacts: [source_register, recomputation, exception_table]
  deterministic_checks: [schema_valid, totals_tie, citations_resolve]
budgets:
  wall_seconds: 180
  remote_attempts: 2
  max_cost_usd: 0.80
side_effects:
  idempotency_key: task_id_plus_input_digest
  compensation: delete_unreleased_artifact
disagreement:
  verifier_rejects_before_stop: 2
  on_exhaustion: human_review
recovery:
  ambiguous_delivery: reconcile_before_retry
  stale_agent_card: rediscover_and_reauthorize
owner: finance-automation

The contract should name what the agent must never do as clearly as what it may do. “Read only” is insufficient if the remote system can send email, create tickets, write memory, or call a sub-agent. Enumerate effects at the business boundary. Bind authorization to the input digest, requested skill, tenant, expiry, and maximum consequence so a valid credential cannot be replayed on a different task.

Budgets are part of correctness. An agent that eventually produces a correct artifact after twelve retries, a forty-minute loop, and a hundred dollars of inference is not interchangeable with one that meets the accepted service level. Make time, attempts, model cost, tool calls, and human interruptions observable. When a budget is exhausted, move to a named state instead of letting the model decide whether to continue.

Cancellation is also a contract. A2A can send a cancellation request, but the server may already have committed an external side effect. Define whether cancellation means “stop future compute,” “guarantee no effect,” or “begin compensation.” Require a receipt that distinguishes canceled-before-effect from canceled-after-effect. Otherwise the user interface can say canceled while a deployment, message, purchase, or record change still completes.

Make completion claims carry evidence

The remote agent should return a compact evidence envelope as an artifact. The envelope separates claims from proofs and lets an independent verifier inspect raw outputs without trusting the agent's summary. This directly addresses the current community concern about coder-verifier loops: structured feedback is useful, but a coder can overfit to the verifier's prose. Preserve raw test output, hashes, and tool receipts alongside the interpretation.

{
  "contract": "verify-invoice-v3",
  "task_id": "task-9812",
  "input_digest": "sha256:6a8...",
  "agent_card_digest": "sha256:1bf...",
  "claims": [
    {"id": "totals-tie", "result": "pass"},
    {"id": "policy-supported", "result": "fail"}
  ],
  "evidence": [
    {"claim": "totals-tie", "kind": "recalculation", "digest": "sha256:09c..."},
    {"claim": "policy-supported", "kind": "citation-check", "status": 404}
  ],
  "effects": [{"type": "artifact-write", "idempotency_key": "task-9812:6a8"}],
  "usage": {"attempts": 1, "wall_ms": 48210, "cost_usd": 0.31},
  "terminal_state": "completed_with_exceptions"
}

Notice that completed_with_exceptions is an application state, not an A2A core task state. The A2A task may be completed because the remote agent delivered the requested artifact. The orchestrator still rejects release because a citation failed. This two-level state model prevents transport success from becoming business success.

The verifier should be independent enough to catch correlated errors. Prefer deterministic schema validation, recalculation, access checks, policy engines, sandboxed tests, and human review for judgment-heavy consequences. A second model using the same prompt, context, and provider can agree for the same wrong reason. When a model verifier is necessary, give it different evidence, prohibit hidden repair, and record its uncertainty.

decision = validate_schema(envelope)
if not decision.ok: reject("invalid evidence envelope")
if envelope.input_digest != expected_digest: reject("wrong task input")
if envelope.usage.cost_usd > contract.max_cost: stop("budget exceeded")
for check in contract.deterministic_checks:
    if not run(check, envelope.evidence): reject(check)
if verifier_reject_count >= 2:
    escalate(raw_evidence=envelope.evidence)
else:
    accept_for_human_gate()

Terminate A2A at a policy gateway

Do not let every internal agent fetch arbitrary public Agent Cards and obtain credentials independently. Place a gateway between orchestrators and remote agents. The gateway resolves an approved registry, pins card and protocol versions, validates signatures when present, maps skills to local contracts, acquires workload identity, enforces budgets, normalizes telemetry, stores evidence, and controls retries.

The gateway should cache public Agent Cards briefly but invalidate them on version or security changes. Extended cards may expose privileged skills and therefore require authentication and tighter access. Treat new or changed skills as a supply-chain event: diff the card, run conformance and consequence tests, and require approval before exposing the capability to production callers.

1. Resolve the agent from a curated registry or explicit configuration, not an untrusted task message.
2. Fetch the Agent Card over TLS, validate its domain and signature where available, and record a digest.
3. Negotiate an explicit protocol version and transport; never silently downgrade security or semantics.
4. Map the requested skill ID to a local failure contract and deny unknown skills.
5. Acquire a task-bound credential out of band with the smallest scope and lifetime.
6. Send the input digest, idempotency key, budget, accepted output schema, and correlation ID.
7. Persist task and artifact events idempotently; expect duplicate push deliveries.
8. Run independent verification before releasing any consequence to downstream systems.
9. Reconcile ambiguous timeouts before retrying, and hard-stop when disagreement or budget limits are reached.

This design also improves replacement testing. A candidate agent receives the same contract and fixture set behind the gateway. The platform compares accepted outcomes, evidence completeness, failure behavior, cost, latency, and recovery rather than comparing model-generated prose.

Test protocol conformance and consequence conformance separately

The official CLI effort is important because it can make the protocol surface testable across languages and transports. Use it to verify discovery, basic messaging, task inspection, cancellation, polling, JSON output, exit codes, streaming, push configuration, and authentication. Add the official inspector or technology compatibility tooling as it matures.

Then run consequence fixtures the protocol cannot define. Give two conforming agents the same malformed input, expired credential, duplicate request, conflicting source, tool timeout, cancellation race, and verifier rejection. Compare the final external state, not only the A2A transcript.

A passing wire test proves the adapter speaks A2A. A passing consequence test proves the workflow behaves within your risk boundary. Keep both results in the release record and rerun them after SDK, Agent Card, protocol, gateway, policy, model, tool, or verifier changes.

Common failure modes in interoperable agent systems

The hardest defects are plausible. The result may be well-written, the A2A objects valid, every TLS connection authenticated, and the final decision still wrong. Observability must connect protocol events to business consequences: which contract version ran, which evidence passed, which credential authorized the effect, and who accepted the residual risk.

A 30-day rollout should certify one bounded task family

1. Days 1-4: choose a reversible, low-consequence delegation with clear inputs, an independent oracle, and a named owner. Record the current non-A2A baseline.
2. Days 5-8: write the failure contract, input and output schemas, authority map, budgets, evidence envelope, stop states, and compensation behavior.
3. Days 9-12: place the remote agent behind a gateway, pin its card and protocol version, and obtain task-bound workload credentials.
4. Days 13-16: run protocol tests across discovery, send, get, cancel, streaming or polling, push duplicates, authentication failure, and version mismatch.
5. Days 17-20: run consequence fixtures for duplicate effects, stale data, verifier disagreement, timeout ambiguity, hidden cost, and cancellation after effect.
6. Days 21-24: shadow production requests. Compare accepted outcomes, evidence completeness, time, cost, retries, and human review with the baseline.
7. Days 25-27: permit a small live cohort with reversible effects, independent verification, daily exception review, and an immediate kill switch.
8. Days 28-30: the workflow owner decides approve, approve with limits, remediate, hold, or stop. Record exact versions and reapproval triggers.

Do not start with a swarm. Start with one caller, one remote agent, one task family, one verifier, and one unambiguous owner. Interoperability should reduce custom integration while preserving responsibility. If responsibility becomes harder to locate, the architecture is not ready to scale.

Frequently asked questions

What does the A2A protocol standardize?

It standardizes agent discovery through Agent Cards, messages, stateful tasks, artifacts, streaming and push updates, supported transports, versioning, and authentication requirements between independent agent systems.

Does A2A replace MCP?

No. MCP generally connects an AI application to tools and data. A2A coordinates tasks between independent agents. An A2A remote agent may use MCP internally, and an orchestrator may use both protocols.

Is the new A2A CLI production-ready?

The official repository says its v0.2 specification is in active review during August 2026. It is useful as a clear direction for standardized operations and conformance, but adopters should pin versions and avoid assuming the interface is final.

Why is protocol conformance not enough?

A conforming system can still deliver semantically wrong work, exceed budgets, repeat side effects, mishandle credentials, or disagree forever with a verifier. Production acceptance needs consequence-based tests and a local failure contract.

Where should authorization be enforced?

Use a policy boundary outside the model, usually at an A2A gateway and again at consequential tools. Bind credentials and approvals to the exact agent, tenant, task, parameters, input digest, expiry, and maximum effect.