This content originally appeared on Level Up Coding – Medium and was authored by Ahmed Ibrahim
I’ve spent years thinking in layers, networks, subnets, firewalls, storage, and workloads. Things you could trace, measure, or at least restart at 3 AM and hope for the best. Then came AI, and suddenly everyone was talking about models, context windows, and agents.
It felt like walking into a data center where every rack had been replaced by something invisible and no one could tell me where the traffic was going.
So, like many of you, I started trying to make sense of it. And in my experience, the best way to learn something is to try to explain it. Writing forces clarity. If I can explain it, I probably understand it, or at least, I will by the end of this series.
That’s how this article started. I wanted to understand how AI systems actually work underneath all the hype. And I found myself reaching for something familiar: the OSI model.
Finding Layers in the Chaos
The OSI model has been around for decades. It gave us a common language for networks, a standard way to describe what happens from the physical cable all the way to the application data.
AI systems don’t have that yet. They’re still an evolving mix of tools, APIs, and models that somehow cooperate to sound intelligent. But thinking in layers still helps.
For AI systems, I’ve been using this mental model to make sense of things (not an official standard, just a way I’ve found helpful for thinking through problems):
- Infrastructure Layer — Physical compute, GPUs, servers, networking
- Model Layer — The AI models themselves (GPT-4, Claude, etc.)
- Protocol Layer — How components communicate (MCP for tools, A2A for agents)
- Application Layer — Your application logic and orchestration
- Interface Layer — What users interact with
This isn’t the OSI model, and it’s not an industry standard. It’s a framework I’m using to organize my thinking as I learn these protocols. Will it help with debugging? That’s the theory, but I haven’t put it to a real test yet. For now, having some structure (even an imperfect one) beats treating everything as a black box.
At the bottom, we still have infrastructure: compute, storage, and networking. Then we have the models doing the thinking. Above that are the protocols that let models use tools (MCP) and agents talk to each other (A2A). And at the top is your application logic and user interface.
That’s where MCP and A2A live, in that protocol layer.
They’re not decades-old, committee-blessed standards like OSI. They’re newer open standards, the kind that evolve fast and have backing from companies like Google, Microsoft, OpenAI, and IBM. Think of them more like HTTP or OAuth: practical protocols that become standards through adoption rather than committee decree. And right now, they’re the closest things we have to a common language for how AI systems actually talk to tools, data, and each other.
A Note on Timing
Before we dive deeper, it’s worth noting how recent all of this is. Anthropic released MCP in November 2024. OpenAI officially adopted it in March 2025. Google announced A2A in April 2025, and by June it was already a Linux Foundation project with over 100 companies backing it.
We’re watching the foundation of AI infrastructure being laid in real-time. These aren’t battle-tested protocols with decades of refinement, they’re emerging standards that could shape how AI systems work for years to come. That makes understanding them now even more valuable.
The OSI Disclaimer
Another quick note before we go further: AI protocols don’t map perfectly to the OSI model. The OSI model was designed for networks, where data flows in predictable ways through well-defined layers. AI systems are messier, they’re about intelligence, context, and decision-making, not just data transport.
But the thinking still helps. When you’re troubleshooting why your AI system isn’t working, asking “which layer is failing?” is just as useful as it was with networks. So bear with me while I stretch the analogy if it helps us to understand more.
What is MCP (Model Context Protocol)?
MCP stands for Model Context Protocol. It’s an open protocol created by Anthropic (the company behind Claude) and adopted by others, including Microsoft and OpenAI, to define how models connect to tools and data sources.
You can think of MCP as a translator that sits between an AI model and the real world. It defines how the model can access tools like a database, a calendar, or a filesystem, and how those interactions are formatted and logged.
Let’s say you’re building a chatbot that can read files from a shared folder.
Without MCP, you’d probably just give it a custom API endpoint or a Python function and hope for the best. With MCP, you define a connector that follows a standard contract. The model doesn’t just “call random code”; it sends a structured request, like “list available files” or “read file X”, through a controlled channel.
Instead of just calling readFile('secrets.txt') and crossing your fingers, the model sends a structured MCP request that looks something like: {action: 'read_resource', resource_id: 'file://shared/report.pdf', permissions: 'read-only'}. The exact schema varies by implementation, but you get the idea: structured, validated, and enforceable.
The Three Primitives
Under the hood, MCP defines three core primitives that make this work:
- Resources: Data that models can read (like files, database records, or API responses)
- Tools: Actions that models can execute (like “send email” or “create file”)
- Prompts: Pre-built templates that MCP servers can expose for common tasks
In practice, this looks like:
Resources: “Give the model read access to our customer database”
# The model can then query:
resource = mcp.get_resource("database://customers/table")
Tools: “Allow the model to restart a failed service”
# The model can call:
result = mcp.call_tool("restart_service", {"service": "api-gateway"})
Prompts: “Provide a template for analyzing error logs”
# The model can use a pre-defined prompt:
analysis = mcp.use_prompt("analyze_error_logs", {"log_file": "errors.log"})
The beauty is that once you’ve defined these through MCP, any MCP-compatible model can use them. You’re not locked into one vendor’s custom integration format. It’s like SNMP for AI tools: one protocol, every vendor has to speak it, and suddenly your monitoring actually works.
This structured approach means:
- You can authenticate the connector, using normal credentials or tokens.
- You can log every call and enforce permissions (read-only, write, delete).
- You can control context, what the model is allowed to see and remember.
Where MCP Fits
So where does MCP fit in terms of protocols?
If we loosely map it to the OSI model, MCP would live around the application layer, sitting above the transport protocol (usually HTTP or WebSocket). It doesn’t move bytes over the network like HTTP or SMTP; instead, it defines a semantic layer that tells the model what actions exist, how to call them, and what rules apply.
In other words, HTTP delivers the request. MCP explains what the request means. It’s the contract layer between the model and its tools responsible for structure, permissions, and safety, not routing packets.
MCP gives structure to how AI connects with the world. But it doesn’t decide what the model should do, that’s where A2A comes in.
What is A2A (Agent2Agent)?
A2A, short for Agent2Agent, is an open protocol that defines how different AI agents collaborate. It was announced by Google in April 2025 and became an official Linux Foundation project just two months later, with backing from major players like Google, Microsoft, IBM, and over 100 other companies.
While MCP standardized how agents talk to tools, A2A standardizes how agents talk to each other.
Imagine you have three agents in a system:
- A planner agent that breaks down a task.
- A researcher agent that finds information.
- A writer agent that generates the final text.
A2A is the communication layer that allows these agents to exchange structured messages and results, like “Here are the search results” or “Now summarize this.”
Making It Concrete
Let’s make this real. Say you’re on-call and you ask your AI system: “Investigate why the production API is slow and create an incident report.”
Without A2A, you’d manually check logs, metrics, and traces yourself, then write the report.
With A2A, here’s what happens:
The coordinator agent receives your request and breaks it into subtasks:
- [1. Check error logs, 2. Analyze metrics, 3. Query traces, 4. Generate incident report]
It sends a structured A2A message to the logs agent:
{
"task": "analyze_errors",
"service": "production-api",
"timeframe": "last_30_min"
}The logs agent responds with structured data:
{
"results": {
"error_rate": "15%",
"top_error": "DatabaseConnectionTimeout",
"affected_endpoints": ["/api/users", "/api/orders"]
}
}The coordinator then sends that data to the metrics agent:
{
"task": "correlate_metrics",
"errors": ["DatabaseConnectionTimeout"],
"timeframe": "last_30_min"
}The metrics agent responds:
{
"results": {
"db_connections": "maxed out at 100",
"cpu_usage": "85%",
"likely_cause": "connection pool exhaustion"
}
}Finally, the coordinator sends everything to the report agent to generate a markdown incident report.
Each agent stays focused on what it does best: logs analysis, metrics correlation, or report generation. They speak a common language that both sides understand.
If MCP defines how a model talks to tools, A2A defines how multiple intelligent components talk to each other.
Where A2A Fits
In our layer model, A2A sits in the Protocol Layer alongside MCP, but at a higher level of abstraction. While MCP is about “how do I use this tool,” A2A is about “how do we coordinate to solve this problem.”
A2A systems can use MCP underneath to talk to data sources, or they can communicate through APIs, message queues, or shared memory. The key idea is that there’s a standardized language between agents, so they can cooperate instead of just chaining prompts.
Quick Reference
Here’s how they compare:
MCP (Model Context Protocol):
- Purpose: Connect models to tools and data
- Analogy: Model’s “hands and eyes”
- Example: “Read this file” or “Query this database”
- Protocol Level: Application layer (Layer 7)
- Security Focus: Tool permissions, data access
A2A (Agent2Agent):
- Purpose: Connect agents to each other
- Analogy: Agents’ “conversation”
- Example: “I found the data, now you analyze it”
- Protocol Level: Coordination layer (above application)
- Security Focus: Agent identity, task authorization
Seeing the Layers in Action
Now that we’ve defined our layer model, let’s see how they work together.
Think about what happens when you ask an AI assistant: “Check if any of our production services are down and notify the team.”
Interface Layer (You):
- You type the request into a terminal or chat interface
Application Layer (Orchestration):
- Your application receives the message
- Routes it to the coordinator agent
Protocol Layer — A2A (Agent Coordination):
- Coordinator agent decides: “I need the monitoring agent”
- Sends A2A message: {"to": "monitoring_agent", "task": "check_service_health"}
Protocol Layer — MCP (Tool Access):
- Monitoring agent uses MCP to call: check_health_status(service="all")
- MCP validates: “Does this agent have permission to query health status?”
- Tool is invoked through standardized protocol
Model Layer (AI Processing):
- GPT-4 or Claude processes the health data
- Decides which services are critical
- Formats the notification message
Infrastructure Layer (Physical Work):
- API calls to your monitoring system
- Database queries for service metadata
- Network requests to send Slack notification
- All over standard networking (TCP/IP)
The point: Each layer has a specific job. When debugging, you can ask “which layer failed?” Just like with networks, this layered thinking helps you isolate problems. The logs tell you if it’s an A2A coordination issue, an MCP permission problem, a model decision error, or an infrastructure failure.
Security, Authentication, and Resource Control
When you give an AI model the ability to act (to access files, call APIs, or delegate tasks) security becomes critical. Let me show you what can go wrong, and how MCP and A2A address it.
What Can Go Wrong
MCP Security Risk: Imagine you give an AI assistant access to your infrastructure through a poorly configured MCP connector. Without proper authorization, a prompt like “show me all configuration files” could expose secrets like API keys or database passwords. Worse, if write permissions aren’t restricted, a malicious prompt could modify firewall rules or delete production data.
A2A Security Risk: Picture an A2A system where a “deployment agent” can push code to production. If there’s no proper authentication between agents, a compromised “code-review agent” could approve malicious code, triggering an unauthorized production deployment. Or a “monitoring agent” could be tricked into sending false alerts, causing unnecessary emergency responses.
Both scenarios are prevented by the same security principles, applied at different layers.
MCP Security Model
MCP provides the framework for addressing these risks through three
mechanisms you should implement:
Authentication: Every MCP connector requires its own credentials. The model itself never holds secrets directly. Instead, the runtime environment provides scoped access (like Azure Managed Identity or temporary tokens).
Authorization: Each MCP tool defines what operations are allowed. Can this model read files? Write? Delete? Execute commands? Those policies live in the MCP server configuration, not in the model.
Audit: Every MCP tool call can be logged with the tool name, parameters, caller identity, and timestamp, though you’ll want to balance completeness with logging costs. This is your packet capture for AI systems.
A2A Security Model
A2A works similarly, providing the structure for security without enforcing it. Implementation is up to you as the engineer.
Authentication: Each agent has an identity. When Agent A sends a message to Agent B, B can verify it’s really from A, not a spoofed message.
Authorization: Agents operate under different permission scopes. The “read-only monitoring agent” can’t trigger the “deployment agent.” The system enforces this at the A2A protocol level.
Audit: Every A2A message is logged: who sent it, who received it, what task was requested, and what was the result. If an agent starts misbehaving, you can trace the entire conversation chain.
Cost as a Security Boundary
There’s one more dimension: cost. Every model call, every token processed, every agent message has a price. If you don’t limit context size or message frequency, you’ll burn through your budget before you can say “debug logs.”
But cost isn’t just about money. It’s also about preventing abuse. Rate limiting and token budgets are security controls as much as they are financial ones. An attacker who gains access to your AI system will try to rack up huge bills by making endless API calls.
Both security and cost are solved by the same thing: visibility. The moment you can trace which layer the activity belongs to (whether it’s MCP tool calls or A2A messages) you can start controlling it.
Learning Out Loud
I’m not writing this because I have all the answers. I’m writing this because teaching is how I learn.
The act of breaking things down, comparing them to what we already know, is how I build my own understanding.
MCP and A2A aren’t perfect or final, but they’re promising open standards that are making AI systems more predictable and secure. They give us mental handles, layers we can observe, audit, and refine as the ecosystem matures.
In the next article, I’ll take this exploration further. I’ll build a minimal demo using MCP connectors and A2A messages to watch how requests move across layers and where the cracks appear. We’ll look at what can go wrong, and what security measures actually help when the theory hits reality.
If AI is going to be everywhere, we might as well understand what’s moving inside it, and make sure it’s both smart and safe.
If you found this helpful, follow me for Part 2 where I’ll build a working demo of MCP and A2A in action. We’ll see what breaks and how to debug it.
Questions? Thoughts? Drop them in the comments. I’m learning this alongside you.
An Infrastructure Engineer’s Guide to MCP and A2A was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.
This content originally appeared on Level Up Coding – Medium and was authored by Ahmed Ibrahim