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, inside an MCP tool server, and the 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.
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 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.
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.
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.
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 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, and the RAG-only end of the argument is running right now at the live demo: upload a document, ask a question, and watch the knowledge-in layer do its job with no agent in sight.