Gartner's forecast for 2026 is that 40% of enterprise applications will ship with task-specific AI agents, up from under 5% in 2025. The counterintuitive part is what that number does to your architecture: the organisations struggling most this year are not the ones with too few agents. They are the ones with too many agents that cannot talk to each other.
Every department buys its own. Finance has an invoice agent inside its ERP. Customer service has one inside its ticketing platform. Legal has a contract reviewer. Each works. None of them can hand a task to another without a human copying output from one screen into another.
That is the problem A2A was built to solve, and in 2026 it stopped being a research curiosity and became infrastructure.
What is A2A?
A2A (Agent2Agent) is an open protocol that lets independent AI agents discover each other, delegate tasks and exchange results across organisational and vendor boundaries. It was contributed by Google to the Linux Foundation, which now governs it as a vendor-neutral standard rather than a single company's product.
The practical unit of A2A is the Agent Card: a machine-readable JSON document that publishes what an agent can do, what endpoint it lives at, and what authentication it expects.
One agent reads another's Agent Card the way a procurement team reads a capability statement, then decides whether to delegate.
According to the Linux Foundation's one-year announcement in April 2026, more than 150 organisations now support the standard, it reached a v1.0 stable specification with cryptographically signed Agent Cards, and it has landed inside the major cloud agent platforms with production deployments across multiple industries.
How is A2A different from MCP?
MCP governs how a single agent reaches downward into tools, databases and files. A2A governs how one agent reaches sideways to another agent. They are complementary layers, not competitors, and most enterprise architectures designed in 2026 use both at once.
The cleanest way to hold the distinction: MCP is how an agent uses its hands. A2A is how two agents shake them.
An invoice agent uses MCP to query your ERP and read a PDF. It uses A2A to ask the procurement agent, which may sit in a different vendor's platform entirely, whether a purchase order exists for that invoice.
If your team has already worked through what MCP means for enterprise integration, A2A is the second half of the same picture, and the half most integration roadmaps have not budgeted for.
The distinction matters commercially. MCP decisions live inside one system owner's budget. A2A decisions cross budgets, cross vendors and, increasingly, cross legal entities.
What actually happens when two agents talk to each other?
An A2A exchange has four steps: discovery, task submission, status streaming and result return. The requesting agent fetches the remote Agent Card, submits a task with a defined lifecycle, receives progress updates while the work runs, and collects a structured artifact at the end.
The parts worth a decision-maker's attention are the ones that map to controls you already recognise.
--- Discovery: the Agent Card declares skills, endpoints and required credentials. Signed cards let you verify the publisher.
--- Task lifecycle: tasks are stateful objects with explicit states, so a long-running job is auditable rather than a fire-and-forget API call.
--- Transport security: HTTPS with TLS, plus role-based access control that plugs into existing enterprise identity.
--- Artifacts: results come back as typed outputs, not free text, which is what makes downstream automation safe.
The one thing A2A deliberately does not solve is identity semantics. Identity is handled at the protocol layer by whatever your infrastructure already enforces, which means A2A inherits your identity weaknesses rather than fixing them.
Why does agent interoperability matter for Hong Kong enterprises now?
Because Hong Kong's regulator has already named agentic AI as a distinct risk category. The Privacy Commissioner for Personal Data has treated agent autonomy and system access as materially different from chatbot risk, which turns cross-agent delegation into a compliance question, not only an engineering one.
In the PCPD's 2026 compliance checks, covering 60 organisations across sectors, the share of organisations running regular internal audits or independent assessments rose by roughly 17 percentage points year on year, and human-in-the-loop adoption rose by a similar margin.
Read that as a direction of travel. The bar for demonstrating oversight is rising while the systems being overseen are becoming more autonomous.
Now add the local operating reality. Hong Kong mid-market firms rarely run one vendor's stack end to end. A logistics group might run Microsoft in the back office, a mainland-built WMS in the warehouse and a regional SaaS for customs documentation.
Interoperability is not an aspiration in that environment. It is the only way agents ever leave a single department.
What framework should leaders use to assess A2A readiness?
Use a four-question readiness test before funding any cross-agent work: Do you have an agent inventory? Can you authenticate a non-human caller? Who owns the delegated outcome? And what is the blast radius if delegation goes wrong? Failing any one of these makes interoperability premature.
--- Inventory: list every agent already running, its owner, its data access and whether it was procured or built. Most organisations discover more agents than their IT register shows.
--- Non-human authentication: agents are callers without a person behind them. If your identity platform cannot issue and revoke credentials for a workload, A2A will paper over a gap you cannot see.
--- Outcome ownership: when agent A delegates to agent B and the result is wrong, one named business owner must be accountable. Protocols do not assign accountability. Governance does.
--- Blast radius: define the maximum financial and data exposure of a single delegated task, then cap it. A delegation that can approve unlimited spend is a control failure regardless of how well the protocol performs.
The value of this test is that it is answerable in a two-hour workshop, and the answers tell you whether your next agent investment should be a new agent or a control layer under the agents you already own.
How does this play out in a real organisation?
Three Hong Kong scenarios show the same pattern: the technical connection is the easy part, and the ownership question is what stalls the project. Interoperability projects fail at the governance boundary far more often than at the integration boundary.
A financial services firm, 400 staff. A KYC agent needs to delegate document verification to a vendor's specialist agent. The protocol work takes two weeks. The question of whether client documents may leave the firm's tenancy takes four months and ends with a scoped delegation that returns only a verification verdict, never the underlying document.
A logistics group, 250 staff. A booking agent delegates customs classification to a regional service. It works until the service updates its Agent Card and silently changes an output field. Nobody was monitoring the card. Three weeks of misclassified shipments follow.
A professional services group, 120 staff. Partners want a research agent to delegate to a billing agent. Legal blocks it because there is no audit trail showing which human authorised the chargeable time. The fix is not technical. It is a policy stating that delegation may prepare a charge but never post one.
What goes wrong when organisations adopt agent protocols too early?
The dominant failure is adopting a protocol before establishing governance, which produces working integrations nobody will sign off on. Gartner has warned that over 40% of agentic AI projects could be cancelled by 2027 on unclear value, rising costs and weak governance. Protocol maturity does not protect against any of those three.
--- Assuming the protocol carries policy. Academic analysis of agent protocols in 2026 has been direct that MCP, A2A and ACP cannot express many governance constraints organisations assume are covered. Permissions, purpose limitation and data residency remain your job.
--- Skipping the agent inventory. You cannot govern delegation between agents you have not catalogued.
--- Treating Agent Cards as static. A card is a live contract. Version it, monitor it and alert on change, the same way you would treat a supplier's API.
--- Letting the protocol choose the use case. The correct sequence is business decision first, delegation design second, protocol last. Reversing that produces impressive demonstrations and no measurable outcome.
--- Underestimating cross-boundary cost. Every external delegation carries a commercial relationship, a security review and a support path. Budget for all three, not just for the build.
What should you do in the next 90 days?
Run a three-stage sequence: inventory your agents in 30 days, define one delegation policy in 60, and pilot exactly one cross-agent workflow in 90. The discipline is in the count. One pilot generates learning. Five simultaneous pilots generate a governance backlog nobody will clear.
--- Days 1 to 30: build the agent register. Owner, data scope, procurement route, whether it exposes or consumes an interface.
--- Days 31 to 60: write one page of delegation policy. What may be delegated, to whom, with what financial cap, and who signs off.
--- Days 61 to 90: pilot a single internal delegation with a measurable outcome, such as hours removed from one handoff. Keep it inside your own tenancy for the first cycle.
Nothing in that sequence requires a platform decision. That is the point. The organisations that will handle agent interoperability well in 2027 are the ones building the register and the policy in 2026, while the protocols are still settling.
The strategic takeaway
A2A has become real infrastructure fast: a stable specification, Linux Foundation governance, 150-plus supporting organisations and production use inside a year. That maturity is genuine, and it changes what is technically possible in your architecture.
It does not change what is organisationally possible. A protocol can make two agents interoperable. Only governance can make a delegated outcome defensible to your board, your auditor and Hong Kong's regulator.
The leaders who get this right will not be the ones who adopted A2A earliest. They will be the ones who knew which agents they owned, who was accountable for each delegated decision, and what the worst case looked like before they connected anything.
That is unglamorous work, and it is the work that separates an AI programme from an AI demonstration. We understand AI. We understand you. With UD by your side, AI never feels cold.
Reviewed by the UD enterprise AI team, Hong Kong.
Where to start
Now that you have the framework, the next step is identifying the right entry point for your organisation. We'll walk you through every step, from AI readiness assessment to agent inventory, delegation policy and a first measurable pilot, backed by 28 years of Hong Kong enterprise experience.
