When does an LCEL chain stop being the right abstraction for a workflow?

## The shape LCEL commits you to Every abstraction is a bet about the shape of the problem. LCEL bets on a **pipeline**: an ordered set of transformations, each a pure-ish function from its input to its output, with fan-out allowed (parallel blocks) and fan-back-in allowed (merging dicts), but no edge pointing backwards and no memory between invocations. Within that shape it is very good: you get sync and async, single and batch, buffered and streaming, plus tracing that spans every nested step, for free. The cost is that anything outside the shape must be smuggled in. ## Four signals you have outgrown it **1. Cycles.** "Try, evaluate, revise until good enough" is a loop. A `RunnableSequence` has no way to express one. The workaround — a lambda containing a `while` — makes the iterations invisible: the trace shows one opaque step, the caller cannot stream intermediate attempts, and there is no way to cap or resume the loop from outside. If iteration is central to the task, the control flow deserves to be first-class. **2. Durable state across turns or processes.** A chain's intermediate values live in the call stack. If a crash mid-run must resume rather than restart, or a conversation's working state must survive between HTTP requests, you need persistence at the orchestration layer, not a bigger dict passed down the pipe. **3. Human intervention mid-run.** Approval gates and mid-run edits require pausing execution, serialising the state, and resuming from that point later — possibly in a different process, hours later. There is no pause point in an LCEL sequence; the only unit of interruption is the whole call. **4. Per-step recovery and observability of a long job.** `.with_retry()` retries a scope by re-invoking it. That is fine for one flaky call and wasteful for a nine-step pipeline where step seven failed and steps one to six were expensive. Wanting to resume rather than replay is the same requirement as durable state. ## The opposite verdict: too much abstraction The symmetric failure is reaching for composition when there is nothing to compose. If your flow is "build a prompt string, call the model once, parse JSON", writing it as a piped chain adds indirection to stack traces, a framework version to your dependency graph, and a vocabulary tax on the next reader — in exchange for streaming and batching you may never call. A senior answer names this direction too: the right question is which of the inherited capabilities you actually use. ## Migration is incremental, not wholesale The useful framing in an interview is that this is not a rewrite decision. Because a composed chain is itself a `Runnable`, a pipeline can be embedded as one step inside a larger orchestration, and a graph runtime's node can be an LCEL chain. So the practical pattern is: keep the linear transform segments as chains, and lift only the control flow — the loop, the branch that depends on accumulated state, the approval gate — into whatever owns cycles and persistence. That keeps the streaming and tracing benefits where they apply, and pays the orchestration cost only where it is earned. ## How to justify the call A credible answer names the requirement, not the technology: *does this workflow need to loop, to resume, to be interrupted, or to be recovered per step?* If yes to any, a stateless pipeline is the wrong container regardless of which product you pick to replace it. If no to all, the pipeline is right — and if you additionally do not need streaming, batching, async or unified tracing, plain code is righter still. ## Things not to claim Do not assert that LCEL is deprecated — in LangChain v1 it remains the composition primitive in `langchain-core`, and chains still appear inside larger orchestrations. And do not describe the pre-1.0 chain classes as the alternative; they are the older generation of the same pipeline idea, not the answer to cycles or persistence.