A2A and MCP for Customer Support: What Support Leaders Actually Need to Know

Two acronyms have been showing up in vendor decks all year, usually on a slide nobody explains. A2A and MCP are protocols, not products, and the reason they matter to a support leader has nothing to do with the specification and everything to do with what your queue looks like in eighteen months.

This is the version without the JSON.

The two protocols, in one paragraph each

MCP connects your agent to your tools

The Model Context Protocol is a standard way for an AI agent to call external systems: your helpdesk, your CRM, your order database, your billing platform. Before it existed, every connection between an AI system and a business tool was a bespoke integration, which is why AI support pilots used to spend their first six weeks on plumbing.

Anthropic released it in late 2024 and donated it to the Agentic AI Foundation under the Linux Foundation in December 2025, alongside founding contributions from Block and OpenAI. That governance move is the part support buyers should care about, because it means MCP is no longer one vendor's standard. AWS, Google, Microsoft, Cloudflare and Bloomberg all sit on the foundation. When competing platform companies agree on a connector format, the format has won.

A2A connects your agent to other companies' agents

Agent2Agent covers a different problem: how an agent built by one organisation discovers, authenticates with, and delegates work to an agent built by another. Google released it in April 2025 and handed it to the Linux Foundation two months later. It reached v1.0 and crossed 150 supporting organisations in April 2026, with production deployments across supply chain, financial services, insurance and IT operations, plus native support in Azure AI Foundry, Copilot Studio and Amazon Bedrock AgentCore.

The shorthand that enterprise architects have settled on is worth memorising because it survives most arguments: MCP for tools, A2A across organisations. They're complementary, not competing, and the vendor telling you to pick one doesn't understand either.

Where the line falls in a support stack

Concretely, in a support deployment:

• MCP is how your agent reads an order. It calls your commerce platform, pulls the order record, checks fulfilment status, and issues the refund. All internal, all under your credentials.
• A2A is how a customer's agent asks yours for something. It finds your published capabilities, authenticates, submits a task, and receives a typed result rather than a paragraph of prose.
• A2A is also how your agent talks to a partner's. Your support agent delegating a delivery exception to a 3PL's logistics agent is the same shape as a customer's agent talking to yours.

Most of what your team touches today is the MCP half, whether or not anyone calls it that. Every action-taking integration in a modern support platform, whether that's closing a ticket, issuing a credit, or updating a shipping address, is that pattern. Robylon's 60+ write-access integrations are the same thing, standardised.

The A2A half is the one that's about to arrive and that almost nobody in support has planned for.

A worked example: one delayed parcel

Take a hypothetical furniture retailer with a $1,400 dining table stuck somewhere between a warehouse in Rotterdam and a flat in Lyon. Trace the same problem through both protocols and the division of labour gets obvious.

The customer never writes to anyone. Their assistant notices the delivery date has slipped past the promise, finds the retailer's agent card, authenticates, and submits a task: status and remedy for order 88214.

That's A2A. One request, typed, with an identity attached.

Everything after that is MCP. The retailer's agent pulls the order from the commerce platform, queries the carrier's tracking system, checks the returns policy for what a fourteen-day delay entitles the customer to, and calculates a goodwill credit against the rules it's been given. Four tool calls, all internal, all under the retailer's own credentials.

Then A2A again for the answer: a structured response with the revised delivery window, the credit amount, and a reference. The customer's agent takes it, and the customer sees a two-line summary at breakfast.

What used to be a four-email thread over three days becomes one exchange in about eleven seconds. That's the appeal, and it's real.

Now change one variable. Suppose the remedy the policy points to is a full refund and reshipment on a $1,400 order rather than a small goodwill credit. Same protocols, same authentication, same clean typed request, and a decision that no sensible retailer wants made by two pieces of software agreeing with each other at 4 a.m. with nobody watching. The protocol handles the transport perfectly. It has nothing to say about whether the action should have happened.

That gap is where the rest of this article lives.

Agent cards, and why your support org will publish one

A2A's discovery mechanism is the agent card: a JSON manifest published at a well-known path on your domain, advertising your agent's identity, its skills, its endpoint, and how to authenticate against it. It's the DNS-shaped layer of the whole thing. If you've ever written a robots.txt or an OpenAPI spec, the instinct transfers.

v1.0 added signed agent cards, which let the other side cryptographically verify that the card belongs to who it claims. That solves an identity problem that would otherwise have made the whole architecture unusable in regulated industries.

Here's the decision most support leaders haven't been asked yet: what do you publish?

Advertising that your agent can check order status is straightforward. Advertising that it can issue refunds up to $200 without human review is a very different sentence to put in a public manifest, because you've just written a specification for anyone who wants to probe that boundary. Our own view is that the first generation of support agent cards should be deliberately conservative, with read operations and status queries public, and anything that moves money behind an authenticated, rate-limited path with a named counterparty relationship.

That's not the exciting answer. It's the one that doesn't end up in an incident review.

What actually changes in operations

Protocol adoption sounds abstract until you look at what it does to the day job.

Queue shape

Structured inbound doesn't behave like human inbound. It arrives in bursts, at any hour, with complete identifiers and no narrative. It also arrives at a different volume, because software has no social cost for asking. We've written separately on how this plays out on email in the machine inbox; A2A is the same pressure with better plumbing.

Authentication stops being enough

OAuth proves a request came from a legitimate agent. It says nothing about whether the human that agent represents actually approved this specific refund. The standards community has been working the problem through 2026, and there's real movement on agent identity and delegation chains, but nothing is settled. A support org taking money-moving instructions from third-party agents is carrying that gap on its own balance sheet.

Practical answer for now: a value threshold. Below it, act. Above it, a human confirms. Boring, effective, defensible.

Audit trails get harder and more important

When an action was requested by an external agent, executed by your agent, against a record in a third system, the question of who authorised this and on what basis has four possible answers and you need to be able to produce all of them. Whatever you're logging today for internal automation is probably insufficient. Our guide to what to log in AI email support covers the baseline; add counterparty identity and the card version that was in effect at the time.

Per-resolution pricing gets strange

If you're on a per-resolution contract and a customer's agent opens four tasks where a human would have sent one email, who pays for the extra three? Vendors have not standardised on an answer. Ask before you sign. It's a live commercial question, and the definitions already vary enough between vendors to move total cost meaningfully.

The security part

Email was already the untrusted-content channel. Protocol traffic doesn't fix that; it changes the shape of the exposure.

An agent endpoint that accepts structured tasks from external agents is, by construction, a system that takes instructions from strangers and acts on private data with the ability to communicate outward. That combination is the one security researchers have been warning about, and prompt injection is now the fastest-growing attack class in the field.

The mitigations aren't exotic, they're just work:

• Verify signed cards. An unsigned card is an unauthenticated claim. Treat it as such.
• Scope tokens narrowly. An external agent asking about order status has no business holding a credential that could also change a payment method.
• Separate the retrieval path from the action path. Content an external agent supplies should never be able to reach the layer that decides which tool gets called.
• Cap and log per-counterparty. Rate limits by relationship, not just by IP, and a running total of what each counterparty has caused you to do.
• Keep a kill switch per skill. If one advertised capability turns out to be exploitable, you want to withdraw it without taking the whole endpoint down.

If you're building the buyer-side version of this list, our enterprise security checklist for AI email support covers the ground that applies regardless of protocol.

What to ask a vendor in 2026

Most support platforms will claim protocol support this year. These questions separate the ones who've implemented from the ones who've read the press release:

1. Do you consume MCP servers, expose one, or both? Which of your actions are available through it?
2. Do you publish an agent card on our behalf, and can we control what skills it advertises?
3. Do you verify signatures on inbound agent cards, and what happens when verification fails?
4. How is an externally-originated task represented in our logs and our reporting, separately from human tickets?
5. Under our contract, does an external agent's task count as a resolution?
6. What's the escalation path when an external agent's request exceeds our authority threshold?

Question four is the one that catches people. A vendor who can't separate machine-originated work in reporting will hand you a resolution-rate number that quietly changes meaning as the mix shifts, and you won't find out until someone asks why the trend line moved.

What's worth doing this quarter

Honestly, not much of this needs to happen right now. The protocols are stable, the tooling is real, and the inbound volume from third-party agents is still small for most companies. Rushing to publish a permissive agent card in 2026 is a way to be early to a problem rather than early to an advantage.

What's worth doing is narrow. Find out which of your integrations already run over MCP, because several probably do. Get your logging to the point where you could answer the counterparty question if asked. Decide your authority threshold as a policy rather than discovering it during an incident. And put the agent-card decision on a roadmap with a named owner, so that when a large customer asks whether you support A2A, and one will, the answer is a date rather than a shrug.

The teams that get this right won't be the ones who adopted first. They'll be the ones who knew what they'd already exposed.

How Robylon handles it

Robylon's platform sits on action-taking AI agents that resolve 60-80% of email tickets autonomously, with write access across helpdesks, commerce platforms, CRMs and billing systems rather than read-only lookups. That action layer is what protocol support is built on: an agent that can only answer questions has nothing meaningful to expose to an external counterparty anyway.

On the A2A side we're taking the conservative path described above. Human-in-the-loop confirmation above configurable value thresholds, machine-originated tasks segmented in reporting from the start, and capability exposure that a customer controls rather than one we decide for them. Deployment stays in the 3-7 day range because the integration work doesn't change; what changes is who's allowed to trigger it.

Frequently Asked Questions

What is the difference between A2A and MCP?

They solve adjacent problems. MCP standardises how an AI agent connects to tools and data (your helpdesk, CRM, order system) so integrations aren't rebuilt for every platform. A2A standardises how agents built by different organisations discover each other, authenticate, and delegate tasks across company boundaries. The working rule enterprise architects use is MCP for tools and A2A across organisations. Both are governed under the Linux Foundation, and most real deployments use them together rather than choosing.

Does my support team need to publish an agent card?

Not urgently, but it belongs on a roadmap with an owner. An agent card is a public manifest advertising what your support agent can do and how to reach it, so publishing one is a security decision as much as a technical one. A sensible first version exposes read operations like order status and leaves anything that moves money behind authenticated, rate-limited access with a named counterparty. Enterprise customers will start asking about A2A support during procurement.

How does A2A change customer support metrics?

Externally-originated tasks don't behave like human tickets. They arrive in bursts at any hour, one person's agent can generate several where a human sent one message, and satisfaction surveys become meaningless when the requester is software. The fix is to segment machine-originated work from human work in every report, because resolution rate, reopen rate, and cost per resolution each need separate columns. A blended figure changes meaning as the mix shifts.

Is prompt injection a real risk with agent protocols?

Yes, and it's the main one. An endpoint accepting tasks from external agents takes instructions from unknown parties, holds private customer data, and can communicate outward, which is precisely the combination that makes injection dangerous. It is currently the fastest-growing attack class against AI systems. Practical defences include verifying signed agent cards, scoping tokens narrowly per skill, keeping externally-supplied content away from the tool-selection layer, and capping actions per counterparty.

Should we wait before adopting A2A for customer support?

For inbound traffic from third-party agents, waiting is reasonable in 2026, since the volume is still small for most companies and a permissive public manifest creates exposure ahead of demand. What shouldn't wait is preparation: confirm which integrations already run over MCP, get logging to the point where you can identify the requesting counterparty, and set an authority threshold above which a human confirms any action. That work pays off regardless of protocol timing.

Ready to build a support stack that's ready for agent-to-agent traffic? Robylon AI resolves 60-80% of customer emails autonomously with AI agents that take action across Zendesk, Shopify, Salesforce, HubSpot and 60+ other integrations. Start free at robylon.ai