RAG pre-retrieves information before the model sees the question. Agents and MCP go further: the model itself decides what it needs, requests it from live systems, reads the response, and continues. The model stops being a reader and starts being an actor.
In a RAG system, a separate retrieval process decides what information to put in front of the model. The model plays no role in that decision — it just receives the context that was assembled for it and works from there.
In an agent system, the model participates in the retrieval process itself. It reads your question, reasons about what information it needs, requests that information from a connected tool or data source, reads what comes back, and then either answers or decides it needs something else. The model is in the loop — not just at the end, but throughout.
Think of the difference this way: RAG is like a researcher who pre-reads a stack of documents before you arrive for a meeting. Agents are like a researcher who reads your question live, decides which filing cabinet to check, opens it, reads what's relevant, and then gives you an answer — possibly checking a second cabinet if the first one wasn't enough.
RAG requires someone to anticipate what information might be relevant before the question is asked. Agents don't — they figure out what they need in response to the specific question. For dynamic, unpredictable queries, agents are more flexible. For well-defined, high-volume query patterns, RAG is simpler and more predictable.
An agent's reach is defined by the tools it has been given access to. A tool is simply a capability the model can invoke — a function it can call, a system it can query, an action it can take. The model doesn't execute the tool directly; it generates a structured request describing what it wants, and the surrounding system executes it and returns the result.
Common tools include:
The model decides which tool to use based on the question, invokes it, receives the output in its context window, and incorporates that information into its response — exactly as if you had pasted the information there yourself. From the model's perspective, it's still just reading context. The architecture around it is what made that context dynamic and live.
As agents have proliferated, a practical problem emerged: every AI system was connecting to tools in its own proprietary way. If you wanted Claude to access your calendar and your database and your internal wiki, you'd need to build three separate custom integrations, each in a different format.
MCP — Model Context Protocol — is an open standard that solves this. It defines a common language for how AI models and tools talk to each other. If your calendar system speaks MCP, any MCP-compatible AI can connect to it. If your database speaks MCP, any MCP-compatible AI can query it. Build the integration once; use it with any model that supports the standard.
The analogy is USB. Before USB, every peripheral had its own connector — printers, keyboards, cameras all used different plugs. USB standardized the connection so any device could work with any peripheral. MCP is trying to do the same thing for AI and data sources.
When you connect Claude to your Google Calendar or Gmail through an integration, that connection is likely using something like MCP under the hood — a standardized channel through which the model can request information ("what's on my calendar Thursday?") and receive structured responses ("you have three meetings: 9 AM standup, 11 AM client call, 2 PM 1:1"). The model reads those responses as context and incorporates them naturally into its reply.
When an agent handles a complex request, it doesn't do it in one pass. It runs through a loop:
A request like "check if our API latency has been above threshold this week and if so draft a summary for the team" might involve querying a monitoring system, reading latency metrics, comparing against threshold, and then drafting a message — all as separate tool invocations in a single agent loop. The model orchestrates the sequence. The tools provide the live data. The result lands in your inbox or Slack or wherever the final tool deposits it.
RAG makes the model better informed. Agents make it capable of action. The model moves from "reads documents and answers" to "reads context, queries systems, synthesizes results, and acts." The underlying token-prediction mechanism is unchanged. What changes is the richness and liveness of what flows through the context window — and what the model is allowed to do with its outputs.
None of this makes the model smarter in a fundamental sense. It's still predicting the next token. It still has no understanding of truth versus plausibility. It can still hallucinate — now potentially in the content of tool calls, not just in the final response.
Agents add capability and flexibility. They also add complexity and new failure modes. A hallucinated tool call can have real consequences if the tool on the other end executes it. The model deciding which tool to invoke and what parameters to pass is still probabilistic reasoning — usually correct, occasionally wrong, rarely aware of its own uncertainty.
Understanding this helps you think clearly about where to deploy agents and where simpler approaches are safer. Not every question needs an agent. Sometimes the right answer is a well-crafted prompt with good context. The tool should match the problem.