LCEL replaced LangChain's old Chain class tree with a single pipe-composable Runnable interface that gives every chain batch, stream, and async without extra code.
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 with it.
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 change 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.
The problem LCEL was built to solve
Pre-LCEL LangChain shipped a class for every common pattern. LLMChain handled prompt to LLM, SimpleSequentialChain ran two chains in a row, and SequentialChain was the more flexible version. RetrievalQA covered retrieve then prompt, ConversationalRetrievalChain added chat history, and MapReduceChain handled long-document summarization. There were dozens more. Each had 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 often. 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 current quickstart builds agents with create_agent, while LCEL stays the composition layer for prompt | model | parser pipelines
- 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 choice for a framework like LangChain?
The integration surface (models, prompts, parsers, retrievers, tools) grows fast and combinatorially. One subclass per combination grows without bound. 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 value 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.