Reactive Graph Sequencing: The Technology Behind Wanderer

Most flow builders execute your logic once and move on. RGS rebuilds the entire sequence every time your data changes.

Wanderer is a new kind of flow builder, and at its heart is a technology called RGS – Reactive Graph Sequencing. It solves a problem hiding in plain sight: workflows that need to adapt in real-time, not just react to events.

What Is Graph Sequencing?

Graph sequencing takes a graph of nodes and edges and collapses it into a logical execution order. Which node runs after which? That's the sequencing problem.

RGS uses depth-first traversal combined with three types of directed edges:

• Must – This path must be taken
• May – This path can be taken (conditional)
• Not – This path must not be taken

Each edge type has a visual weight (thickness) representing its priority. With just these three primitives, you can draw any logical gate purely visually, and traversal collapses the visual representation into an executable sequence.

That's graph sequencing. But what makes it reactive?

The Reactive Layer: States and Continuous Re-Sequencing

Every node holds state – primitive values like booleans, strings, numbers. Outgoing edges can evaluate these states (e.g., "is this value true?") to determine which paths to take during traversal.

States can be pushed from one node to another via edges, partially or completely overwriting the target's state. They can also be changed by external processes – user input, API responses, database updates.

When a state changes, the graph doesn't just trigger the next node. It re-traverses the entire graph and generates a new sequence based on the updated data. The graph continuously adapts, collapsing into different execution paths as your data evolves.

Beyond Simple Flows: Control Edges

Traditional flow builders connect nodes linearly or with branches. RGS adds control edges that operate outside the main traversal:

• Push – Send state to a distant node without traversing there
• Call – Call logic in a remote part of the graph that causes states to change.

These enable non-local state manipulation, allowing flows that would require complex custom code in other tools.

But Does It Scale?

A question I get a lot: but does it scale to 1,000 nodes and beyond? And my honest answer is: when was the last time you actually needed a conversational flow with 1,000 nodes? Most real-world flows – onboarding wizards, configurators, support bots, approval processes – live comfortably in the tens to low hundreds. The "scale" concern is usually imported from backend thinking, where 1,000 of anything is small. Interactive flows are a different beast: every node is a moment a human or system actually passes through.

But let's take the question seriously anyway. If the graph re-sequences on every state change, doesn't traversal become expensive?

It doesn't – by design. At the start, only the entry node is active, so traversal is minimal. As the user progresses, active branches grow, but never into the full graph. Every decision activates one path and kills others. The active traversal rises and then stabilizes. When a user backtracks, the previously active branch dies and a new one takes its place – the traversal shifts rather than accumulates. The active portion is always a fraction of the whole.

There's also a second kind of scaling that matters more than node count: logic scaling. In a traditional flow builder, every backtrack, every "what if the user changes their mind three steps ago," every invalidation rule is code you have to write. The graph grows linearly, but the logic glueing it together grows combinatorially. RGS absorbs that work. Backtracking, invalidation, re-routing on state change – the graph handles it because that's what re-sequencing is. You don't write the logic; you just change a state, and the traversal figures out the rest.

So the practical answer is: RGS scales fine for the flows people actually build, and more importantly, it scales down the amount of logic you have to maintain as the flow grows.

A Concrete Example: The Adaptive Chatbot

Imagine a chatbot for an e-commerce store. A customer is configuring a custom skateboard deck and has answered five questions about graphics, size, and wheels. Then an API call comes in: the deck just went out of stock.

In a traditional flow builder, you'd have to store the conversation state, manually interrupt the flow, write custom backtracking logic, and hope you didn't break anything.

With RGS, you simply change a state value (deckInStock: false). The graph re-sequences itself. Questions based on that deck become invalid, the traversal recalculates, and a new message appears:

"Sorry, the skateboard deck you're configuring just went out of stock. Can I help you with something else?"

This isn't a special case handled by custom code – it's how RGS works by default. The graph can invalidate earlier decisions and re-route the conversation based on new information.

Why This Matters: Real-Time Adaptation vs. Event Reaction

Most automation tools are event-driven: something happens → trigger a workflow → execute a sequence → done.

RGS is state-driven: the graph continuously evaluates current state and generates the appropriate sequence. When state changes, the sequence changes. This enables new categories of workflows:

• Adaptive onboarding that adjusts to verification failures or changed user data
• Product configurators that recalculate when options become unavailable
• Multi-stakeholder approvals that re-route when budget or requirements change mid-flight
• Real-time assistants that respond to external events (package delivered, meeting rescheduled) and adjust the conversation

These are either impossible or require significant custom code elsewhere. With RGS, they're just graphs.

Building Wanderer: Design Principles

Wanderer is the first implementation of RGS, built on a few unconventional principles:

• Zero friction: No login, no registration, no server. Open the browser and start building.
• Immediate feedback: Edges animate during traversal, active nodes get an outline, and clicking any node reveals its current state. The complexity of sequencing becomes tangible through visualization.
• Self-contained learning: Tutorials run inside the builder. Nodes load interactive guides. A chat assistant (itself built with message nodes) guides you through concepts. The graph teaches you how to build graphs.
• Graphs are JSON: Export, version control, share, restore. No proprietary format, no lock-in.

But Wait — There's Still Code in the Nodes!

Yes. And that's the point. Where is the no-code promise then?

A typical "Send Message" node contains code that talks to an API, formats a string, handles a timeout. That code has to exist somewhere – something has to actually do the thing. My claim isn't that code disappears. It's that code disappears from the control flow layer.

Two very different kinds of code live in a typical flow builder:

• Action code: "Send this HTTP request." "Format this string." "Write to this database." A side effect that talks to the outside world.
• Control flow code: "If the user said yes and their cart isn't empty and we haven't shown this question before, go to node C." Logic about the flow itself.

In every flow builder I know, both kinds are mixed together – buried inside nodes, hidden in condition fields, scattered across expression strings. The graph shows the choreography; the actual logic lives in a hundred little fragments you have to click into to read.

In RGS, control flow code is gone. The graph is the control flow. State lives in nodes. Conditions live on edges, visually. AND, OR, NOT, XOR — you draw them. If you want to know why the flow went left instead of right, look at the canvas, not a config panel.

Action code stays. A node that sends an email has to know how to send an email. But that's a capsule – a clean, reusable adapter to the outside world. It doesn't know anything about your flow; it just does its job when the graph tells it to.

That's the trade: honest about action code, ruthless about control flow code. Most "no-code" tools get this backwards – they hide action code behind nice icons and then ask you to write control flow code in tiny text fields. That's exactly the wrong way around.

What You Can Build With RGS

Because RGS handles both forward sequencing (what happens next) and retroactive adaptation (what should have happened), it opens up use cases that other tools struggle with:

• Conversational AI with memory and context manipulation – chatbots that revise earlier questions, invalidate assumptions, and re-route based on real-time data
• Dynamic product configurators – adapt when inventory changes, prices update, or compatibility rules shift
• Complex approval workflows – multi-stage processes that re-route when stakeholders, budgets, or requirements change
• Adaptive onboarding and wizards – user journeys that adjust based on verification, preferences, or external state
• Real-time decision engines – business rule systems that continuously re-evaluate as conditions change

Where RGS Sits in the Landscape

State-driven graphs aren't new. Reactive programming, statecharts, dataflow languages — smart people have thought about this for decades. Let me be honest about where RGS borrows and where it does something different.

• Statecharts (Harel, XState): State machines on steroids – hierarchical state, parallel regions, beautiful transitions. Fantastic if you're a developer, but it's a library. You write JSON or TypeScript. A domain expert can't open XState and click together a pizza configurator.
• Temporal, Cadence, durable workflow engines: Brilliant for long-running backend processes with replay and fault tolerance. Code-first. Different problem entirely.
• Node-RED: The closest spiritual cousin to Wanderer – visual, graph-based, a real editor. But it's message-passing: a message flows through the graph, gets transformed, exits. There's no concept of "this node is alive right now because the current state says so." When a user backtracks or a data source invalidates, you wire that yourself.
• BPMN / Camunda: Formally founded, visual, mature. Built for long-running business processes, not interactive flows that re-evaluate continuously.
• Reactive frameworks (Svelte, Solid, MobX signals): Continuous re-evaluation is their core idea, and RGS owes them conceptually. But these are code primitives. You don't draw signals on a canvas.

So what's actually new about RGS? Not any single ingredient – it's the combination: a visual editor where state lives in nodes, logic lives in edges, and the whole graph continuously re-sequences itself, in a tool a non-programmer can actually open and use. Statecharts gave us hierarchical state. Signals gave us continuous reactivity. Node-RED gave us a usable visual editor. RGS pulls those threads together and asks: what if the canvas itself was the runtime?

The Technical Foundation: What Makes RGS Different

RGS combines the visual simplicity of flow builders with the power of reactive programming and the expressiveness of state machines – without requiring a backend.

Why Now?

Visual programming has been "almost there" for decades. Flow builders handle simple automation well but break down when workflows need to adapt dynamically.

RGS bridges that gap. It gives you the expressiveness of code with the clarity of visual diagrams, and it handles complexity without requiring you to write complex logic. Most importantly, it makes reactive, adaptive workflows accessible – not just to developers who can write custom state management code, but to anyone who can draw a graph.

Try It Yourself

Wanderer is live and free to use. No signup, no installation. Open your browser, start building, and watch your graph come to life. See edges animate as the graph traverses. Watch nodes light up when they're active. Click any node to inspect its state in real-time. The complexity of Reactive Graph Sequencing becomes intuitive when you can see it happen.

Conclusion

Reactive Graph Sequencing isn't just a new algorithm – it's a new way of thinking about workflows. Instead of asking "what happens next?", RGS asks "what should be happening right now, given everything we know?"

That subtle shift unlocks workflows that adapt, reconsider, and optimize themselves in real-time. Wanderer is the first tool built on this foundation, but RGS is bigger than any single implementation. It's a technology for building systems that think in graphs and react to reality.

Title image: https://unsplash.com/de/fotos/flachwinkelfotografie-von-metallstrukturen-ZiQkhI7417A