TIL: You can use a single RunnableLambda to cut graph complexity by half

Just saw another "LangGraph is a game-changer!" post on here. Everyone's building these intricate Rube Goldberg machines with a dozen specialized nodes, each a custom `RunnableLambda`. Then they complain about debugging complexity. Classic.

Here's a contrarian take: you can often replace half your custom nodes with a **single, well-designed `RunnableLambda`** that uses a simple `if-elif-else` chain or a dispatch dictionary. The obsession with "one node, one purpose" is creating needless overhead for linear or mostly-linear workflows.

People seem to think LangGraph *requires* a sprawling graph to be useful. It doesn't. If your flow is "validate input → check policy → query DB → format response," that's four nodes. But if the state object is consistent, you can bundle the logic.

**Example:** Instead of:
- Node A: `validate_input`
- Node B: `enrich_context`
- Node C: `call_llm`
- Node D: `parse_output`

You write **one node** that does:
```python
def core_workflow(state):
step = state.get("next_step", "validate")

if step == "validate":
# ... logic
state["next_step"] = "enrich"
elif step == "enrich":
# ... logic
state["next_step"] = "call_llm"
# ... etc.
return state
```

Then you wire a simple two-node graph: this processor and a conditional edge that loops back until it's done.

**Benefits:**
* State inspection is trivial—everything's in one place.
* Fewer edges to misconfigure.
* Easier to add logging or error handling consistently.
* Often simplifies routing logic.

**When this *doesn't* work:**
* When you have truly independent, parallel branches.
* When you need different nodes to be swapped out independently (like competing LLM providers).

But for most linear "orchestration" flows I see posted? This cuts the visual complexity and actual code volume by half. Try it before you build a cathedral.