For two decades now, we have been dragging nodes onto canvases, connecting them with arrows, and calling the result a "flow." Chatbot builders, automation tools, LLM orchestrators, form designers. Every single one of them shows you the same picture: boxes connected by lines. And every single one of them quietly wastes what that picture actually is.

Because here is the uncomfortable truth. When you design a flow visually, you are not drawing a flow. You are drawing a network graph. A structure that, in mathematics, biology, neuroscience, and computer science, belongs to the most powerful organizing principles we know of.

And yet, flow builders use this structure for exactly one thing: telling the runtime what happens next.

That is like buying a Formula 1 car to drive it to the mailbox.

Networks are one of the most powerful structures in nature

Look around. Neurons in your brain. Mycelium under a forest floor. Power grids. Protein interactions. Social ties. Road systems. The internet itself. Whenever nature or engineering needs to solve a hard, adaptive, distributed problem, the answer tends to look the same: a network of nodes connected by edges.

Why? Because networks can do things that linear sequences fundamentally cannot.

• Networks can loop back. A signal can return, revisit, reconsider.
• Nodes can know each other. They can exchange data without a strict parent and child relationship.
• Networks can be traversed in many ways. There is rarely one path. There are paths, plural, and the best one depends on the current state of the world.
• Multiple regions can be active at the same time. Parallelism is native, not a feature you bolt on.
• Networks can adapt. Activating one region can deactivate another. Energy, attention, or signal can shift across the whole structure as conditions change.

This is the energy sitting on every flow builder canvas you have ever opened. And almost none of it is harnessed.

What flow builders actually do with all that power

Open Botpress. Voiceflow. n8n. Make. Pick your favorite. The graph on screen is treated as a glorified arrow diagram. The edge means one thing and one thing only: "after this node, go to that node."

That is it. Twenty years of progress and the edge is still a fancy "then."

Everything a real network can do has been amputated. There is no real backtracking, no shared context between distant nodes, no native parallelism, no concept of a path that can be invalidated and rerouted. The graph is a wireframe for a sequence, not a living structure.

And so the moment your flow needs to behave like a real network, you fall off a cliff.

The consequences of ignoring the network

This is not a theoretical complaint. It shows up in the daily pain of anyone who has ever shipped a serious flow.

Backtracking requires manual code. A user changes their mind three steps ago. In a real network, that is a state change that ripples through the graph. In a typical flow builder, it is a problem you solve with custom logic, hidden conditions inside nodes, and a private collection of curse words.

Bots block when they show an interface. The moment a chatbot displays a form, a button group, or a configurator, the entire conversation freezes until the user finishes. Why? Because the underlying engine has no concept of multiple regions being alive at the same time. A real network would let the form sit there while the bot keeps reacting, sending hints, validating, or responding to side events. But the flow builder only knows "next."

Multiple intents are nearly impossible to handle. A user writes "I want to cancel my order and also change my email." Two intents in one sentence. A network could activate both relevant regions and serialize them cleanly. A linear flow builder picks one, drops the other, or routes you into a "sorry, I did not understand" loop.

These are not edge cases. These are everyday flows. And the tools we have were never built to handle them, because the network underneath was never allowed to behave like a network.

The three escape hatches the big builders offer (and why they all fail)

When the architecture cannot solve the problem, the vendor sells you a workaround. There are essentially three on the market today, and each one creates a new problem instead of fixing the old one.

1. Restarts: "The user said something unexpected? Restart the flow. The state got messy? Restart. Something changed mid conversation? Restart." This is pain pushed directly onto the user. Imagine a website where every misclick sent you back to the homepage. We would call that broken. In flow builders, we call it a feature.

2. Code nodes: "Cannot express it in the graph? Drop in a code node and write JavaScript." This is pain pushed onto the agency or developer. You end up mixing imperative code with visual flow, creating an unmaintainable hybrid where half the logic is on the canvas and half is buried in script fields. Six months later nobody knows where anything lives. The graph lies about what the system actually does.

3. LLMs as a control layer: "Let the model figure it out." This is pain pushed onto reliability. LLMs are excellent at fuzzy understanding and terrible at deterministic expert flows. Try running a regulated intake form, a medical screening, or a precise product configurator through a free floating LLM and see how many compliance officers want to talk to you. The moment you hand the steering wheel to a probabilistic model, you have lost the guarantees that made a flow worth drawing in the first place. For deterministic, auditable, expert grade flows, "let the model decide" is not an answer. It is a liability.

All three workarounds exist because the foundation refuses to use the network it pretends to be.

But this is not an anti LLM argument

It is important to be precise here, because the easy misreading of the previous section is "Wanderer thinks LLMs do not belong in flows." That is not the position. The position is that LLMs do not belong in charge of flows. They belong inside them, as typed components with a clear job.

In Wanderer, this is exactly how Multi Intent is solved. A user types something like "I want to cancel my order and also change my email." An LLM node receives the prompt, extracts the intents as structured JSON, and that JSON unlocks edges in the graph. The LLM does what it is genuinely good at, which is understanding language. The graph does what it is genuinely good at, which is executing logic deterministically and reproducibly. No model decides business rules. No business logic tries to parse natural language. Each part does the job it was built for.

That distinction matters more than it looks. It is the difference between using an LLM as a conductor and using it as a sensor. As a conductor, an LLM has to be right about everything, all the time, including things it has no way of knowing. As a sensor, it only has to produce structured output from unstructured input, which is the one task where modern models are reliably strong. The graph takes that output and decides what happens next, based on rules you can read, audit, and trust.

This is the architecture that survives contact with real users, real regulations, and real edge cases. Not "LLMs everywhere." Not "LLMs nowhere." LLMs as nodes, the graph as the runtime, and a clear contract between them.

What if the graph actually behaved like a network?

This is the question that motivated Reactive Graph Sequencing, the engine behind Wanderer. The idea, as laid out in I'm done. Flow editors are broken. And you all know it., is simple to state and surprisingly hard to find anywhere else.

Treat the graph as the runtime. Let state live in nodes. Let logic live on edges. Let the network continuously re-sequence itself as state changes. Give edges real semantic weight (must, may, not) instead of "go here next." Add control edges so distant nodes can push state or call each other without violating the visual structure. Then watch what becomes possible.

You stop drawing diagrams. You start drawing behavior.

The flows that suddenly become trivial

The clearest way to understand the difference is to look at flows that are essentially impossible (or require pages of custom code) in conventional builders, and become a handful of nodes in a real network engine. Every one of the following is a working example in the Wanderer flow database.

A chatbot that keeps talking while a form is open. "A chatbot that helps you fill out a form" lets the form stay visible while the bot continues reacting, sending messages, and offering guidance in the background. No frozen UI. No blocking modal. Two regions of the network alive at once.

Automatic multi intent serialization. A user types a single prompt containing several intentions. The flow detects them, queues them, and processes them one after another, cleanly. No restart. No "I only understood one thing." The network simply activates the relevant regions and orders them.

Automatic UI cleanup. When a button, form, or input no longer makes sense given the current state, Wanderer removes it automatically. Because the graph already knows which nodes are alive and which are not. You never write cleanup code, because cleanup is a property of the network, not a task.

Context change detection. A flow that notices when a user keeps switching back and forth between two product branches, and proactively offers help. That is the network observing its own traversal history. Try wiring that with conventional condition fields.

Product configurator with live stock invalidation. A customer is halfway through configuring a product. The last unit sells out via an API event. The chatbot interrupts, tidies up the affected UI, explains the situation, and offers alternatives. No restart. No custom backtracking code. The state changed, the network re-sequenced, and the affected branches died on their own.

The Time Traveling Pizza Configurator. Pick your dough, your sauce, your toppings. Jump back. Change your mind. Break it if you can. Backtracking, follow up questions, and data invalidation all happen on their own, without a single line of code, so the configuration always stays consistent no matter how often you reshape it.

Try and Throw for unexpected entries. When a user types a new intention instead of, say, an expected order number, a Try / Catch structure catches that signal deep in the conversation and redirects it elsewhere. Errors and surprises become routable events, not crashes.

None of these are demos invented to flatter the engine. They are the everyday situations that break conventional builders, expressed as a few nodes and edges because the underlying network is finally allowed to do what networks do.

Stop drawing diagrams. Start drawing systems.

We have been staring at network graphs on our screens for twenty years and treating them like flowcharts from a 1970s textbook. The energy was always there. The structure was always there. We just kept asking it to do one tiny job: tell me what comes next.

Networks can do so much more. They can remember, reroute, parallelize, invalidate, and adapt. They can absorb the messiness of real users instead of pushing it back onto developers, agencies, or worst of all, the users themselves.

The next generation of flow builders will not win because of nicer icons or a shinier sidebar. It will win because it finally treats the graph as what it has always been. A living network. With all the power that implies.

We have been drawing them for two decades. It is time we started using them.

Title image: https://unsplash.com/de/fotos/grunes-und-schwarzes-seil-BW0vK-FA3eg