Kartik Buttan

Posted on Jul 16

A2A + MCP + Identity: Stop Comparing Them. You're Looking at Different Layers of the Stack

#ai #backend #softwareengineering #architecture

Everyone seems to be asking the same question these days.

"Should I use MCP or A2A?"

Every time I hear that, it feels like someone asking, "Should I use HTTP or PostgreSQL?"

The question itself doesn't make sense. One is about communication. The other is about capabilities. They're solving completely different problems.

And yet, somehow, we've managed to turn them into rivals. I think we're missing the bigger picture.

The Agent Gold Rush

We have officially entered the "agent era."

Every framework now claims to build autonomous agents. Every cloud provider has an agent SDK. Every conference has at least three talks about multi-agent systems.

But if you zoom out, most of these conversations revolve around two protocols:

Model Context Protocol (MCP)
Agent-to-Agent (A2A)

The internet quickly turned this into another technology battle. MCP vs A2A. Google vs Anthropic. Choose your side.

Except... there isn't a side to choose.

Before We Talk About Protocols...

Let's answer a more important question: what is an agent?

Strip away all the marketing. An agent is surprisingly simple.

It has a brain.
It knows how to think.
It knows how to communicate.
It knows how to act.

That's it.

The LLM gives it reasoning. Prompts shape its behaviour. Memory gives it continuity. Planning gives it direction. Tools let it interact with the real world. Communication lets it collaborate.

Everything else is implementation details.

Every Agent Has Three Jobs

I like reducing systems to the smallest possible abstraction.

Every agent, no matter how sophisticated, only does three things:

It thinks.
It talks.
It acts.

Thinking is internal. Talking is between agents. Acting is interacting with external systems.

Interestingly, A2A and MCP map perfectly onto these responsibilities.

Thinking happens inside the agent.
Talking happens through A2A.
Acting happens through MCP.

Notice something? There isn't any overlap.

MCP Isn't Your Agent

One misconception I keep seeing is treating MCP as if it's some kind of intelligent orchestrator.

It isn't.

MCP doesn't plan. It doesn't reason. It doesn't decide. It simply exposes capabilities in a standard way.

Imagine hiring a chef. The chef decides the recipe. The kitchen doesn't. The kitchen simply contains ovens, knives, ingredients and utensils.

That's MCP. It's the kitchen. Not the chef.

Without the chef, nothing gets cooked. Without the kitchen, the chef can't cook. Both are necessary. Neither replaces the other.

A2A Isn't About Tools

Now imagine running a restaurant. One chef isn't enough. You have pastry chefs, sous chefs, line cooks, servers, expeditors. Each has a specialized responsibility. But they constantly communicate.

"Table seven is ready."
"I need dessert."
"Fire two steaks."

That's A2A. It's not about accessing GitHub. It's not about databases. It's about coordinating work between specialists.

A planner agent delegates. A retrieval agent searches. An ingestion agent collects data. A reporting agent prepares the final response.

Each does one thing well. Together they solve much bigger problems.

So Where Does Authentication Fit?

This is where I think most architecture diagrams stop too early. They usually end here:

Agent
  │
 MCP
  │
Tools

Looks neat. Unfortunately, that's not how production systems work.

The missing piece is identity.

Without identity, your agent has no authority. Without authority, every tool call becomes a security nightmare.

A production architecture actually looks closer to this:

Identity isn't an implementation detail. It's a first-class architectural layer.

Should Agents Carry User Tokens?

My first instinct was yes. The user authenticates. The agent simply forwards the access token. Done.

The more I thought about it, the less I liked it.

Imagine asking an agent: "Summarize my backend repository."

Should that worker agent suddenly inherit every permission you have? Probably not.

Instead, imagine issuing a new credential. Not a user credential. A task credential. Something that says:

"DataIngestionAgent may read this repository, for this task, during the next 15 minutes. Nothing more. Nothing less."

Now we've moved from identity propagation to delegated authority. That small distinction changes everything.

Authorization Doesn't Belong Inside the Agent

This is another subtle design decision.

Suppose the ingestion agent decides it needs GitHub. Should the agent itself verify permissions?

I don't think so.

The agent's responsibility is deciding what needs to happen. The MCP's responsibility is deciding whether it's allowed. That separation keeps intelligence separate from security.

The agent says: "Fetch backend repository."

The MCP checks:

Is this token valid?
Has it expired?
Is this repository allowed?
Does this task have repo.read permission?

Only then is the request forwarded.

The agent never needs to understand OAuth, RBAC, policy engines, or permission inheritance. Its only job is solving the problem.

Why Not Give Every Agent Direct Tool Access?

You could. For a toy application, it works perfectly.

Then your second agent appears. Now both agents need GitHub. Then Slack. Then Gmail. Then S3. Then PostgreSQL.

Soon every single agent contains:

authentication logic
retries
caching
SDKs
rate limiting
permission checks

Congratulations. You've just duplicated your infrastructure ten times.

A shared MCP layer eliminates that duplication: one integration, many agents, consistent behaviour, centralized policies. Much cleaner.

Putting Everything Together

Once you zoom out, the architecture becomes surprisingly elegant.

Every layer has exactly one responsibility.

Identity answers: Who is allowed to perform this work?
A2A answers: Who should perform this work?
MCP answers: How do we safely access the capabilities required to perform this work?

When each layer focuses on one responsibility, the architecture becomes both simpler and more secure.

Final Thoughts

I don't think the future belongs to a single "super agent."

It belongs to teams of specialized agents collaborating through standard protocols. Those agents won't have hardcoded integrations. They'll rely on shared capability layers. And they won't blindly inherit user credentials — they'll operate with delegated, task-scoped authority.

That's why I no longer think about A2A or MCP in isolation. They're simply two layers of the same stack.

The third layer — the one that quietly holds everything together — is identity.

Because before an agent can think... before it can collaborate... before it can call a tool... it first has to answer the most important question of all: