LCEL replaced LangChain's old Chain class tree with a single pipe-composable Runnable interface that hands you batch, stream, and async for free.
Picture a kitchen where every appliance used to need its own kind of plug, toaster plug, blender plug, kettle plug, and you needed an adapter to chain any two. LCEL is the move to one universal socket. Plug a prompt into a model into a parser with the same connector. Now whatever you build can be turned on one at a time, in a big batch, streaming, or asynchronously, without you wiring anything extra. Before LCEL, each combination needed its own special chain class. After LCEL, it is one line and the runtime features come along for the ride.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
LCEL is LangChain's most important architectural pivot since the project launched. Before LCEL, the framework was an ever-growing tree of Chain subclasses. Each common pattern had its own class with its own constructor, its own streaming hooks, its own async story, and constant behavior drift between siblings. LCEL replaces that tree with a single Runnable interface, one composition operator, and a small set of runtime methods that every composition inherits automatically.
This section walks the pre-LCEL pain point, the structure of the Runnable interface, what composition actually gives you, the legacy story, and the boundary conditions where LCEL is the wrong tool.
The problem LCEL was built to solve
Pre-LCEL LangChain shipped a class for every common pattern. LLMChain for prompt to LLM. SimpleSequentialChain for two chains in a row. SequentialChain for the more flexible version. RetrievalQA for retrieve then prompt. ConversationalRetrievalChain for the version with chat history. MapReduceChain for the long-document summarization pattern. Dozens more, each with its own constructor, its own way to enable streaming (if it supported streaming at all), its own async story (if it had one), and frequent behavior drift between releases.
The pain was real. A developer needed to remember which class did what, which constructor argument was named llm versus chat_model versus prompt, which classes supported .stream() and which did not, and which were async-capable. Tutorial blog posts went stale in months because LangChain shipped new chain types and deprecated old ones at high cadence. Switching from one provider's chat model to another sometimes required swapping the entire chain class.
The deeper issue was architectural. The chain hierarchy was inheritance-heavy and the integration surface was growing combinatorially. Each new model integration, each new retriever, each new parser potentially needed its own chain variants. The tree grew until it could not be navigated.
Situations where this technique stops working.
2–4 min · Everything important, quickly.
from langchain_core.prompts import ChatPromptTemplate
from langchain_core.output_parsers import StrOutputParser
from langchain_openai import ChatOpenAI
prompt = ChatPromptTemplate.from_template('Summarise in one paragraph: {text}')
model = ChatOpenAI(model='gpt-4o-mini')
chain = prompt | model | StrOutputParser()
# Same chain, four call patterns, all free from composition
out_single = chain.invoke({'text': 'A long article...'})
out_batch = chain.batch([{'text': a}, {'text': b}, {'text': c}])
for token in chain.stream({'text': 'A long article...'}):
print(token, end='', flush=True)
# async usage
# async for token in chain.astream({'text': '...'}): ...
# Stacking: fallbacks, retries, structured output all return Runnables
robust = chain.with_fallbacks([prompt | ChatOpenAI(model='gpt-4o') | StrOutputParser()])Real products, models, and research that use this idea.
- LangChain's official quickstart for chat apps is now pure LCEL, no Chain subclasses
- LangSmith traces visualize LCEL chains as a graph because the Runnable interface exposes the necessary metadata
What an interviewer would ask next. Try answering before peeking at the approach.
QWhy is composition over inheritance the right call for a framework like LangChain?
The integration surface (models, prompts, parsers, retrievers, tools) grows fast and combinatorially. Subclass per combination explodes. A single interface with one composition operator scales linearly with new components, and behavior is uniform across compositions.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Treating LCEL as 'just nicer syntax'. The real payload is the unified Runnable interface that makes batch, stream, and async work uniformly across every composition.
60 second bullets to scan on the way to the call.
The full name of LCEL and the operator it overloads
The five methods every Runnable exposes
Primary sources. Browse if you want the original framing.
Same topic, related formats. Practice these next.