Three Things People Confuse: A Protocol, a Technique and a Library

Most RAG architectures fail not because the retrieval is poor, but because the engineer has conflated a library with a protocol and a technique with a transport. When you start building retrieval systems, the first mistake is usually architectural. You pick LangChain because it is popular. You pick Model Context Protocol because it is new. You pick a command-line interface because it is convenient. Then you wonder why your system is fragile, slow, or impossible to test. The problem is rarely the code. The problem is that you have mixed layers of abstraction that should remain separate. To build systems that scale, you must treat these components as distinct entities with specific jobs. If you blur the lines, you create tight coupling where there should be loose integration.

Separating the Technique from the Tooling

Retrieval-Augmented Generation is a technique. It is a pattern for injecting context into a large language model prompt. It is not a library. It is not a framework. It is a sequence of steps: retrieve relevant documents, format them, and append them to the user query. Any codebase can implement this. You can write it in sixty lines of Python using only the standard library and an HTTP client. You can write it in Rust. You can write it in Go. The technique is orthogonal to the implementation. LangChain is a library. It provides abstractions for chaining operations. It offers convenience methods for loading documents, splitting text, and calling APIs. It is useful for prototyping. It is often detrimental for production systems. When you use LangChain, you are trading control for speed. You gain the ability to write a pipeline in fewer lines of code. You lose visibility into the exact data flow. You become dependent on the library’s update cycle. If LangChain changes its interface, your pipeline breaks. If you have built your business logic directly on top of LangChain classes, you are locked in. The confusion arises because tutorials often present LangChain as synonymous with RAG. They show you how to build a RAG pipeline using LangChain. They do not show you how to build a RAG pipeline without it. This creates a false dependency. Senior engineers should view LangChain as a scaffolding tool. Use it to explore ideas. Do not use it to define your architecture. Your architecture should be defined by the data flow, not by the library’s class hierarchy.

Protocols and Transports Are Not Logic

Model Context Protocol is a protocol. It defines how applications share context. It standardises the way a host application exposes resources and tools to an AI model. It is a contract. It is not a retrieval technique. It is not a library. It is a specification for communication. When you implement MCP, you are building a server that exposes data. You are building a client that consumes that data. The protocol ensures that the client and server speak the same language. It does not tell you how to retrieve the data. It does not tell you how to rank the results. It only tells you how to package the request and response. A command-line interface is a transport. It is a way for a human to interact with a system. It is not a retrieval technique. It is not a protocol. It is a user interface. When you build a CLI for your RAG system, you are defining how the user submits queries and receives answers. The CLI should be thin. It should take input, send it to the pipeline, and display the output. It should not contain retrieval logic. It should not contain ranking algorithms. It should not contain prompt templates. If your CLI contains business logic, you have created a maintenance nightmare. You will have to duplicate that logic when you build a web interface. You will have to duplicate it again when you build an API. Conflating these layers leads to bad decisions. You might try to implement retrieval logic in your CLI. You might try to define your protocol in your library code. You might try to use a library to enforce a protocol. Each of these mistakes adds complexity. Each one reduces flexibility. Keep the transport separate from the logic. Keep the protocol separate from the implementation. Keep the library separate from the technique.

Skills as Packaged Instructions

A skill is a packaged instruction set. It is a way to tell the model how to perform a specific task. It is not a library. It is not a protocol. It is a prompt template with associated tools. When you define a skill, you are specifying the context, the constraints, and the expected output format. Skills are modular. You can swap them out. You can test them in isolation. You can version them. The confusion here is often with agents. An agent is a loop that decides which skill to use. A skill is the action itself. When you build a RAG system, you often have a single skill: retrieve and answer. But as the system grows, you may have multiple skills. One skill might be for summarisation. Another might be for code generation. Another might be for data extraction. Each skill has its own retrieval strategy. Each skill has its own prompt template. Each skill has its own evaluation criteria. Treating skills as first-class citizens allows you to manage complexity. You can test each skill independently. You can monitor each skill separately. You can update each skill without affecting the others. If you bundle all your logic into a single monolithic prompt, you lose this modularity. You create a system that is hard to debug. You create a system that is hard to scale.

The cost of this separation is initial friction. It takes longer to set up a system where each layer is distinct. It takes more code to wire them together. It requires discipline to keep them separate. But the payoff is clarity. You can replace the library without breaking the protocol. You can change the transport without altering the technique. You can update the skills without touching the pipeline. This modularity is essential for systems that evolve. Draw this diagram. Put RAG at the centre. Draw LangChain as a wrapper around the retrieval steps. Draw MCP as the interface between the host and the model. Draw the CLI as the entry point. Draw skills as the atomic units of work. Redraw it from memory. If you cannot draw it clearly, you do not understand the architecture. This reference diagram is your anchor. Use it to evaluate every design decision. If a component does not fit into one of these boxes, question its place in the system. The next lesson, The Naive Build: Sixty Lines, No Framework, strips away the library and builds the technique from scratch.

Apply it to your work