DEV Community: Kartik Buttan

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

Kartik Buttan — Thu, 16 Jul 2026 14:02:10 +0000

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:

"What am I allowed to do?"

Always happy to connect with builders working on AI systems, retrieval pipelines, and knowledge infrastructure.

💼 LinkedIn: https://www.linkedin.com/in/kartikbuttan
💻 GitHub: https://github.com/kartik1112
🌐 Portfolio: https://kartik1112.github.io

Google's OKF Might Quietly Break the Entire RAG Stack

Kartik Buttan — Tue, 30 Jun 2026 15:00:00 +0000

We didn’t build bad AI systems.

We just gave them broken maps of knowledge.

Everyone is building AI agents right now.

The demos are insane:

“Book my meetings.”
“Analyze my revenue.”
“Find the root cause.”

Then you deploy it in a real company...

…and it starts hallucinating confidence on top of uncertainty.

Not because the model is bad.

But because retrieval is fundamentally broken.

⚡ TL;DR

RAG today:

Finds what looks similar

OKF:

Connects what actually relates

That difference changes everything.

The Real Problem

Ask:

“How is Monthly Active Revenue calculated?”

You get:

dashboard docs
onboarding guides
outdated Confluence pages
random SQL files

Nothing is technically wrong.

But nothing is truly right either.

Because retrieval is based on:

semantic similarity, not meaning

RAG in One Diagram

Question
  ↓
Embedding
  ↓
Vector Search
  ↓
Top-K Chunks
  ↓
LLM Answer

Simple.

But dangerously incomplete.

Because:

The system never understands relationships.

Only proximity in vector space.

The Chunking Trap

Take this:

Revenue = Payments - Refunds

Now break it:

Chunk 1 → Formula
Chunk 2 → Refund rules
Chunk 3 → Exceptions

Now the system must reassemble truth from fragments.

Sometimes it works.

Sometimes it fails silently.

So we patch it:

more overlap
more retrieval
more reranking
more agents
more compute

We didn’t fix retrieval.

We just made it more expensive.

The Hidden Cost

When retrieval is probabilistic…

we compensate with infrastructure.

Query
 → Vector Search
 → BM25
 → Hybrid Search
 → Query Rewrite
 → Reranker
 → Reranker v2
 → LLM

It works.

But it feels like overengineering a missing concept:

structure

Enter OKF

Instead of asking:

“What looks similar?”

It asks:

“What is actually connected?”

That changes the entire model.

Think Wikipedia, Not Search

Wikipedia isn’t useful because of articles.

It’s useful because of links.

Newton
 → Calculus
 → Leibniz
 → Differential Equations

You don’t retrieve knowledge.

You navigate it.

Documents vs Knowledge Graph

Old world:

Revenue.pdf
Orders.pdf
Refunds.pdf

New world:

Revenue
 ├─ depends on Orders
 ├─ subtracts Refunds
 ├─ owned by Finance
 └─ drives Dashboard

No guessing.

No inference.

Just structure.

Real Example

Question:

“Why did revenue drop yesterday?”

RAG:

logs
dashboards
docs
incidents

Then the LLM guesses causality.

OKF-style structure:

Revenue
 → Payment Service
 → Failed Transactions
 → Deployment Change
 → Incident Report

Now the system doesn’t guess.

It traverses.

Is This Just a Graph Database?

No.

But they’re related.

Graph databases like Neo4j, Amazon Neptune, and TigerGraph store and query relationships efficiently.

But OKF is different.

Graph DB vs OKF

Graph database:

“How do I store relationships?”

OKF:

“How do I define relationships so any system can understand them?”

One is infrastructure.

The other is a knowledge standard.

Think:

HTML → structure
Browser → renderer
Graph DB → storage

OKF sits at the structure layer.

Why This Matters

Enterprise knowledge today is fragmented:

docs
code
APIs
dashboards
spreadsheets

We force AI to unify it using probability.

But probability breaks when structure is missing.

The Real Bottleneck

It’s not model size.

It’s not context windows.

It’s not agents.

It’s this:

We never taught our systems how knowledge connects.

Final Thought

We’ve spent years upgrading intelligence.

Maybe the next leap is upgrading structure.

Because even the smartest model in the world can’t follow connections that were never written down.

If AI is the brain...

Then OKF might become the nervous system.

And that changes everything.

Always happy to connect with builders working on AI systems, retrieval pipelines, and knowledge infrastructure.

💼 LinkedIn: https://www.linkedin.com/in/kartikbuttan
💻 GitHub: https://github.com/kartik1112
🌐 Portfolio: https://kartik1112.github.io