API vs RAG vs MCP vs A2A: The Four-Layer AI Agent Stack Explained

01The Foundation: Why APIs Are Not Enough

An API is a contract between two programs. It defines what you can request, how that request must be formatted, and what comes back. If you send the expected input to the expected endpoint, you get a predictable response. That predictability is the whole point. Much of the modern internet runs on APIs: a weather app asks for a forecast, an online store processes a payment, a messaging service sends a notification.

Traditional software handles these tasks reliably because the developer plans the sequence in advance. Then we placed a large language model inside that carefully scripted system. The input was no longer a neat form. Someone might say, Find me a good flight, avoid overnight layovers, and make sure I do not miss Monday's meeting. Now the system has to understand the request, check several services, ask follow-up questions, and adjust its plan.

The model may understand the goal, but the API still needs exact instructions: which endpoint to call, which fields and data types to send, which credentials to use, and what to do when something goes wrong. It is like giving a talented new employee a room full of control panels with no labels. Intelligence does not automatically create an interface.

Our first workaround was brute force. We describe every function to the model: when the user asks for flights, call this function, provide these fields, and expect this shape back. That works at small scale, but add ten tools and the instructions swell. Whenever you change a schema, something can fail silently. We were attaching a flexible reasoning layer to a collection of rigid integrations, one custom connector at a time.

02Wall One: Knowledge Without Facts (RAG)

To see where each protocol fits, we follow a fictional AI agent named Atlas, a personal travel assistant. You tell Atlas, Plan my trip to Tokyo in March. Atlas should understand your preferences, check your schedule, find flights and hotels, request approval when necessary, and help you complete the booking.

Atlas is powered by a large language model. The model may know a lot about Tokyo — the neighborhoods, food, train lines, and usual travel advice — but it does not know your passport is going to expire in April, or that you have airline points, or that your company caps reimbursable flights at $800. These facts are private, specific to you, and likely to change. They were never part of the model's training data. When a model can sound confident even when it does not know the answer, it fills the gap with something plausible but false. That is a hallucination.

Why not fine-tune the model on your data? Fine-tuning can teach behavior, tone, and repeated workflows, but it is not a reliable database for facts that change often. When you renew a passport or spend some points, the model's stored knowledge becomes outdated. The smarter move: do not force the model to memorize changing facts. Let the application retrieve the relevant facts when they are needed.

That is RAG — Retrieval Augmented Generation. Think of it as an open-book answer. The model still reasons, but first it receives a small evidence packet containing the information most relevant to the current question.

The basic pipeline works as follows. You ingest documents such as travel policies, preferences, and trip notes. You split them into useful chunks and index them — using keyword search, semantic embeddings, or a hybrid of both. When a request arrives, the system applies the user's permissions, retrieves the strongest matches, and places those passages in the model's context before generation begins. Atlas is not remembering your passport record. It is reading an authorized copy at the moment it needs it.

That makes the answer fresher and easier to verify. This is why RAG appears in document assistants, support bots, enterprise search tools, and coding products. RAG is a system pattern that retrieves useful evidence, then generates with that evidence in context.

But RAG has a critical limitation. It gives Atlas context, but not capability or authority. It can tell Atlas what a policy says, but it does not let Atlas change a booking or approve a payment. A document index does not check a live fare, place a hold, or update your calendar. Retrieval answers what Atlas needs to know, but it does not answer what Atlas can do. Knowledge without action. That is Atlas's second wall.

03Wall Two: Tools Without Standards (MCP)

The obvious next step is to connect Atlas to a flight API, a calendar API, and an email API. Function calling gives Atlas a structured way to request an action. It proposes a function call along with parameters like origin, destination, and travel dates. The host checks the request, runs the code, and sends the result back. This repeating loop — model requests, host checks, tool performs, result returns — is the basic engine behind most useful AI agents.

But function calling is not a magic connect button. For every service, a developer still has to do setup: read the API documentation, match its data format, and decide what the model is allowed to see and do. Then repeat for hotels, calendars, email, payments, and internal databases. Other teams build their own versions of the same connectors. The result is a growing pile of custom code that holds everything together. Whenever a service changes its data format, a developer has to update and maintain that code.

This is where MCP — the Model Context Protocol — enters the story. Anthropic introduced it in November 2024 as an open standard so different companies could use the same approach. Since then, many AI products and developer tools have adopted it. The popular shorthand is USB-C for AI applications. That analogy is useful as long as we understand what it does and does not promise. USB-C gives devices a common way to communicate about a connection, but using a USB-C accessory does not automatically mean it is safe, approved, or compatible with every feature. MCP standardizes how an AI application talks to an outside tool, but you still need login checks, permissions, data validation, and the application's own rules.

A calendar service running an MCP server can advertise a tool named find open time, explain what it does, and publish a machine-readable input schema. A flight service can offer search fares and hold itinerary the same way. Because both services use MCP, every AI application receives the tool descriptions and input requirements in the same format. Developers do not need to create a different connection format for every service.

On the other side, the application running Atlas is the MCP host. It connects to each MCP server through its own MCP client. When a connection starts, the client and server introduce themselves and agree on what each one supports. The client asks the server which tools are available, gives the model the relevant tool descriptions, and when the model suggests using a tool, the client checks the request and sends it to the correct server. Under the hood, these messages use an updated version of JSON-RPC. Local servers communicate through standard input and output; remote servers use streamable HTTP.

04Wall Three: Agents Without Coordination (A2A)

Atlas can now retrieve information and use tools. But in a real organization, Atlas soon runs into a third wall. The challenge is no longer accessing a tool. Atlas has to coordinate work with another independent system, one with its own rules and responsibilities. The more options we give it, the more likely it is to choose the wrong tool, keep track of too much information, or fail in unexpected ways.

Real organizations do not give one employee every responsibility. They use specialists, where each specialist owns a smaller task and hands work to the others. Agent systems can use the same pattern. Atlas can handle travel, while finance and airline agents handle their own areas. This separates responsibilities and permissions, but it also adds coordination challenges and security risks.

Agent-to-agent communication, or A2A, becomes useful when the agents belong to different teams or companies and need a shared way to work together. Google introduced A2A in April 2025 with support from many technology companies. Its goal: help independent AI agents work together, even when different teams or companies build them using different technologies.

One important part of A2A is the agent card. It is a machine-readable information sheet that tells other systems how to work with an agent: the agent's name, where to contact it, what it can do, which data formats it accepts and returns, and how users must sign in. Think of it as a service card, not a social profile. It tells you what the agent claims it can do, but it does not prove the agent is safe or trustworthy. That distinction matters. Atlas should find the finance agent only through a trusted source — the company's official domain, a direct setup, or an approved directory. Then Atlas proves its identity using the required sign-in method. Finally, the finance service decides what Atlas is allowed to do.

Once connected, Atlas can ask the finance agent to approve a specific travel plan. If the review takes time, the finance agent can create a task, share updates such as submitted or in progress, ask for missing information, and return a final approval record.

05The Full Journey: Four Layers in Action

Here is how all four pieces work together when you say, Atlas, book my Tokyo trip for the second week of March.

Step 1 — RAG (Facts): Atlas retrieves only what it needs: your preferences, company policy, points balance, and passport expiry date — not your full passport scan. If something looks risky, Atlas flags it instead of guessing.

Step 2 — MCP (Tools): Atlas checks your calendar and searches live fares through MCP-connected servers. The host approves each tool, validates every request, and logs every action. Atlas finds a suitable flight and places it on hold.

Step 3 — A2A (Coordination): The fare exceeds your company's limit, so Atlas sends only the itinerary and price to the finance agent through A2A. Finance returns an approval tied to that exact trip, amount, and expiry time.

Step 4 — Human confirmation: Atlas still does not buy. It rechecks the price, shows you the final amounts, and waits for your confirmation. When you say yes, Atlas books without risking a duplicate purchase. It saves the receipt, updates your calendar, and sends the itinerary.

One request, four clear roles. API provides the contract. RAG provides the knowledge. MCP provides the tools. A2A provides the coordination. Each layer solves the wall the previous one hit.

06Why This Matters for Builders

Understanding where each protocol stops and the next begins is not academic. It determines architecture decisions, security boundaries, and team responsibilities. If you build an agent and give it tools without RAG, it will hallucinate facts. If you give it knowledge without MCP, it will know what to do but cannot act. If you give it tools without A2A, it will work in isolation when real workflows require multiple specialists.

The adoption curve tells the story. MCP, introduced in November 2024, has been adopted by major AI development tools including Claude Code, Cursor, and VS Code extensions. A2A, introduced in April 2025, has support from Google and a broad coalition of technology companies. RAG has become the default pattern for enterprise AI applications — nearly every document assistant, support bot, and coding assistant uses some form of retrieval-augmented generation.

The stack is maturing. The question for builders is no longer whether to use these protocols, but how to layer them correctly — and where to draw the boundaries between knowledge, tools, and coordination.