LLM vs Chat Models
LangChain has two model interfaces — understanding which one to use matters for how you write prompts.
LLM (text-in, text-out)
Takes a plain string prompt and returns a plain string. The older interface — used by base models like GPT-3 era models.
llm.invoke("Tell me a joke")
Chat Model (messages-in, message-out)
Takes a list of messages (system, human, AI) and returns a message. The modern interface — used by GPT-4o, Claude, Gemini.
chat.invoke([HumanMessage("Tell me a joke")])
Use Chat Models for everything new. All modern LLMs use the message format. LLM (text-in) is mostly legacy.
Chains vs Agents
This is the most important conceptual distinction in LangChain.
Chain
A fixed sequence of steps. You define the order at build time and it always runs the same way. Predictable, fast, cheap.
Prompt → LLM → Parser → Done
Agent
The LLM decides what to do at runtime. Given a goal and tools, it reasons about which tool to call next, loops until done.
Goal → LLM decides → Tool → Observe → Repeat
Rule of thumb: if you know the steps in advance, use a chain. If the steps depend on what the LLM finds along the way, use an agent.
LCEL — the Runnable interface
LCEL (LangChain Expression Language) is the modern way to compose LangChain components. It uses the
| pipe operator to chain any two Runnables together —
exactly like Unix pipes.
Old way (v0.1 chains)
chain = LLMChain(llm=llm, prompt=prompt)New way (LCEL)
chain = prompt | llm | output_parserEvery component in LCEL implements the same interface — invoke(), stream(), batch(). You can swap any piece without rewriting the rest.
Why LCEL matters:
- Streaming works out of the box — just call
.stream() - Async support built in — call
.ainvoke() - Easy to add logging, retries, and fallbacks at any step
- Composable — chains of chains are just more pipes
The core building blocks
| Component | What it does | Example |
|---|---|---|
| Model | Wraps an LLM or Chat Model API | ChatOpenAI() |
| Prompt | Templates with variables | ChatPromptTemplate |
| Output Parser | Converts model output to structured data | StrOutputParser() |
| Retriever | Fetches relevant documents | vectorstore.as_retriever() |
| Memory | Persists conversation history | ConversationBufferMemory |
| Tool | Function an agent can call | @tool decorator |
Quick summary
- Use Chat Models for everything — LLM (text-in) is legacy
- Chains = fixed steps; Agents = LLM decides the steps at runtime
- LCEL uses
prompt | llm | parser— composable, streaming, async - Six core components: Model, Prompt, Parser, Retriever, Memory, Tool
- LangGraph = stateful graph-based agents — the future of LangChain
LangChain Core Concepts FAQ
What is the difference between a chain and an agent in LangChain?
A chain is a fixed sequence of steps you define at build time — it always runs the same way, making it predictable, fast, and cheap. An agent lets the LLM decide what to do at runtime: given a goal and a set of tools, it reasons about which tool to call next and loops until the task is done.
What is LCEL in LangChain?
LCEL (LangChain Expression Language) is the modern way to compose LangChain components using the pipe operator, such as prompt | llm | parser. Every component implements the same Runnable interface — invoke(), stream(), and batch() — so you get streaming, async, retries, and fallbacks out of the box.
What is the difference between an LLM and a chat model in LangChain?
An LLM takes a plain string prompt and returns a string — the older, mostly legacy interface. A chat model takes a list of messages (system, human, AI) and returns a message, which is the modern format used by GPT-4o, Claude, and Gemini. Use chat models for everything new.
What are the core components of LangChain?
LangChain has six core building blocks: Model (wraps an LLM or chat API), Prompt (templates with variables), Output Parser (structures the model output), Retriever (fetches relevant documents), Memory (persists conversation history), and Tool (a function an agent can call).
Should I use chains or agents in LangChain?
Use a chain when you know the steps in advance — it is faster, cheaper, and more predictable. Use an agent when the steps depend on what the LLM discovers along the way, such as deciding which tool or API to call based on the user's request.