Implement a chain to handle multi-step reasoning in LangChain.

What you need to know

"Multi-step reasoning" means the answer depends on several intermediate results. You can leave the steps inside one model call, or pull them out into the chain.

Plan, execute, synthesise

1from pydantic import BaseModel2from langchain_core.runnables import RunnableLambda, RunnablePassthrough34class Plan(BaseModel):5    steps: list[str]67planner = plan_prompt | llm.with_structured_output(Plan)8solver = step_prompt | llm | StrOutputParser()       # uses {question} and {step}910def run_steps(x: dict) -> list[str]:11    return solver.batch([{"question": x["question"], "step": s}12                         for s in x["plan"].steps[:5]])1314pipeline = (RunnablePassthrough.assign(plan=planner)15            | RunnablePassthrough.assign(findings=RunnableLambda(run_steps))16            | synth_prompt | llm | StrOutputParser())  # uses {question} {findings}

1. The planner returns a Plan object, not free text, so the next step can loop over it.
2. run_steps runs up to 5 steps with batch, in parallel, since here each step is independent.
3. The synthesis prompt sees the question and all findings and writes the answer.

The [:5] cap stops a planner that returns 20 steps from running up the bill.

When to move to LangGraph

A fixed pipeline runs each stage once. If step 3's result should change the plan, if a failed step should be retried with different inputs, or if a person must approve the plan, you need a loop and state. LangGraph models that as a graph with conditional edges.

When one call is enough

Current reasoning models do much of this internally. If one call with a reasoning model passes your test set, it is simpler and often faster than a hand-built pipeline. Split the steps when you need to check, cache or reuse them, or when different steps need different tools.

A real-life example

A lead-qualification pipeline for a commercial real-estate firm answers "Is this company a good lead for our Hinjewadi office space?". A single prompt gave confident but shallow answers. The team built plan, execute, synthesise: the planner produces steps like "estimate headcount", "check current office location", "check recent funding"; each step calls a search tool or the CRM; the synthesis prompt scores the lead with reasons. Because each step's output is saved, the sales team can see why a lead scored 8 out of 10. When the "recent funding" step kept returning old news, they fixed that one step's prompt without touching the rest.

Follow-up questions to expect

• "Why use structured output for the plan?" — So the next stage can loop over a list reliably, instead of parsing numbered prose.
• "How do you stop runaway plans?" — Cap the number of steps, set max_tokens, and add a timeout on the whole run.
• "What if steps depend on each other?" — Run them in order and pass earlier findings into later steps, or move to LangGraph where state carries across steps.