From n8n to LangGraph: What My AI Stack Evolution Actually Taught Me

Every tool I’ve used to build AI workflows has eventually broken in a way that was entirely predictable in retrospect. Each one had a ceiling — a point at which the abstraction that made it fast to start with became the thing that made it impossible to keep going.

I’ve been through this arc three times in four years: n8n → Prefect → LangGraph. Each transition was preceded by about two months of me fighting the current tool and telling myself I just needed to learn it better. Then I’d capitulate, try the next thing, and have that breathtaking experience of watching a hard problem suddenly become easy.

I want to tell you about all three, because the wrong lesson from this story is “use LangGraph.” The right lesson is something about patterns versus tools, and I’ll get there at the end.

n8n: The Fast-Start Tool That Does Everything Until It Doesn’t

n8n was my entry point into visual AI workflow automation. If you’ve never used it: it’s a node-based visual workflow builder — sort of like Zapier for people who want to self-host and don’t mind some complexity. You connect nodes visually, each node does one thing (call an API, transform data, write to a database), and when it works it’s genuinely delightful. You can wire together a workflow in an afternoon that would take a day to code from scratch.

For a lot of use cases, n8n is completely appropriate and you should use it. Simple API integrations. Basic data pipelines. Scraping workflows. Webhook receivers. Notification systems. I still use n8n for a class of work where the complexity ceiling doesn’t matter — things that are inherently linear, inherently stateless, and inherently recoverable from failure by just running again.

But here’s what n8n can’t do well: conditional state management across steps. Long-running workflows that need to pause and resume. Workflows where the path forward depends on previous results in non-trivial ways. Human-in-the-loop processes where you need to wait for approval before proceeding. Retry logic that’s smarter than “try again three times and then give up.”

And it definitely struggles when your workflows start branching and looping in complex ways. n8n’s parallelism story is awkward. Its error handling is limited. When a large workflow fails halfway through, figuring out exactly where it failed and what state you need to recover from is harder than it should be because the visual representation doesn’t map cleanly to execution state.

I hit this ceiling when I tried to build a multi-step document processing pipeline with conditional branching, human review steps, and stateful retry on failure. The n8n version took a week to build and was fragile in ways I couldn’t fully engineer around. I spent more time debugging the workflow framework than building the actual logic.

Prefect: The Serious Tool That Was Right But Early

The next stop was Prefect. If n8n is the visual tool for pragmatic builders, Prefect is the serious workflow orchestration platform for data engineers who want observability, retry logic, scheduling, and a clean Python API.

Prefect was genuinely better than n8n for the class of problems that had broken n8n. Flows are code — proper Python functions decorated to become workflow steps. You get a beautiful UI for monitoring runs. Error handling is expressive and granular. State management is first-class.

What it wasn’t designed for, circa 2023-2024, was agentic AI workflows — specifically, workflows where the structure of the workflow is itself determined at runtime. Prefect wants to know the shape of your flow before it runs. It’s good at “do these steps in this order, retry on failure, log everything.” It’s awkward at “have an AI decide what to do next based on the results of the last step, and maybe loop back around.”

Prefect also has a learning curve and deployment story that’s more complex than what a lot of SMB applications need. Running Prefect in production means either using their cloud offering (perfectly fine, but more moving parts and vendor dependency) or self-hosting their infrastructure (non-trivial). For simple-to-moderate use cases, it was more framework than I needed.

The moment I started building workflows where an LLM’s output was determining the next node to execute — rather than me hard-coding the graph structure — Prefect started to feel like the wrong tool for the job.

LangGraph: The Framework That Finally Matched the Problem

LangGraph explicitly models your workflow as a directed graph where nodes are functions and edges can be conditional — determined at runtime based on state. That’s the fundamental difference. You’re not defining a sequence of steps. You’re defining a set of nodes and the rules for moving between them, and the actual path through the graph can change based on what happens as it runs.

For agentic AI workflows, this maps directly to how the work actually functions. An agent receives a task, decides what tool to call, gets a result, decides what to do with that result, maybe calls another tool, maybe loops back, maybe routes to a human reviewer. That’s a graph with conditional edges, not a sequence with branching conditions bolted on.

The other thing LangGraph gets right is explicit state management. Every node in the graph reads from and writes to a shared state object. That state persists across the graph execution, can be inspected and debugged, and can be persisted to a database if you need long-running workflows that survive process restarts. This is the thing that made human-in-the-loop workflows actually feasible: you can pause the graph execution, wait for external input (a Discord approval, a webhook, a manual review), and resume from exactly where you stopped.

# A simplified example of what conditional graph routing looks like in LangGraph
def should_review(state: WorkflowState) -> str:
    if state["confidence_score"] < 0.8:
        return "human_review"
    return "auto_approve"

graph.add_conditional_edges("classify", should_review, {
    "human_review": "request_approval",
    "auto_approve": "commit_result"
})

That should_review function runs at runtime. The graph’s path is determined by the actual output of the classification step, not a pre-defined branch condition. This is the expressive power that makes LangGraph the right tool for genuinely agentic workflows.

What Actually Changed Between Tools

Here’s the thing I said I’d come back to: the wrong lesson from this story is “LangGraph is the best tool.”

The right lesson is that each tool forced me to understand a deeper layer of what I was actually building. n8n taught me workflow patterns — the mechanics of how data flows between steps, how to think about inputs and outputs, when to use parallel branches. Prefect taught me observability and reliability — that a workflow isn’t done when it runs once, it’s done when it runs consistently in production with proper error handling and logging. LangGraph taught me that agentic workflows are fundamentally different from scripted workflows — they need runtime flexibility, not compile-time rigidity.

I wouldn’t skip n8n and go straight to LangGraph. The conceptual foundation n8n builds is genuinely useful. And Prefect taught me to care about operational concerns that LangGraph doesn’t force on you.

The other lesson: tools change fast. What I’m recommending today might not be what I’d recommend in 18 months. Hatchet is interesting. Temporal has a serious following. New orchestration options are shipping constantly. The tools are not the point.

The point is understanding what pattern your problem needs: linear sequence, stateful branching, conditional routing, agentic exploration — and then finding the tool that expresses that pattern naturally instead of fighting it. When the tool and the pattern match, building feels easy. When they don’t, you spend your time fighting the framework.

Every tool I’ve discarded felt like a great tool. It was just a great tool for a slightly different problem than the one I was actually solving.

If the LangGraph model of graph-based orchestration sounds right for your use case, the next logical read is how to architect multi-agent systems on top of it — particularly the section on shared state design, which is the part people most often get wrong on the first attempt.

If you’re in that place — fighting your current orchestration framework and wondering if there’s a better fit — let’s talk about what your specific workflows actually need.