Your AI will soon be talking to your supplier's AI. Is your business ready to be spoken to?

For most of the last two years, the practical question for a small firm was "what can an AI do inside our four walls?" The answer was always the same shape: give it access to your files, your CRM, your calendar, and it gets useful. That access layer now has a standard, MCP, and I wrote about it in October.

The next question is the one most firms haven't met yet: what happens when your AI needs to work with somebody else's?

Two protocols, two different jobs

The cleanest way I know to hold this in your head is hands and colleagues.

MCP (Model Context Protocol) gives an agent hands. It's the standard way an agent connects to tools and data: your database, your ticket system, your accounts package. One agent, many tools, all inside your own boundary.

A2A (Agent2Agent) gives an agent colleagues. It's the standard way one agent finds another, learns what it can do, hands it a task and gets a result back, even when the two are built by different vendors and run in different organisations. The A2A project's own description is that MCP is the vertical layer connecting agents to tools and data, and A2A the horizontal layer for peer-to-peer collaboration between agents. They are complementary, not rivals.

Each A2A agent publishes an "Agent Card": a machine-readable description of who it is, what it can do and how to talk to it. In the version 1.0 specification those cards can be cryptographically signed, so the agent reading one can check who published it. That sounds like plumbing, and it is. It's also the difference between "an AI emailed us something" and "a verified agent from a known supplier asked us for a quote."

Why this is no longer a research curiosity

The reason to pay attention now is who has joined in, and how quickly.

• Google released A2A in April 2025. By April 2026 the Linux Foundation reported more than 150 supporting organisations, up from over 50 a year earlier, and a first stable 1.0 specification (March 2026).
• On 27 August 2026 the A2A project announced it had been accepted as a Growth Stage project at the Agentic AI Foundation, the Linux Foundation-directed home that also hosts MCP. The two standards now share governance.
• The Linux Foundation says Microsoft has built A2A into Azure AI Foundry and Copilot Studio, and AWS into Amazon Bedrock AgentCore Runtime. Supporters it names include Cisco, Google, IBM, Salesforce, SAP and ServiceNow. There are SDKs in several languages, .NET included.

That is vendor and platform support, not proof of a million live deployments. The Linux Foundation describes "active production deployments" in areas like supply chain, financial services and IT operations but gives no counts, and the names it gives are platforms rather than customers. Hold that lightly.

The direction, though, is hard to argue with. When the software your accountant, your logistics partner and your largest customer already use starts shipping agents that speak a common protocol, your side of that conversation is either ready or it isn't.

Why this is a small-business question, not an enterprise one

Think of a 40-person UK distributor. Today, an order query is a phone call, an email chain, and someone re-keying a figure into a spreadsheet. The agentic version is your customer's purchasing agent asking your agent for stock and delivery windows, your agent checking the warehouse system (that's MCP), asking the haulier's agent for a slot (that's A2A), and replying with a firm answer in seconds.

Firms that can be reached this way will be easier to buy from. Firms that can't will be the ones still answering the phone, and slower is a competitive disadvantage even when nobody says so out loud. This is the same pattern as the integration islands I wrote about last month: the work was never the AI, it was whether your systems could be connected to anything at all.

What a sensible UK firm does now

I wouldn't buy an "agent platform" this quarter. I would do the unglamorous things that make any of it possible:

1. List your systems and ask one question of each: does it have a proper, documented API? Anything that can only be driven by a person clicking is an island. That list is your real readiness score.
2. Pick one narrow capability and expose it safely. "Is this item in stock?" is a good first candidate: read-only, low risk, useful. Build it as an MCP tool internally before you think about exposing anything outside.
3. Treat agent identity like staff identity. An agent should have its own account, least-privilege access and a log of what it did. If you wouldn't give a temp the master password, don't give an agent one.
4. Know where personal data would travel. If your agent passes customer details to another organisation's agent, UK GDPR responsibilities don't disappear because software did the sending. Check data sharing terms and keep a record. This isn't legal advice; ask your data protection adviser.
5. Avoid lock-in on the wire. Both protocols are now under open governance, so prefer tools that speak them over proprietary connectors.

The cost of waiting

Nobody gets a letter saying "your market has moved to agents." What happens is quieter: a customer's system works smoothly with your competitor's and awkwardly with yours, and an order goes the easier way. The firms that spend this winter getting their data and APIs in order will be able to plug in when the counterparties arrive. The others will be retrofitting under pressure.

If you want a second pair of eyes on which of your systems are islands, and what a first MCP or A2A-ready service should look like for your stack, that's what I do as a fractional architect: cheesesharp.com