Agents Are Talking to Each Other Now: Multi-Agent Interoperability with A2A and MCP (2026)

TL;DR — Until 2025, AI agents mostly worked alone: each with its own model, its own tools, its own little world. In 2026 that changed. Agents now talk to each other. Two protocols make this possible: MCP (Model Context Protocol) connects an agent "vertically" to tools and data; A2A (Agent2Agent Protocol) connects agents to each other "horizontally." The two are not rivals — they are complementary. As of April 2026, MCP is deployed on more than 10,000 enterprise servers with over 97 million SDK downloads; A2A, under the Linux Foundation, surpassed 150 organizations in a single year. But there's a catch: roughly 79% of enterprises say they "adopted agents," while only about 11% actually run them in production. In this piece I explain why that gap exists, why security sits at the very heart of the matter, and where a Turkish enterprise should start within the bounds of KVKK, data residency, and human oversight.

The most common misunderstanding I run into while consulting in the field is this: "We already have an AI assistant, what's the difference?" The difference is enormous. A single assistant fits in a single box. You ask, it answers. But real enterprise workflows do not fit in a single box. Picture a procurement process: one agent that understands the request, another that scans supplier contracts, a third that runs budget checks, a fourth that manages the approval chain. Each of these may have been built by a different team, a different system, even a different company.

Until 2025, to connect these agents we wrote custom, brittle integrations every single time. Each connection was a hand-woven bridge; change one and the other collapsed. Now there are standard protocols. Just as the internet was built on TCP/IP and the web on HTTP, the agent economy is being built on a shared language. This is, without exaggeration, one of the most important infrastructure shifts of the last two decades. And most enterprises aren't even aware of it.

Here's the good part: these protocols are no longer controlled by a single company. Anthropic launched MCP, Google launched A2A, but both have been handed over to independent foundations. For enterprise decision-makers, that's a critical trust signal. Because no CTO wants to leave the backbone of their company at the mercy of a single vendor.

MCP, the Model Context Protocol, was developed by Anthropic and standardizes how an agent connects to the outside world — to tools, databases, file systems, APIs. I call this the "vertical" connection, because it reaches an agent down into the resources beneath it.

Let me offer an analogy. MCP is like the USB-C of the AI world. There used to be a separate charging cable for every device; one cable for a phone, another for a camera, a third for a laptop. USB-C arrived and they all met on a single standard. MCP does the same: write an MCP server once, and any agent that supports MCP can use that tool. Connect your CRM once, and whichever agent shows up can speak to that CRM.

The numbers show how fast this standard has spread. As of April 2026, MCP is live on more than 10,000 enterprise servers and its SDKs have been downloaded over 97 million times. More importantly, look at who has adopted it: Anthropic, OpenAI, Google, Microsoft, AWS. Giants that normally compete fiercely sat down at the same table on this. That's rare in this industry; when it happens, you know something has truly become a standard.

Let me make MCP concrete. Suppose a bank wants its customer-service agent to be able to query account balances. Without MCP, custom connection code has to be written for that agent; change the agent and the code is rewritten. With MCP, the bank stands up a "balance query" MCP server once and defines that capability together with its access limits and audit logs. Now whichever agent connects to that server runs under the same rules, with the same oversight.

A2A, the Agent2Agent Protocol, was originally developed by Google and solves a completely different problem: getting agents to talk to each other. If MCP reaches an agent down into tools, A2A brings two agents side by side. I call this the "horizontal" connection.

Think of it this way: MCP is the infrastructure that lets an employee access their computer, phone, and filing cabinet. A2A is two employees emailing each other, holding a meeting, handing off a task. One is a person's relationship with their tools, the other is the relationship between people. Both are necessary, both are different.

A2A's journey is instructive too. The project was brought under the Linux Foundation in June 2025, and by its one-year mark in April 2026 it had surpassed 150 organizations. Today it's integrated into Microsoft Azure AI Foundry and Copilot Studio, AWS Bedrock AgentCore, and Google Cloud. So even if you run one agent on Azure and another on AWS, they can speak a common language thanks to A2A. That meaningfully reduces the fear of cloud vendor lock-in.

At the heart of A2A is a concept called the "Agent Card." Each agent publishes an identity card that introduces itself: "Here's who I am, here's what I can do, here's how you can talk to me." Just like a business card. When one agent discovers another, it first reads this card, understands what it can do, and delegates tasks accordingly. This discovery mechanism lets agents collaborate even without knowing each other beforehand — which is essential for a scalable agent economy.

To clear up the confusion, let me compare them in a table:

Dimension	MCP (Model Context Protocol)	A2A (Agent2Agent Protocol)
Origin	Anthropic	Google (now Linux Foundation)
Direction	Vertical: agent → tool/data	Horizontal: agent ↔ agent
Problem solved	Agent access to resources	Collaboration among agents
Analogy	USB-C / tool belt	Email / business card
Core concept	Tool, Resource, Prompt	Agent Card, Task, delegation
Typical use	Connecting CRM, database, file, API	Orchestrating multi-agent workflows

Looking at this table, it becomes easy to see why they're complementary rather than competitive. In a real enterprise solution you use both: your agents talk to each other over A2A, and each agent reaches out to tools over MCP to do its job. Without one, the other is left half-done.

For a while there was a "which protocol will win?" debate. The industry expected a "winner-take-all" scenario, like the video format wars or the operating system wars. There's a third protocol too: ACP (Agent Communication Protocol), developed by IBM and AGNTCY. For a time, people thought the three protocols would devour one another.

But that's not what happened. Today MCP, A2A, and ACP all sit under Linux Foundation oversight. The era of "winner-take-all" is giving way to "complementary layering." That's a very important sign of maturity. Instead of destroying one another, the protocols are specializing at different layers. Just as the internet works not on a single protocol but on layered protocols stacked one on another (IP, TCP, HTTP, TLS).

For the enterprise decision-maker, the meaning is clear: you no longer need to wait out of fear of "betting on the wrong horse." All three major protocols are developing under a neutral foundation, designed to work together. That provides the confidence needed to invest. Instead of waiting and seeing, now is exactly the time to start with cautious but decisive steps.

Now I come to the most critical part. Agents talking to each other is exciting, but it also opens an entirely new attack surface. For years, the security world focused on managing trust between human users and systems. Now autonomous, decision-making agents have entered the picture. That requires rethinking security architecture from the ground up.

Ask this question: when an agent receives a task from another agent, how do we know that agent really is the one it claims to be? In the human world we verify identity — passwords, biometrics, multi-factor authentication. The agent world needs the same, but more complex. Because agents can appear and disappear dynamically, act on behalf of other agents, even delegate authority in a chain.

Three core pillars deserve attention:

• Identity and authentication: Every agent must have a verifiable identity. It must be able to answer "who are you?" cryptographically. A2A's Agent Card mechanism lays the foundation, but the enterprise must tie it tightly to its own identity infrastructure (enterprise SSO, a certificate authority, and so on).
• Authorization: An authenticated agent shouldn't be able to do everything. The answer to "you are who you say — but what are you allowed to do?" must be clear. The principle of least privilege is vital here. A payment-initiation agent should not have the authority to bulk-export customer data.
• Audit trail: Which agent, when, gave which task to which other agent; which tool did it access; which decision did it make? All of this must be recorded immutably. When something goes wrong — and it will — you need to go back and ask "what happened here?" Putting agents into production without an audit trail is something I would never recommend.

Beyond these three pillars there are new, agent-specific risks. Prompt injection, for instance: a malicious agent or data source can secretly slip harmful instructions into another agent. Or "privilege creep": authority silently accumulating along an agent chain until a power no one intended emerges. These aren't theoretical; they're real problems we're beginning to encounter in the field.

Now to the truth the industry least wants to discuss. According to Gartner, by the end of 2026 roughly 40% of enterprise applications will feature task-specific AI agents — a big jump from below 5% in 2025. The picture looks bright.

But there's the other side of the coin. Over the same period, about 79% of enterprises say they've "adopted AI agents," yet only around 11% actually run them in production. This chasm — the gap between adoption and production — is the industry's real story. Most enterprises get stuck in the pilot stage. The demo works, the presentation is impressive, management is excited; but when it comes time to go to production with real customer data, real money flows, and real accountability, everyone stops.

Why? Because production is a completely different game. An agent that errs in a demo is funny; an agent that errs in production means lawsuits, fines, reputational damage. That is precisely why the security, identity, and audit matters I described above form the wall between pilot and production. You cannot scale without crossing that wall.

"

My observation from the field: most enterprises that can't reach production are not stuck on a technical obstacle but on a gap in trust and governance. The model works; what's missing is the organizational answer to "what happens if something goes wrong?"

But there are strong signals that the gap is closing. Examples running in production, at real scale, now exist. In February 2026, Alipay processed roughly 120 million AI-agent-initiated transactions in a single week. That's not a toy figure; it's proof that real money is being moved by agents at real scale. Similarly, DBS Bank and Mastercard completed the first live agentic payment in Singapore. These are pioneering cases, and they show the rest of us the way: with the right security and governance, agents really can move money in production.

Now I come to the part I care about most: how does an enterprise in Turkey claim its share of this transformation? Because generic advice is easy; the real challenge is aligning it with local realities, with KVKK, with data residency constraints, with organizational culture.

The first and most important principle: build KVKK into the design from the very start. Agents process data; moreover, they hand data to one another. When one agent delegates a task containing personal data to another, that is a data processing activity under KVKK. The duty to inform, explicit consent (where required), purpose limitation, data minimization — all of these must be embedded into the agent architecture. Compliance bolted on afterward is never real compliance. Map out which personal data agents access, for what purpose, and for how long, from the very beginning.

Second: take data residency and on-prem options seriously. Many Turkish institutions — especially in finance, healthcare, and the public sector — don't want their data leaving the country, or legally can't let it. The good news: because MCP and A2A are open standards, they can run both in the cloud and on-prem. You can host your agent infrastructure in your own data center or a local cloud and still speak to the outside world via standard protocols. The protocol being open and neutral is a huge advantage here; it doesn't condemn you to a particular provider's geography.

Third: put human oversight at the center of the architecture. Especially at the start, having a human in the approval loop for critical decisions is essential. The human-in-the-loop approach is the healthiest way to build trust in agents step by step. The agent prepares the recommendation, the human approves; over time, as trust grows and audit records mature, you grant more autonomy. Rushed full autonomy is one of the most expensive mistakes I've seen in the field.

Fourth: connect the dots with the EU AI Act. Many institutions in Turkey serve Europe or work with European partners. The EU AI Act brings a risk-based approach and imposes obligations such as transparency, human oversight, and record-keeping for high-risk AI systems. The good news is that these obligations overlap substantially with solid agent governance. KVKK + EU AI Act + good agent architecture all point in the same direction: identity, authority, audit, human oversight. Do one right and you've already done most of the others.

Let me turn these principles into a concrete starting plan:

Phase	What to do	Typical duration
1. Discovery	Pick a low-risk, agent-suitable area from existing processes	2-4 weeks
2. Pilot	Connect tools via MCP in a single workflow, test in a controlled environment	4-8 weeks
3. Security hardening	Identity, authorization, audit trail; human approval loops	4-6 weeks
4. Multi-agent	Add a second agent to the orchestration via A2A	6-8 weeks
5. Production	Phased rollout, monitoring, feedback loop	Ongoing

This timeline will differ for every enterprise; my aim is not speed but to show the right order. Note that security hardening comes before the multi-agent step. Because if you can't even make a single agent secure, getting two agents to talk multiplies the risk not by two, but many times over.

This is the question I'm asked most often: "Where do we start?" My answer is always the same: not the flashiest place, but the safest. Your first agent project should be in an area where going wrong won't shake the company. Internal processes — an IT help desk, an HR Q&A assistant, a report-summarization flow — are perfect starting points. If you make mistakes there, customers don't see it, no money is lost, you just learn.

Leave customer-facing or money-moving agents for last. By the time they come, you'll have already built the muscle, stood up the audit infrastructure, and trained the team. Alipay's 120 million transactions didn't happen in a day; behind them are years of infrastructure, security, and trust-building. Don't rush; but don't stay paralyzed either.

Let me add one more thing: define your metrics from the very start. If you don't have a clear answer to "what must this pilot achieve to count as successful?", the pilot never ends. Never-ending pilots are the single biggest cause of the production gap. Set a concrete target: "resolve 30% of help desk tickets without human intervention, accurately," for example. You can't manage what you can't measure, and you can't put into production what you can't manage.

Do I need both MCP and A2A, or is one enough? It depends. If you only want to connect a single agent to your tools, MCP is enough. The moment you want multiple agents talking to each other, A2A comes into play. In most serious enterprise scenarios the two are used together: agents coordinate over A2A, each reaching out to tools over MCP.

Do these protocols create vendor lock-in? Quite the opposite. Both are open standards governed by independent foundations (the Linux Foundation). Their very purpose is to reduce vendor lock-in. The fact that you can run one agent on Azure and another on AWS and have them speak the same protocol is proof of that.

Is agents handing data to each other a problem under KVKK? A handoff is a data-processing activity, so it falls under KVKK. It's not a problem but it must be managed: purpose limitation, data minimization, disclosure, and consent where required. Build it into the design from the start and it's fine; try to add it later and it becomes a headache.

We're stuck and can't reach production. What's the most common cause? My observation in the field is that the problem is usually not technical but a matter of governance. The model works, but there's no organizational answer to "what happens if something goes wrong?" Stand up identity, authorization, audit trail, and human approval loops; that's usually where the wall gets crossed.

When should we move to fully autonomous agents? Don't rush. Start human-in-the-loop, let your audit records mature, let trust be proven with data. Increase autonomy gradually. The most expensive mistakes I've seen in the field come from full autonomy granted before trust was built.

So far I've described the protocols separately; now I want to pause and bring them to life together with a concrete scenario. Because theory is understood where it meets practice. Consider a claims-assessment process at an insurance company. A customer reports a claim. The first agent, the "intake agent," receives the request and collects photos and documents. This agent accesses the document management system over MCP — there's the vertical connection. Then the intake agent hands the assembled file to an "assessment agent" over A2A — there's the horizontal connection. The assessment agent checks the policy database, again over MCP, verifies coverage, then passes the task to a "payment agent" over A2A.

In this chain, every handoff and every tool access is logged. Each agent introduces itself with an Agent Card, gets authenticated, has its authority bounded. If the payment agent encounters an amount above its authority, it is automatically routed to a human approval loop. This is what a healthy agent architecture looks like: vertical and horizontal connections interwoven, but with identity, authority, and audit tightly stitched at every step. In this example you can see with the naked eye why the protocols are complementary; without MCP agents can't reach useful data, and without A2A they can't hand work to one another.

The beauty of this architecture is its modularity. If tomorrow you want to replace the assessment agent with a better model, you replace only that agent; as long as the Agent Card stays the same, the rest of the chain never even notices. That gives enterprises enormous flexibility. Instead of monolithic, fragile systems, you build an ecosystem of small agents, each doing its own job and speaking through standard interfaces. Remember the revolution microservices brought to software engineering; the agent economy carries a similar flexibility into the AI world.

I've seen this again and again in the field: standing up the technology is far easier than standing up the governance. Getting an agent running takes days; clarifying who is responsible for that agent's decisions, within what limits it acts, who oversees it can take months. But that second part is the key to actually reaching production.

Good agent governance must answer a few questions clearly. When an agent makes a harmful decision, where does responsibility lie — with the team that built it, the business unit that deployed it, the human in the approval loop? The answers vary from one organization to the next, but they must be settled in advance. Starting a debate about responsibility in the middle of a crisis is the worst possible timing. Standing up an agent committee or an AI governance board may seem excessive at the start, but it becomes priceless as you scale.

Policies also need to be living documents. Agent technology changes fast; a rule you write today may be obsolete in six months. Set up regular review cycles. Update your governance when a new protocol feature ships, when a new attack type is discovered, when a new regulation takes effect. A static policy quickly becomes meaningless against a dynamic technology.

Finally, I want to touch on something most technical articles skip: the human dimension. When agents start doing work, employees rightly ask, "is this going to replace me?" Ignoring that fear will sink even the best technical architecture. Because it's still humans who feed, oversee, correct, and improve the agents. If you treat your team as an adversary rather than a partner, the system gets quietly sabotaged or simply never adopted.

My advice is to position agents not as tools that "take work away" but as tools that "grow the work." A help desk agent doesn't put an employee out of a job; it frees them from boring, repetitive requests and steers them toward more complex, more valuable work. Delivering that message honestly, with concrete examples, doubles the pace of transformation. Transparency is critical here: tell employees clearly which processes will use agents and which decisions will remain with humans. Uncertainty grows fear; clarity grows trust.

Training is an inseparable part of this cultural transformation too. Your team needs to learn how to work with agents, how to oversee them, when to intervene. That skill will become a core competency of nearly every white-collar role in the coming years. Preparing your organization in that direction today is tomorrow's competitive advantage. I call it "agent literacy"; just as computer literacy became mandatory a generation ago, this will too.

As I wrap up, I want to leave you not with an abstract summary but with a thinking framework you can use the moment you sit down tomorrow. Agent interoperability has left the "might happen in the future" category; it's running in production, with real money, at real scale. The question isn't "will it happen?" but "are we ready?"

Ask your own organization these four questions. First: if our agents will one day talk to each other, how will we verify their identities and bound their authority? If you don't have an answer, that's the right place to start. Second: when an agent decision goes wrong, do we have an audit trail to go back and ask "what happened?" If not, it must be built before going to production. Third: which architectural choices do our KVKK and data residency constraints force on us — cloud, on-prem, or hybrid? Make that decision early, because changing it later is expensive. Fourth: which internal process will our first low-risk pilot be, and how will we measure its success?

The answers to these four questions are the bridge that carries you from the pilot trap to production reality. The protocols have matured, the foundations have provided trust, the pioneering institutions have opened the path. Now it's your turn to take the first step in your own organization — cautiously, but decisively. Don't wait for the perfect moment — that moment is the one in which you start in the right order. Discovery first, then a small pilot, then security hardening, and only then getting agents to talk to each other. Organizations that hold to this order will be among the winners of this transformation next year. Those that skip the order will, sadly, join the 79% stuck in the production gap. The choice — or rather, the discipline — is in your hands.