LCEL: The Pipe Operator

LCEL composes Runnables into chains with |. Understand when to use it, how streaming actually works through each step, and the type contracts that break in production.

Quick Reference

→chain = prompt | model | parser — output of each step becomes input of the next
→Every Runnable has .invoke(), .stream(), .batch(), and async variants
→| is lazy — it wires steps together; .invoke() or .stream() triggers execution
→Only the model step generates tokens — prompt and parser steps are instant
→Type mismatch between steps fails at runtime, not at chain definition time
→Use LCEL for prompt→model→parser pipelines; use create_agent() for agent loops
→Legacy chains (LLMChain, SequentialChain) moved to langchain-classic in v1.0

LCEL in LangChain v1

LCEL's scope in LangChain 1.0

In LangChain 1.0, LCEL (the | pipe operator) is the standard for composing prompt → model → parser pipelines. It lives in langchain-core and isn't going anywhere. But for agent loops — anything involving tool calling, memory, or multi-step reasoning — LangChain 1.0 uses create_agent() with middleware instead of LCEL chains. LCEL is a composition primitive, not an application framework.

When to Use LCEL (and When Not To)

Before writing a chain, decide which composition tool fits your use case. Using LCEL where create_agent belongs — or vice versa — produces code that's either over-engineered or missing capabilities.

The Pipe Operator

LCEL lets you compose any Runnables with |, just like Unix pipes. The left step's output becomes the right step's input. Each | creates a RunnableSequence that executes in order when you call .invoke(), .stream(), or .batch().

Sign in to read this article

This is a premium article. Sign in with your Google account to continue.