LangChain Crash Course

This is the framing post for the LangChain crash course, and the cover names the role the framework plays: it's the plumbing that wires models, prompts, data, and tools into one application. Newcomers often arrive expecting LangChain to be some kind of AI — it isn't. It's infrastructure.

The headline frames LangChain as 'the framework that wires LLM apps together' deliberately, because the whole mental shift is realizing the value is in composition and reuse, not in any model. The model is something LangChain calls; LangChain is what turns that call into a real app.

LangChain is best defined by what it provides: standard, swappable components for the recurring parts of an LLM application, plus a way to compose them. Model wrappers, prompt templates, output parsers, retrievers, memory, and tools are each a building block with a consistent interface. You assemble them into pipelines called chains.

The phrase to hold onto is 'it is the glue, not the brain.' Every later slide builds on this. LangChain doesn't make decisions or generate language; it provides the structure that lets the model's output flow cleanly into the next step of your application.

This slide heads off the most common misconception by stating plainly what LangChain is not. It is not a model and generates no text itself — under the hood it calls OpenAI, Anthropic, or a local model. It is not magic intelligence; it is structure and convention.

The practical framing is that LangChain turns one-off API calls into a maintainable application. A script that calls the API once doesn't need a framework. The moment you have several steps, want to reuse a prompt, or need to swap providers, the structure LangChain imposes starts paying for itself. Naming this early sets honest expectations.

Naming the core building blocks gives the reader a durable vocabulary for the rest of the course. The model wrapper standardizes how you talk to any LLM. The prompt is a reusable, templated instruction. The parser turns raw model text into structured data. The retriever fetches relevant documents. Memory carries conversation state across turns.

These five names recur in every LangChain app you'll ever read. Memorizing them now means that when later posts mention a 'retriever' in a RAG chain or a 'parser' that crashes in production, you already know exactly which Lego brick is being discussed and where it sits in the pipeline.

This slide defines the word 'chain' precisely, because it's both the namesake and the most overloaded term in the framework. A chain is simply components wired in sequence, where each step's output becomes the next step's input. The simplest possible chain is prompt, then model, then parser.

The modern syntax — LCEL, the LangChain Expression Language — lets you connect components with a pipe operator, so an entire flow reads as one expression. That pipe is the single most important piece of syntax in current LangChain, and post 3 unpacks exactly how it works. For now the reader just needs to see a chain as a relay.

The flow diagram shows the simplest chain as three handoffs so the reader sees a chain as a relay rather than a single event. The prompt fills in its template, the model generates text from it, and the parser structures that output. Each box hands its result to the next.

Seeing it left to right reinforces the core intuition: data flows through stages, each one transforming it. This same shape — input enters, each stage reshapes it, structured output emerges — scales all the way up to complex RAG and agent chains. The reader who internalizes the three-box version can read the fifty-box version.

This first code slide makes the abstraction concrete in three lines. It creates a prompt template with a {topic} variable, a chat model wrapper, and then composes them with the pipe operator into a chain. Calling invoke with a dict that fills the template runs the whole flow and returns the model's message.

The load-bearing detail is the single character |. That pipe is LangChain's composition operator: it takes the prompt and the model and produces a new runnable that chains them. The reader doesn't need to fully understand runnables yet — post 3 covers that — but seeing the pipe wire two components into one callable plants the central idea of the framework.

This comparison contrasts calling the API directly with using LangChain so the trade-off is concrete. Direct calls mean you glue everything by hand, write provider-specific code, and re-implement parsing and retries in every project — which is perfectly fine for a single call. LangChain gives you reusable, composable components, one-line model swaps, and built-in parsing, retries, and memory, which is what you want for multi-step apps.

The honest reading is that neither side is universally better. The right tool depends on scale. A one-shot script doesn't need a framework; a multi-step product with retrieval and memory benefits enormously from one. Post 2 makes this scale-dependent argument in full.

This slide sketches the ecosystem so the reader isn't confused by the many package names they'll encounter. langchain-core holds the base abstractions and LCEL. The main langchain package holds chains, agents, and common logic. Integration packages connect specific providers and vector databases. LangGraph handles stateful, branching agent workflows. LangSmith provides tracing and debugging.

Understanding this split matters practically: modern LangChain deliberately separated these packages, and importing from the right one is part of avoiding the version churn covered in post 5. The reader should leave knowing LangChain is a family of packages, not a single monolith.

The mental-model slide compresses the post into rules to carry forward. LangChain is plumbing, not a model. Its components are standard and swappable. A chain wires each output into the next input. The pipe operator composes steps left to right. And you reach for it specifically when one API call is no longer enough.

That last rule is the bridge to post 2. Everything useful about LangChain — reuse, composability, provider independence — only matters once your app outgrows a single call, which is precisely the 'why a framework exists' question the next post answers.

The CTA closes the concept post and points to motivation. We've established what LangChain is and isn't, named its core building blocks, defined what a chain is, contrasted it with raw API calls, and mapped the ecosystem.

Day 80's teaser asks the natural follow-up: if LangChain is just plumbing, why does a whole framework need to exist? Post 2 answers by walking through the gap between a quick demo and a real product — the templates, parsing, retrieval, memory, and provider independence that you'd otherwise rebuild by hand, badly.