We Have Been Drawing Flows for 20 Years. But We Are Not Using Their Power

2026-06-11 by Chris<br>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.<br>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.<br>And yet, flow builders use this structure for exactly one thing: telling the runtime what happens next.<br>That is like buying a Formula 1 car to drive it to the mailbox.<br>Networks are one of the most powerful structures in nature<br>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.<br>Why? Because networks can do things that linear sequences fundamentally cannot.<br>Networks can loop back . A signal can return, revisit, reconsider.<br>Nodes can know each other . They can exchange data without a strict parent and child relationship.<br>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.<br>Multiple regions can be active at the same time . Parallelism is native, not a feature you bolt on.<br>Networks can adapt . Activating one region can deactivate another. Energy, attention, or signal can shift across the whole structure as conditions change.<br>This is the energy sitting on every flow builder canvas you have ever opened. And almost none of it is harnessed.<br>What flow builders actually do with all that power<br>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."<br>That is it. Twenty years of progress and the edge is still a fancy "then."<br>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.<br>And so the moment your flow needs to behave like a real network, you fall off a cliff.<br>The consequences of ignoring the network<br>This is not a theoretical complaint. It shows up in the daily pain of anyone who has ever shipped a serious flow.<br>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.<br>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."<br>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.<br>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.<br>The three escape hatches the big builders offer (and why they all fail)<br>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.<br>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.<br>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...