How do LlamaIndex Workflows differ from LangChain LCEL?

LCEL and Workflows are both ways to compose multi-step LLM pipelines, but they use different abstractions and that difference shows up the moment you need loops. LCEL, LangChain Expression Language, composes by piping Runnables. You write `prompt | model | parser` and the runtime walks that pipe from left to right. Branching exists via RunnableBranch and parallelism via RunnableParallel, but the overall shape is a directed acyclic graph. There is no way for a later step to send work back to an earlier step. LlamaIndex Workflows compose by events and step handlers. You decorate methods with `@step`, and each method declares which event type it consumes and which event type or types it emits. The runtime is event-loop driven. It dispatches events to whichever step handles them, and a step can emit an event that re-triggers an earlier step. The practical consequence: Workflows can express cycles natively. Agent loops, retry with backoff, human in the loop waits. All natural. LCEL cannot. To get cycles in the LangChain ecosystem, you graduate to LangGraph, a separate library that adds a state graph on top of LCEL. Workflows rolls the DAG and the cycle-capable orchestrator into one abstraction.

LCEL and LlamaIndex Workflows are both composition layers but they bet on different primitives. **LCEL** treats a pipeline as a typed function composition. A Runnable is something with `.invoke`, `.batch`, `.stream` (plus async variants), and the pipe operator chains them: `prompt | model | parser`. Each step has one typed input and one typed output. Branching is RunnableBranch; parallelism is RunnableParallel; conditional logic is RunnableLambda wrappers. The runtime walks the composition from left to right, and the composition is a DAG by construction. There is no syntax for a later step to feed an earlier one. **LlamaIndex Workflows** treats a pipeline as event-driven handlers. You define a Workflow class with `@step`-decorated methods. Each step takes an event type as its argument and returns one or more event types as its output. The runtime dispatches events to whichever step accepts them; a step that emits an event of type `RetryEvent` re-triggers the step that consumes `RetryEvent`, even if that step ran earlier. The structural capability Workflows has and LCEL does not is **cycles**. Agent loops naturally write as `ThinkStep` emits an `ActStep`-event, `ActStep` emits a `ThinkStep`-event, repeat until a `StopEvent` is emitted. Retry with backoff writes as a step that emits its own input-event on failure. Human in the loop waits write as a step that emits a `WaitEvent` and resumes when an external trigger emits a `ResumeEvent`. LCEL cannot express any of these in pure form. The LangChain answer is to graduate to LangGraph, a separate library that wraps LCEL with a state graph offering exactly the cycle-capable orchestration Workflows has built in. The practical implication is that LlamaIndex bundles the DAG composition layer and the cycle-capable orchestration into one abstraction, while LangChain ships them as two libraries.