What are Runnables in LangChain | Generative AI using LangChain | Video 8 | CampusX

LangChain’s “runnables” are the missing abstraction that turns a pile of LLM-related components into a composable system. Instead of manually wiring prompts, models, retrieval steps, and output parsing together with custom glue code, runnables provide a common interface so each step can be treated like a reusable “unit of work.” The payoff is the ability to build complex LLM workflows by connecting standardized blocks—much like assembling Lego—while keeping the integration logic consistent.

The need for runnables traces back to how LangChain grew. Early on, LangChain became popular by standardizing access to different LLM providers: each vendor’s API behaves differently, so LangChain wrapped them so developers could switch models with minimal code changes. But once teams started building real applications—like PDF question answering—the work didn’t stop at calling an LLM. Developers also had to load documents, split them into chunks, generate embeddings, store them in a vector database, run semantic retrieval, and then format the retrieved context into a prompt for the LLM. In other words, “LLM calls” were only one small part of the pipeline.

LangChain responded by creating many components for these recurring tasks: document loaders, text splitters, embedding models, vector stores, retrievers, and output parsers. Even with these building blocks, developers still had to manually connect them. A key insight emerged: across many workflows, the same pattern repeats—create a prompt (often from a template), send it to an LLM, and then pass the result onward. LangChain introduced “chains” to automate these repeated wiring steps. For example, an “LLM chain” can take an LLM plus a prompt template and handle formatting and prediction automatically. A “retrieval QA chain” can bundle the retrieval step (query → semantic search in a vector database → retrieved text) with prompt construction and LLM answering.

However, the chain approach ran into a scaling problem. As more chains were added to cover more use cases, the codebase became heavier and the learning curve steeper—new users had to memorize which chain to use when. The deeper issue was compatibility: components weren’t designed with uniform interfaces from the start. Different components used different method names and calling conventions (e.g., LLMs use predict-style calls, prompt templates use format-style calls, retrievers use their own retrieval functions). Because of that, developers needed custom glue code to connect components for each new workflow.

Runnables address this by standardizing the interface across components. Every runnable follows a common contract with methods like invoke (single input), batch (multiple inputs), and stream (streaming outputs). Once standardized, components can be connected generically: the output of one runnable becomes the input of the next. Crucially, a composed workflow is itself a runnable, enabling nested and arbitrarily long pipelines.

The transcript then demonstrates the idea from scratch: dummy LLM and dummy prompt-template classes are converted into runnable-compatible components via an abstract runnable base class. A runnable connector composes multiple runnables in sequence by looping through them and feeding each step’s output into the next. Finally, two smaller chains (generate a joke, then explain it) are connected into a larger chain without writing new wiring logic—showing how runnables make complex multi-step workflows flexible and reusable. The instructor closes by noting that LangChain’s real implementation follows the same structure, with concrete runnable classes inheriting from the runnable interface and implementing invoke.