---
title: 'MCP vs RAG vs agents: three acronyms, one system'
excerpt: 'MCP, RAG, and agents answer three different questions: knowledge in, actions out, control flow. A map of how production systems compose them, with receipts.'
date: '2026-06-17'
lastModified: '2026-07-04'
author: 'Teo Deleanu'
authorAvatar: '/team/teo.jpg'
tags: ['Production AI', 'AI Engineering', 'Architecture', 'Agents']
keywords: ['MCP vs RAG vs agents', 'AI system architecture', 'agent control flow', 'RAG and tool composition']
featured: false
tldr: 'ByteByteGo EP202 poses MCP, RAG, and agents as competing options, and the framing is a category error: RAG decides how knowledge gets into context, MCP decides how actions get out, and an agent decides the control flow in between. A production system typically composes all three, and confusing the layers produces documented debt: bigger models shipped for retrieval failures, 850 raw tool definitions taxing every turn, and manager loops that negotiate instead of answering. The doc-intel demo on this site runs RAG alone with control flow fixed in code, while the IoT analytics platform composes the agent loop, the tool catalog, and skill-fed knowledge. This post is the map; three earlier deep dives carry the numbers.'
keyTakeaways:
  - 'RAG, MCP, and agents occupy different layers of one system: knowledge in, actions out, control flow. Comparing them head to head is a category error'
  - 'Compose by subset: the doc-intel demo runs RAG alone with control flow fixed in code, and the IoT analytics platform runs all three layers'
  - 'Category confusion has a bill: bigger models shipped for retrieval failures, 850 raw tool definitions riding in context every turn, manager loops whose transcripts grow faster than the answers improve'
  - 'Whichever layers you compose, guarantees stay in code: tenant isolation via AST injection, scoped tool servers, and eval gates hold where the model cannot vote'
---

ByteByteGo's EP202 lines up MCP, RAG, and agents as if a team is supposed to pick one. The lineup is a category error. RAG answers how knowledge gets into the model's context. MCP answers how the model's decisions get out into the world as actions. An agent answers who decides the control flow between those two edges. Comparing them head to head is like comparing a fuel pump to a steering wheel: both live in the same car, and the car needs both.

I have written a deep dive on each layer, with production numbers: [how RAG works in production](/blog/how-rag-works-in-production), [inside an MCP tool server](/blog/inside-an-mcp-tool-server), and [the anatomy of a multi-agent platform](/blog/anatomy-of-a-multi-agent-platform). This post is the map that places all three. It introduces no new claims; every number below comes from one of those posts, and the links carry the detail.

![One production system: RAG feeds knowledge in on the left, an agent owns control flow in the center, MCP tools act outward on the right, each labeled with the question it answers](/blog/three-acronyms-one-system.svg)

## Each acronym decides a different layer

The clean test for which category you are in is what changes when you swap the piece out. Swap the embedding model and retrieval quality moves while tool schemas and control flow stay put; that is a RAG decision, and the demo's embedding migration shipped exactly that way, validated by an eval run before it went live. Swap a hand-rolled tool interface for MCP and the model gains a doorway it was trained to use, while what it knows and who decides remain untouched. Swap a fixed pipeline for an agent loop and a model starts choosing which call happens next; knowledge and tools do not change, but the control flow now has a non-deterministic owner.

## RAG: knowledge in

The [live demo](/demo) on this site runs the whole inbound channel: parse hostile documents, chunk under a per-document cap with a dead-letter queue for the pathological ones, embed with gemini-embedding-001 at 768 dimensions, index into pgvector, retrieve hybrid and fuse the rankings with RRF at k=60, then generate a grounded answer with citations. Retrieval recall@k holds at 0.93, and an eval suite re-scores that number on every pull request; a drop blocks the merge.

The model appears only at the last stage. That ordering is the whole diagnostic: when a RAG system answers badly, retrieval usually failed stages earlier and the model faithfully summarized the wrong chunks. The stage-by-stage walk, including why embedding dimensions are a cost dial and why hybrid beats pure vector, is in [how RAG works in production](/blog/how-rag-works-in-production).

## MCP: actions out

On a financial-analytics platform we work on, 22 MCP hubs expose more than 850 tools for token resolution, asset search, swap quotes, and oracle and gas data. The protocol layer is the small part; a working MCP server is a day of work if you have shipped a REST API. The engineering lives in the outbound path: semantic reranking so the model picks from a shortlist instead of an 850-entry phone book, user-scoped and admin-scoped servers so a prompt injection cannot invoke a tool that was never in the catalog, and a Redis cache with per-tool TTLs that holds p95 swap-quote latency under 300 ms.

All of that machinery belongs to the outbound layer: it hardens the interface between a model's decision and the systems that execute it. The full breakdown, including why versioned skills load before tools, is in [inside an MCP tool server](/blog/inside-an-mcp-tool-server).

## Agents: who owns the control flow

An analytics platform we built for an IoT product runs the agent layer in production. A front-desk router on Claude Sonnet 4.6 reads each question, splits it if it spans domains, and dispatches to two specialists on Claude Opus 4.8. Single-domain questions, the common case, bypass synthesis and cost one routing decision plus one specialist call.

The agent decides which calls happen. Permissions live elsewhere: every generated SQL query is parsed with sqlglot and the tenant predicate is injected into the AST before execution, so cross-tenant leakage is impossible by construction. Control flow belongs to the model; guarantees stay in code. Why the orchestrator routes instead of managing, and what the checkpointing and tracing look like, is in [the anatomy of a multi-agent platform](/blog/anatomy-of-a-multi-agent-platform).

<!-- CTA -->

## Category confusion is architecture debt

Each deep dive documents a failure that starts with a category mix-up.

Treat a knowledge problem as a model problem and you ship a bigger model while retrieval stays broken. Nine times out of ten in the postmortems I have been called into, the generation stage was working fine all along; the fix lived in the RAG layer, because no model can cite a chunk retrieval never fetched.

The tool layer fails through neglect. An agent re-reads its tool catalog on every turn, so a fat catalog is a tax you pay per turn, forever, and no model reliably picks the right tool from 850 raw definitions. The IoT platform's earlier version carried 200+ hardcoded definitions; replacing them with one generic tool plus a compressed 9k-token catalog dropped the per-turn cost and turned new operations into catalog entries.

The agent layer fails through overbuilding. Manager-pattern orchestrators plan, delegate, critique, and loop, and the transcript grows faster than the answer improves. Nobody reads those negotiations; everybody pays for them. A router that only splits, routes, and synthesizes gets the answer without the loop.

## Two systems, two subsets

Composition has a dial, and the honest move is setting it per system. The doc-intel [demo](/demo) runs RAG alone, deliberately. Its control flow is fixed in code: every document moves through the same six stages, every question triggers retrieve-then-generate, and the model cannot alter the pipeline's shape. No agent loop, no tool calls. For answering questions over uploaded documents, a pipeline is the right amount of machinery, and it keeps the demo auditable end to end.

The IoT analytics platform composes all three layers: an agent loop for control flow (the router plus specialists), tools for actions (the generic tool and its 9k-token catalog), and knowledge flowing in through versioned skills loaded before any query tool runs, so the model interprets readings instead of echoing them. The platform earns each layer because its questions span domains and touch a live multi-tenant database.

Sequencing follows the same dial: start with the pipeline, add tools when the model needs to act, and add the loop only when questions genuinely require a model to choose the next step.

## Where to go from here

The three deep dives carry the receipts this map points at, and each one links onward to the runbooks and ADRs. The systems behind all of them are summarized in [the operator brief](/about), and the RAG-only end of the argument is running right now at the [live demo](/demo): upload a document, ask a question, and watch the knowledge-in layer do its job with no agent in sight.