What Is A2A? Agent2Agent Spec, Security & Payments (2026)

A2A's official description of how it divides work with MCP is: "MCP is vertical, deepening a single agent; A2A is horizontal, connecting agents across boundaries." In A2A, the called party is an "opaque" agent: it reasons and keeps state on its own, the caller cannot see which models or tools it uses internally, and the two sides interact over multiple turns only through the lifecycle of a Task. Taiwanese official documents already cover A2A: the Ministry of Digital Affairs' Public Sector AI Application Reference Handbook V1.0 (document-stated date of provision 115-01-28, ROC calendar) has a subsection on page 14 titled "A2A: a communication protocol between AI agents", explaining that it focuses on "client–remote" communication.

A2A governance has gone through three stages. On 2025-06-23 the Linux Foundation announced it was taking over, with founding members AWS, Cisco, Google, Microsoft, Salesforce, SAP and ServiceNow; on 2025-08-29 IBM-led ACP merged into A2A and stopped development. Actual decision-making power rests with a 9-seat Technical Steering Committee (TSC), one seat per company: Google, Microsoft, Cisco, AWS, Salesforce, ServiceNow, SAP, IBM and Bloomberg. Proposals are voted on with gitvote in GitHub issues labeled TSC Review; for example, #1942 consolidated 41 issues into eight v1.1 themes and passed on 2026-06-25 with 5 votes for and 0 against (threshold 51%).

In August 2026, A2A joined the Agentic AI Foundation (AAIF) as a Growth Stage project, putting it under the same foundation as MCP. Sources disagree on the date: the AAIF blog and Axios say 2026-08-17, the official A2A blog and spec page say 2026-08-27, and Forbes' report is dated 08-19. One possibility is that 08-17 was the foundation's public announcement and 08-27 the project's own post, but no source confirms this explanation, so this article lists both dates rather than picking one for the reader. Diginomica counts A2A as AAIF's 5th hosted project, after MCP, goose, AGENTS.md and agentgateway; secondary sources also stress that this was only an organizational change and that the two specifications have not merged.

The A2A governance document states that the "steady-state composition will be decided 18 months after formation". Counting from June 2025, that falls around December 2026, and the AAIF announcement does not say whether the TSC will be reorganized. This is an inference: the TSC's composition may change in the near term and is worth tracking.

Every A2A v1.0 method was renamed: message/send became SendMessage, message/stream became SendStreamingMessage, tasks/resubscribe became SubscribeToTask, and ListTasks was added. REST paths now follow the AIP style, for example POST /tasks/{id}:cancel, and the /v1 prefix was dropped. The HTTP error format switched from RFC 9457 application/problem+json to google.rpc.Status, with reason written in upper snake case (e.g. TASK_NOT_FOUND) and domain fixed to "a2a-protocol.org". The research notes take this revision to mean A2A was remade in the style of Google's API design guide; this is an inference.

The biggest breaking change to the data model is the flattening of Part. The former TextPart, FilePart, DataPart and the kind discriminator field were all removed; a single Part now holds exactly one of text, raw (bytes), url or data, and the type is determined by which field is present rather than by reading kind. mimeType was renamed mediaType, and file.fileWithUri became url. Community reports note that many parsers still read part.kind, which is the most common cause of interoperability failures between 0.3 and 1.0. The Agent Card is now centered on supportedInterfaces[], where each interface carries its own url, protocolBinding, protocolVersion and optional tenant; clients pick in array order and SHOULD implement fallback.

Version negotiation has a default few people notice: if the A2A-Version header is empty, it is treated as 0.3. Clients send only Major.Minor, and a server that does not support it returns −32009 VersionNotSupportedError; one agent can list interfaces with different protocolVersion values in supportedInterfaces, letting 0.3 and 1.0 coexist. The official migration has three phases: first parse both formats, then emit 1.0 while reading 0.3, and finally keep only 1.0. Atlassian Forge and MuleSoft have both published 0.3→1.0 migration guides, showing that someone is really paying the cost of the breaking changes.

Task semantics include several details you only find by reading the whole spec. taskId is always generated by the server; if the client supplies a contextId, the agent may only accept or reject it, not generate a different one; if taskId and contextId do not match, the agent MUST reject. Sending a message to a task in any of the four terminal states (COMPLETED, FAILED, CANCELED, REJECTED) returns UnsupportedOperationError; to continue, open a new task in the same context and link it back to the original with referenceTaskIds. The state machine has two "interrupted" states, TASK_STATE_INPUT_REQUIRED and TASK_STATE_AUTH_REQUIRED, and a blocking SendMessage also returns when it hits an interrupted state.

The guarantees for streaming and push are weaker than most people assume. The final flag on TaskStatusUpdateEvent was removed in 1.0; "connection closed" now signals the end of the stream, so a connection dropped mid-task looks the same to the client as a completed task, and only another call to GetTask or SubscribeToTask can tell them apart. The spec also has no event-ID resumption mechanism, which is listed as v1.1 theme #1986. Push notifications deliver a StreamResponse to the client webhook via HTTP POST with Content-Type application/a2a+json; the spec only requires the agent to attempt delivery at least once, with a timeout that SHOULD be about 10–30 seconds, and the receiver SHOULD process idempotently and MUST verify the taskId. In other words, push is "at least once, no ordering guarantee, unsigned payload"; this is an inference from the spec. Idempotency is also only half done: SendMessage "MAY" deduplicate by messageId, but it is not required.

Sources conflict on two points of date and count. The v1.0 release date: the CHANGELOG says 2026-03-12, a survey paper (arXiv:2507.10644 v4) says January 2026, and the Linux Foundation's first-anniversary press release only calls v1.0 the first stable version without giving a date; this article follows the CHANGELOG as the primary source. The number of SDKs: the Linux Foundation said in 2026-04 there were 5 "production-ready" languages, while the official A2A announcement lists 6 (Python, Go, Java, JS, .NET and Rust), though the Rust SDK that has been tested in detail is a community version.

Over the past year you often heard "MCP added Tasks, so A2A is unnecessary", but the actual direction of the MCP 2026-07-28 revision is the opposite. The MCP 2025-11-25 revision did add experimental Tasks (SEP-1686) for tracking long-running requests, polling and retrieving results later, with states (working, input_required, completed, failed, cancelled) that map almost one-to-one to A2A. But the 2026-07-28 revision removed sessions and the initialize handshake, making MCP stateless (SEP-2567, SEP-2575); moved Tasks out of the core into the official extension io.modelcontextprotocol/tasks (SEP-2663); replaced server-initiated requests with MRTR (InputRequiredResult plus inputResponses attached on resend) (SEP-2322); and marked Sampling, Roots and Logging as deprecated (SEP-2577).

These changes mean the MCP maintainers deliberately gave up the "agentic" path in which the server borrows the caller's LLM for reasoning; this is an inference. An MCP server that wants to reason must bring its own model, at which point it is effectively an opaque agent that merely looks like a tool. MCP's Task handles "deferred retrieval of one long-running tool call"; A2A's Task handles "multi-turn collaboration in which either side may ask questions", plus Agent Card discovery, skill declarations and artifact streaming. There is a failure mode in the other direction too: forcing deterministic lookups such as price or tax-rate queries through the Task, Message and Artifact lifecycle adds latency and implementation cost, and the caller's LLM loses access to a fine-grained tool schema; this is also an inference. The research notes found no actual incident records of "using MCP for agent-to-agent and failing" or "wrapping tools in A2A and failing".

On adoption, besides GitHub topic counts, one non-systematic PyPI comparison shows about 10.9 million downloads for the A2A SDK versus about 257 million for the MCP SDK. Secondary sources indicate that Shopify's UCP endpoint uses MCP as its transport, meaning mainstream commerce agents connect via MCP. On the cloud platforms: AWS AgentCore Runtime can deploy A2A servers (JSON-RPC, POST /, port 9000, OAuth 2.0 or SigV4); A2A support in Microsoft Foundry entered public preview in June 2026; Google Agent Registry reads well-known cards, but automatic discovery is limited to the same project. Among the major model vendors covered in the research notes, Anthropic currently has no native A2A support, and the related Claude Code issue #104852 was only opened in late October 2026.

In practice the choice is simple: to let AI assistants call your deterministic functions (quotes, tax-rate lookups, shipment tracking), use MCP; only when two agents that each reason on their own and belong to different organizations need multi-turn collaboration do you need A2A. HowBridge's public MCP falls into the first category; see our consolidated-shipping MCP tutorial for how to connect it.

An A2A Agent Card uses securitySchemes to declare one of five authentication schemes: API Key, HTTP Auth, OAuth2, OIDC and mTLS. v1.0 removed the OAuth implicit and password flows, added Device Code, and recommends PKCE for all clients. The spec requires servers to "MUST authenticate every incoming request", but authorization is implementation-specific, and credentials must be obtained out-of-band; when a task enters the AUTH_REQUIRED state, the spec explicitly says "Agents MUST NOT treat the state transition alone as authorization". Section 13, "Security Considerations", does not mention prompt injection, delegation or token exchange, or OpenTelemetry at all, and has no dedicated tenant-isolation requirement. A Semgrep review from the v0.3 era noted that A2A "supports but does not enforce Agent Card signing", token lifetime and scope are not constrained by the protocol, and one task can have several parallel streams, so a stolen session token can silently listen in on the victim's stream.

Even a signed Agent Card is not currently guaranteed to verify across SDKs. The spec canonicalizes the card per RFC 8785 (JCS), excluding the signatures field, and then applies JWS; the protected header MUST contain alg and kid. Issue #2122 (opened 2026-08-10, still open as of 2026-10-31) records measured differences: a2a-python 1.1.2 and @a2a-js/sdk 1.0.1 canonicalize to different bytes. Python escapes non-ASCII characters as \uXXXX, sorts by code point rather than UTF-16 units, and outputs numbers as 1e-06, while ECMAScript outputs 0.000001; the spec requires REQUIRED fields to appear even at their default values, but proto3 has no concept of presence, so description: "" and skills: [] are dropped; typ is also ambiguous. PR #2319 fixed the spec examples, but a2a-go's output still differs. Another limitation is that a verified signature only proves the card was not tampered with, not who issued it, and the community has pointed out that the spec has no mechanism binding a card to the runtime environment that actually makes the call.

Some attacks work while remaining fully spec-compliant. A2ABreak (arXiv:2609.10871, v3 2026-10-24) used an LLM to extract 37 states, 76 transitions and 929 formal statements from the natural-language spec and found 11 new vulnerabilities, all of which "require no implementation flaw and can be exploited by a spec-compliant adversary", such as cross-client context injection due to unprotected context identifiers, identity loss after several hops in a delegation chain, and agents claiming unverified capabilities. A name-collision study (arXiv:2609.27624) points out that the spec positions name as "human-readable metadata, not as a stable identity" and defines no collision rules; in 6 of the 7 open-source implementations the author tracked, client-type integrations would send requests to an attacker-controlled endpoint, which the author characterizes as a recurring class of implementation vulnerability rather than a generic protocol vulnerability. Palo Alto Networks' Unit 42 built a session-smuggling proof of concept with Google ADK, showing a malicious agent using "clarifying questions" to extract system instructions and tricking the client into calling buy_stock to buy 10 shares without authorization; Unit 42 states clearly that this is not a protocol vulnerability, that any stateful multi-turn protocol could be affected, and that it has seen no exploitation in the wild. The community has also reported that a malicious server can hide instructions in an Agent Card's description or skills fields, which the host LLM then executes as instructions.

Academic evidence on cross-agent attacks also supports the view that "trust between agents cannot be assumed". Triedman et al. (COLM 2025) found that malicious web content can hijack the control flow of multi-agent systems; with GPT-4o, arbitrary code execution succeeded in 58%–90% of trials. Ferrag et al.'s peer-reviewed survey in ICT Express (2026) traces attacks from prompt injection all the way to the protocol layer, covering MCP and A2A.

The CVE numbers in the table below are copied exactly from the research notes. The notes themselves flag that these numbers are unusual and that some entries appear in only one database (for example, CVE-2026-90790 has no corresponding GHSA in the a2a-python repo and appears only in OpenCVE). Queries of the repo advisories for a2a-js, a2a-go and a2a-dotnet came back empty, but that may be due to insufficient permissions and does not necessarily mean there are no vulnerabilities. Three lessons can be drawn from the table; the following is inference. First, the Agent Card is attacker-controlled input, down to the header names the other side may dictate. Second, the spec only says "SHOULD validate webhook URLs", and SDKs in two languages ended up with SSRF as a result. Third, the spec says "authorization is up to the implementation", and the most popular SDK, the Java one, did no authorization by default, with the fix later bypassed through an Android platform difference.

Outside A2A, the agent identity problem is splitting into three layers. The first is workload identity, answering "which program is this": the authors of draft-klrc-aiagent-auth come from Amazon, Zscaler, Ping Identity, OpenAI and others; the draft has been adopted by the IETF WIMSE working group and superseded by draft-ietf-wimse-aims, and its approach is to reuse the existing WIMSE and OAuth 2.0 families and "not invent a new protocol". The second is authorization and delegation, answering "on whose behalf, and allowed to do what": Ping Identity's example uses the act claim of RFC 8693 token exchange to record the whole delegation path and may_act to restrict the next hop; but RFC 8693 was originally designed for server-to-server exchange "after consent has already happened" and does not natively cover a user's consent to a specific agent.

The third layer is externally verifiable identity, answering "why should a stranger trust it". Cloudflare Web Bot Auth signs HTTP requests with Ed25519 plus RFC 9421, but Cloudflare currently does not verify the nonce, relying mainly on a short validity of about 1 minute against replay; the ANS v2 draft verifies domains via ACME and has three tiers: Bronze, Silver (adds DANE) and Gold (adds a SCITT transparency log). A2A only touches this layer through card signing, and signing is optional. Commercial products have shipped first: Okta Agent SSO became generally available on 2026-08-24 and uses ID-JAG; Microsoft Entra Agent ID does not natively support ID-JAG, and sources differ on its general-availability date (2026-04 or 2026-05). So when doing A2A across companies, both sides will likely have to convert tokens at their own boundaries; this is an inference.

Governments are also working to fill this gap. On 2026-02-17 NIST's CAISI announced the AI Agent Standards Initiative, whose three pillars are industry-led standards, community-led open-source protocols, and agent security and identity research; but the initiative page uses only generic terms such as "interoperable agent protocols" and does not name A2A or MCP. The NIST NCCoE project "Software and AI Agent Identity and Authorization" published a summary of comments on its concept paper on 2026-09-29, with more than 600 organizations or individuals responding. NIST's 2026-10-27 blog post "Design Tenets for Agent Identity Management Systems" sets out 10 design principles, including that agents should have their own identity linked to the initiator with permissions narrowing at each delegation step, least privilege, short-lived and revocable authorization, risk-triggered human intervention, signed mandates defining the scope of action, and tamper-proof records; it is positioned as a blog post, not a formal standard.

Academic research points the same way. South et al. propose extending OAuth 2.0/OIDC with agent-specific credentials and building auditable delegation chains, with a position version of the same research included in the ICML 2025 Position Paper Track; Chan et al. at FAccT 2024 argue for three kinds of measures, agent identifiers, real-time monitoring and activity logs, to increase visibility into agents.

AP2 is no longer the version people remember from 2025. v0.2.0 reworks the mechanism into Checkout Mandates and Payment Mandates, each split into open and closed stages and implemented with SD-JWT, with the open mandate storing the agent's public key in a cnf claim. The key addition is the Human-Not-Present flow: the user first signs an open mandate with their own key on a trusted surface and writes down constraints, and the agent later signs a closed mandate with the agent key, with the two bound together by sd_hash; a merchant or credential provider can return unresolved_constraint to pull the flow back to "human present". The spec also recommends that merchants sign the Checkout JWT with non-deterministic signatures (ECDSA) rather than Ed25519, to prevent rainbow-table attacks. Most importantly, the AP2 spec lists dispute handling, retention and retrieval as out of scope, promising only a non-repudiable cryptographic audit trail. The research notes also observe that the extension method the AP2 spec recommends is UCP's extension points, while A2A is not discussed in the spec body at all; AP2's positioning is shifting from "an A2A extension" to "a security layer inside commerce protocols". This is an inference.

Payment extensions attach to A2A through A2A's own extension mechanism: they are declared in AgentCapabilities as an AgentExtension (uri, description, required, params), and the client requests activation with the A2A-Extensions header. Extensions cannot modify core data structures or add enum values and may only operate through metadata; breaking changes require a new URI, and on hitting an unsupported version they "MUST NOT fall back". a2a-x402 (spec v0.1) is such an extension: the merchant sends payment-required, the client signs and returns payment-submitted, and after on-chain settlement the merchant returns payment-completed.

x402 transaction counts come mainly from wash activity. Chainalysis counts more than 100 million cumulative x402 transactions on the Base chain through Q1 2026, but the surge in Q4 2025 was "mostly driven by meme coin farming", and weekly retention fell from 87% to 5%. Coinbase claimed at the end of April 2026 about 165 million transactions and about USD 50 million in cumulative volume; this is a vendor claim. Artemis believes more than 95% is protocol signaling or testing, and another tracking site estimates real commerce volume at about USD 28,000 per day.

What card networks and platforms actually do is "accept multiple protocols, with human-present strong authentication as the safety valve". In March 2026 OpenAI moved Instant Checkout in ChatGPT back to a merchant Apps model; a spokesperson said "Instant Checkout is moving to Apps". On 2026-07-02 Visa announced that agents had completed real purchases in Europe, with more than 30 partner issuers, and every transaction used Payment Passkeys to meet strong customer authentication (SCA). The liability framework is still blank: Chargebacks911 warns that dispute and liability infrastructure is "largely unaddressed"; Taylor Wessing's analysis is that under the EU framework, a purchase by an agent that exceeds the conditions set by the customer will in principle be treated as an unauthorized transaction; Ant International, Visa and Mastercard only began exploring a Know-Your-Agent interoperability framework on 2026-09-10. The EU's PSD3/PSR has so far only reached the Council's first-reading position adopted on 2026-10-29 and has not yet been published in the Official Journal, and a keyword search of the Council's PSR statement of reasons finds no AI or autonomous-agent provisions; the US CFPB has no guidance on agent payments either.

Academic research points to another blind spot. Debi et al. (IEEE IMNS 2026) red-teamed an AP2 shopping agent and showed that indirect and direct prompt injection can manipulate product ranking and extract sensitive user data, illustrating that a signed mandate cannot protect the reasoning that happens before signing; Jiang et al. (arXiv:2609.00060) used Tamarin to formally analyze x402, MPP, ACP and AP2, highlighting the security dependencies created when intent, delegated authority and settlement are spread across multiple parties. Agentification in logistics is currently going through MCP: Flexport's MCP server lets customers' AI assistants book freight at negotiated rates and obtain a booking ID. The research notes found no instance of freight charges being settled via AP2 or x402.

The Linux Foundation's first-anniversary press release of 2026-04-09 says A2A has 150+ supporting organizations and production deployments in supply chain, finance, insurance and IT operations; this is a vendor claim: the release names no users and provides no process or outcome metrics. The most frequently cited examples, a Microsoft Agent Framework .NET article and Google's purchasing concierge codelab, are code samples, not deployment reports. Tyson Foods is often promoted as an A2A supply-chain case, but apis.io gives its A2A Agent Card a score of 0/8, and what it offers trading partners is still EDI and APIs.

The most direct counter-evidence is testing. In April 2026 one author sampled 50 agents claiming A2A support from a public registry; only about 0–2 served a valid card at the well-known path, and 0 responded correctly to a task. The same author sent 24 requests to 12 organizations on 2026-09-09 and 36 requests to 18 organizations on 2026-10-27, and got 0 cards both times. The samples were chosen by the author and are not a census, but they point the same way. What actually runs is interoperability within a single cloud platform: AWS AgentCore, Microsoft Foundry and Google Agent Registry.

The evidence on multi-agent architectures themselves also weighs against cross-organization A2A. MAST (NeurIPS 2025 Datasets & Benchmarks Track) analyzed 1,642 execution traces and identified 14 failure modes in three categories: system design, inter-agent misalignment and task verification; the 7 state-of-the-art open-source multi-agent systems studied had failure rates between 41% and 86.7% (the authors caution that different benchmarks are not directly comparable). "Towards a Science of Scaling Agent Systems" by authors from Google Research, MIT and elsewhere tested 180 configurations in v1/v2 and the Google blog version: independent multi-agent setups amplified errors 17.2 times and centrally coordinated ones 4.4 times, and on sequential reasoning tasks every multi-agent variant degraded by 39%–70%; v3 of 2026-04-08 expanded to 260 configurations and 6 benchmarks and kept the 17.2x and 4.4x findings. Anthropic's engineering blog (not a peer-reviewed paper) states that its multi-agent research system outperformed single-agent Claude Opus 4 by 90.2%, but used about 15 times the tokens of a normal chat, and names domains "that require all agents to share the same context or involve many dependencies between agents" as poorly suited. Cross-organization A2A happens to combine all of these unfavorable conditions: the two sides share no context, there is no common verifier, and commerce flows (quote→order→payment→shipment) are sequential; this is an inference.

The engineering gaps are larger than the spec gaps. Traces break when A2A delegates to the next agent: the Python SDK only creates local spans, and there is no standard way to propagate W3C Trace Context between agents (Issue #2103). The community Rust SDK reported 7 TCK failures, which on comparison were judged to be defects in the test suite itself; the same report says the JS, Go and Java SDKs passed 21/21 on both bindings. Consumer-side agent traffic is also still small: HUMAN Security counted 7,851% year-over-year growth in agent traffic in 2025, but only 2.3% occurred on checkout pages; a secondary source citing Cloudflare Radar data from August 2026 puts AI bots at about 7% of HTML requests, of which "acting in real time on behalf of users" accounts for only 5.8%; multiplied together that is about 0.4%, a calculation that is an inference and has not been confirmed against the raw data. Akamai warns that e-commerce sites only monitor more than 90% of AI bots, while fraudulent agent activity is increasing. The research notes found no evidence of personal agents such as ChatGPT, Gemini or Claude using A2A to call ordinary enterprise agents, but this is only an absence of evidence, not an official confirmation.

Interviews by governments and international organizations show that the demand is real. OECD Artificial Intelligence Papers No. 65 records on page 16 that the practitioners interviewed prefer open protocols and see agent-to-agent communication protocols such as A2A as an important enabler of multi-agent coordination, while worrying about lock-in to a single vendor's ecosystem.

Taiwan: the Basic Act on Artificial Intelligence has 20 articles. Article 3 defines artificial intelligence as "a system capable of autonomous operation", which can cover AI agents, but the word "agent" does not appear in the Act; Article 4 lists seven principles, including human autonomy and oversight, transparency and explainability, and accountability; under Article 16 the Ministry of Digital Affairs promotes a risk classification framework that interfaces with international ones; Article 17 requires the government to define liability and the conditions for attributing it for high-risk AI, and to establish remedy, compensation or insurance mechanisms; Article 18 requires agencies to complete the related regulatory adjustments within two years of entry into force. Under Article 16, the Ministry of Digital Affairs announced the AI Risk Classification Framework v1.0 on 115-07-07 (ROC calendar; Digital Strategy Letter No. 1150015933, effective immediately), in which risk type B6, "unauthorized actions by autonomous AI agents", states: "Multi-agent systems are more likely, through agents triggering one another, to produce chain reactions unanticipated by both developers and users, making it difficult for humans to intervene and correct them in time." The Ministry of Health and Welfare's guidelines on generative AI for medical institutions, issued by letter on 115-05-29, explicitly state that AI agent systems are "not yet covered by these guidelines".

Taiwan's existing laws also apply to agent scenarios. Article 4 of the Personal Data Protection Act provides that anyone commissioned to collect, process or use personal data is, within the scope of the Act, deemed to be the commissioning agency, so handing personal data to an agent does not escape liability because "an AI is doing it"; Article 21 governs restrictions on international transfers. Note that several articles amended on 114-11-11 (including the new Article 21 and the newly added Article 20-1) have been promulgated but are not yet in force; the effective date will be set by the Executive Yuan. The Electronic Signatures Act does not mention AI or agents; whether a signature made by an agent on someone's behalf can be presumed to be that person's own signature is not stated in law and cannot be confirmed by this article.

China: in National Standard Announcement No. 22 of 2026, the State Administration for Market Regulation and the Standardization Administration of China approved and published on 2026-05-22 the GB/Z 185.1–185.7-2026 series "Artificial Intelligence: Agent Interconnection", 7 guidance technical documents in total (overall architecture, identity code, identity management, agent description, agent discovery, agent interaction and agent tool invocation). The National Public Service Platform for Standards Information lists their status as "current", the full texts were made public on 2026-06-18, and SAMR held a dedicated press conference on 2026-06-26. The protocol name used in the official documents is AIP (Agent Interconnection Protocol); none of the official pages found mention A2A or MCP, and whether the two are compatible is unverified. The Implementation Opinions on Standardized Application and Innovative Development of Intelligent Agents, jointly issued on 2026-05-08 by the Cyberspace Administration of China, the National Development and Reform Commission and the Ministry of Industry and Information Technology, bundle AIP promotion, an agent registration platform and agent digital identity into one package, and require that "operations performed by agents must not exceed the scope authorized by the user". This approach differs from the A2A community's "no official registry".

EU: the AI Act (Regulation (EU) 2024/1689) entered into force on 2024-08-01; obligations for general-purpose AI models have applied since 2025-08-02, and general application and transparency obligations from 2026-08-02. High-risk obligations were postponed by Regulation (EU) 2026/1744 (published in the Official Journal on 2026-07-24): Annex III to 2027-12-02 and Annex I to 2028-08-02. For PSD3 and PSR, the Council adopted its first-reading position on 2026-10-29; a second reading by the European Parliament is still pending, and they have not been published in the Official Journal.

United States, Singapore, United Kingdom: CISA, the NSA and other Five Eyes agencies published "Careful Adoption of Agentic AI Services" on 2026-04-30/05-01, recommending restricted access privileges and starting with low-risk, non-sensitive use cases. The US CFPB has no guidance on agent payments, and its related 2025 interpretive rule proposal was withdrawn on 2025-05-15. Singapore IMDA's Model AI Governance Framework for Agentic AI v1.5 (published 2026-05-20, updated 06-05) directly names, in section 1.1.1, A2A for agent-to-agent communication and MCP for agent-to-tool communication, and identifies recursive delegation and cross-organization identity as current gaps. The UK CMA's guidance published on 2026-03-09 (updated 10-30) states "if an AI agent you use does something illegal, you are responsible", meaning businesses are liable for illegal acts by the agents they use; the UK ICO's call for evidence on agentic AI closes on 2026-11-20.

Issue #1942 consolidated 41 issues into eight v1.1 themes; cross-task agent memory (#893) is outside the tracked scope. The most-commented issues say more about direction than the theme list: #1672 agent identity verification for Agent Cards (about 658 comments), #1829 message signing with Ed25519 plus RFC 9421, #2028 actor-chain delegation, #2121 passing cost and budget, and #1815 using HTTP 402 to signal "payment required". These are all trust and commerce problems; together with the newly created extension governance process, the research notes judge that they are more likely to arrive as extensions than as changes to the core spec. This is an inference.

"How does a personal agent find a company's agent?" currently has no deployed open answer. The official A2A documentation states explicitly that curated registries are outside A2A's scope; the Agent Registry proposal in Discussion #741 has dragged on for a long time, with reviewers questioning its premise that "providers manage their own registry entries". For finding agents from a domain, the IETF has four competing individual drafts: DNS-AID (an SVCB record pointing to /.well-known/agent-card.json), AID (looking up an _agent TXT record), ADP and DAN, none yet adopted by a working group; a landscape draft from July 2026 also notes that the namespace needs coordination. On the MCP side, the MCP Registry has remained in preview from September 2025 until now.

There is likewise no framework for cross-organization auditing and liability. The A2A spec only has SHOULD-level requirements for logging authentication failures and rate limiting, and sources contradict each other on the stability status of the OpenTelemetry GenAI semantic conventions. With current tools, the minimal audit unit that can be retained is roughly: your own side's taskId and contextId, the fingerprint of the other side's Agent Card signature, and the act delegation chain of the token the other side presents, each kept by both parties for later reconciliation; this is an inference. The research notes also found no empirical research on denial-of-wallet attacks aimed at "exhausting the other side's LLM budget".

A2A today looks a lot like early HTTP: the format is standardized, and the trust layer still has to be added by each party; the difference is that this time the called party reasons on its own and can even be persuaded by the other side. The bottleneck is therefore not engineering but "who is responsible for what the agent does", and that question is currently scattered across the IETF (identity), the FIDO Alliance (payment intent), the card networks (disputes) and national regulators, beyond the reach of A2A's TSC. From this we infer that the most likely form of cross-company agent interoperability over the next few years is "an A2A shell wrapping deterministic tool calls": the called party looks like an agent on the surface but is really an API inside, and real reasoning happens only within each company's own trust boundary.

Government guidance points the same way. CISA, the NSA and other Five Eyes agencies recommend starting with low-risk, non-sensitive use cases and restricting access privileges; Singapore's IMDA framework makes "holding humans meaningfully accountable" and technical controls core dimensions; Taiwan's Ministry of Digital Affairs lists chain reactions from agents triggering one another as risk B6; and the UK CMA states plainly that businesses are liable for illegal acts by the agents they use.

The table below grades adoption options for ordinary enterprises by strength of evidence. "Do" means low risk and clear payoff on current evidence; "Optional" means low cost but no measured cases; "Defer" and "Don't" each come with reasons, to be re-evaluated when trigger conditions appear.

The core queries in cross-border e-commerce and logistics (how much is shipping, how much are the taxes, what is this product's tariff code and what are its import regulations) are deterministic calculations to begin with, exactly the kind of service external agents need most and are least likely to get wrong. Anthropic's engineering blog reports that rewriting tool descriptions alone cut task completion time for later agents by 40%; OpenAI's move of Instant Checkout back to merchant Apps shows that transactions ultimately return to the merchant's own flow. So the order of preparation for businesses should be: first make web pages and structured data readable, then turn deterministic tools into MCP, add continuation URLs in tool responses to bring transactions back to your own flow, and only then consider an A2A placeholder.

An A2A placeholder card means publishing a card at /.well-known/agent-card.json whose skills map to existing deterministic tools such as quotes, taxes and process information, backed by direct program calls with no LLM running. This approach is low-cost and has "option value", but there is currently no measured case of any small or medium-sized business gaining traffic or revenue from it; this is an inference. If you really do open an A2A endpoint, at a minimum: expose read-only skills only, trust no field of the other side's card, reject private IPs in push URLs, and log taskId, contextId, caller identity and traceparent.

What HowBridge does today (all verifiable on the HowBridge developer page): HowBridge offers a public MCP that needs no API key and no OAuth (https://0523.tw/mcp/public), containing 8 read-only, idempotent tools covering an introduction to the HowBridge brand and services, consolidated shipping cost estimates from China to Taiwan (sea express/air), Taiwan import tax estimates, CCC tariff code candidates by product name, CCC tariff rates and import regulations, oversize fees for the Taiwan delivery leg, and the consolidation process and simplified declaration rules, limited to 120 requests per minute per IP, and listed in the official MCP Registry (name tw.0523/lucky-public); shipping cost responses include a continuation URL (continue_url) so users can return to the website and continue. The member MCP (https://0523.tw/mcp) uses OAuth 2.1 authorization and provides 6 read-only tools that can only read the authorized member's own bills, parcels, pre-alerts, tax bills and import declarations, with defaults of 60 requests per minute and 5,000 per day. The entry points currently listed on the HowBridge developer page are the member data API, the member MCP and the public MCP; there is no A2A endpoint, and this article does not mean HowBridge supports A2A.

If you want an AI assistant to help estimate the cost of shipping from China to Taiwan, you can use the web versions of the consolidated shipping cost calculator, the import duty calculator and the tariff code lookup directly; the tools and the public MCP share the same calculation logic. Estimates are for reference only: shipping costs are based on the bill issued after measurement at warehouse intake, and taxes are as assessed by customs.