I spent the last years trying to make flow editors work. For chatbots. For forms. For LLM orchestration. Every single time I end up in the same place: buried in nested menus, drowning in node configurations, writing inline code in a tool that promised me "no-code."

I'm done making excuses for these tools. They are broken. Not the UI. Not the docs. The foundation.

So you open Botpress. Or Voiceflow. Or n8n. And within five minutes you're staring at a canvas full of nodes, nested menus, inline code editors, and condition builders that feel like they need their own documentation. You wanted to build a chatbot. Now you're studying a tool.

And it's not just chatbots. Complex form flows, onboarding wizards, LLM orchestration. Every single flow builder out there follows the same pattern: drag a node, click on it, get buried in configuration. Add a condition? Another menu. Need an API call? Another node, another config panel. Want to change something? Good luck finding where that logic actually lives.

This is not normal. And we should stop pretending it is.

The code editor test

Let me ask you something. Have you ever clicked on a variable name in your code editor and suddenly 10 nested submenus popped open? With configuration options, conditions, and inline logic attached to that single variable?

No? Of course not. That would be insane. No developer would accept that. You'd close the editor and never look back.

So why do we accept exactly this in flow builders? Every node is a little universe of hidden complexity. Click on it, and you're three menus deep before you even understand what it does. That's not a powerful tool. That's a broken abstraction.

If a flow editor requires a course before you can use it, it's not a tool. It's a problem.

The real issue is deeper than UI

The frustrating thing is: most people blame the UI. "It just needs a better interface." "A cleaner design." "Fewer options."

No. The UI is a symptom. The actual problem is the underlying architecture.

Think about it. An edge between two nodes is already a condition. It says: if this, then that. That's temporal logic. That's a rule. It's right there, visible on the canvas.

So why does every flow builder then bury another layer of conditions inside the nodes? You connect two nodes with an edge, and then you click on the node and configure more conditions in a nested menu. Conditions hidden inside a box. Invisible from the outside. Black boxes everywhere.

And it gets worse. Most flow builders love super-nodes. Take a typical "Choice Node" or "Question Node." It contains the question, the answer options, the branching logic, sometimes even validation. All packed into one node. That's a conceptual breach. The answer options are not part of the graph. They are buried inside a single node, invisible to the structure, unreachable by edge logic.

What if each answer option was its own node? Connected by edges that already carry the logic? Then your entire decision tree would be visible on the canvas. No hidden menus. No black boxes. The graph is the logic. This applies to every complex node type out there. The moment a node contains structure that should live in the graph, you've lost the point of having a graph in the first place.

And there is another problem: Most flow builders are event-driven at their core. Something happens, a trigger fires, a sequence runs top to bottom, done. That model has no real concept of state. It doesn't know where you are. It doesn't adapt when things change. So every edge case, every branch, every "what if the user goes back" scenario has to be manually wired and configured inside the nodes. The architecture can't handle the logic on a structural level, so it dumps it on you, hidden behind click after click after click.

What if the graph could think for itself?

Imagine a different foundation. Instead of "event happens, sequence runs," the graph itself holds the state. Every node knows if it's alive or dead. Every connection between nodes has a clear semantic meaning: this path must be taken, this path may be taken, this path must not be taken.

Three edge types. Must. May. Not. That's it. And that's enough. These three types can express every logical gate visually on the canvas. AND, OR, NOT, XOR. No configuration panels. No inline code. Just edges you can see.

When state changes, the graph re-sequences itself. You don't manually wire fallback paths. You don't write inline conditions. The structure is the logic. Change a decision and entire branches die while others come alive. No custom code. No nested menus. The graph adapts because it was designed to.

And before someone asks: no, re-sequencing doesn't mean the entire graph is traversed every time. At the start, only the entry node is active. As the user progresses, the active portion grows, but it stabilizes at a fraction of the total graph. When a user backtracks, the old branch dies and a new one activates. The traversal shifts, it doesn't accumulate. The more complex your graph, the more branches are dead at any given moment. Complexity makes it more efficient, not less.

This concept is called Reactive Graph Sequencing. And I built a flow editor based on it.

Wanderer

Wanderer is an open source flow editor built on RGS. No nested menus. No inline code. No configuration hell. The graph structure itself defines the logic.

If you want to understand the technical foundation in detail, I wrote about it here: Reactive Graph Sequencing: The Technology Behind Wanderer

Want to see demos? Check this out

I'm not saying this is the only way. But I am saying that the current generation of flow builders is built on a broken foundation. And we should stop blaming ourselves for struggling with tools that were never designed to be intuitive.

What do you think? Is the architecture the real problem, or am I just bad at reading nested menus?

Title image: https://pixabay.com/de/illustrations/ai-generiert-scrapyard-wagen-8241457/