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 that's been hiding in plain sight: workflows that need to adapt in real-time, not just react to events.

Let me show you how it works.

What Is Graph Sequencing?

At its core, graph sequencing is about taking a graph of nodes and edges and collapsing it into a logical execution order. Which node runs after which? That's the sequencing problem.

RGS uses depth-first graph 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) that represents its priority. With just these three primitives, you can draw any logical gate purely visually. Through graph traversal, this visual representation collapses into an executable sequence.

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

The Reactive Layer: States and Continuous Re-Sequencing

Every node in an RGS graph 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.

Here's where it gets interesting: States can be pushed from one node to another via edges, partially or completely overwriting the target node's state. States 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.

This is reactive sequencing: The graph continuously adapts, collapsing into different execution paths as your data evolves.

Beyond Simple Flows: Control Edges

Traditional flow builders connect nodes in a linear or branching fashion. RGS adds control edges that operate outside the main traversal:

• Push – Send state to a distant node without traversing there
• Pull – Request state from another node
• Call – Invoke logic in a remote part of the graph

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

A Concrete Example: The Adaptive Chatbot

Imagine you're building a chatbot for an e-commerce store using Wanderer. A customer is configuring a custom skateboard deck. They've answered five questions about graphics, size, and wheels.

Then an API call comes in: The deck they're configuring just went out of stock.

In a traditional flow builder, you'd have to:

1. Store the conversation state
2. Manually interrupt the flow
3. Write custom logic to backtrack
4. Hope you didn't break anything

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

"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 entire 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 the current state and generates the appropriate sequence. When state changes, the sequence changes.

This enables entirely new categories of workflows:

• Adaptive onboarding flows that adjust based on verification failures or changed user data
• Product configurators that recalculate when options become unavailable
• Multi-stakeholder approval processes 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 accordingly

These workflows are either impossible or require significant custom code in traditional flow builders. With RGS, they're just graphs.

Building Wanderer: Design Principles

Wanderer is the first implementation of RGS, and it's built with some unconventional principles:

Zero friction: No login, no registration, no server. You open the browser and start building. The graph executes as you construct it.

Immediate feedback: Edges animate during traversal. Active nodes get an outline. Click any node to see its current state. The complexity of graph sequencing becomes tangible through visualization.

Self-contained learning: Tutorials run inside the builder. Nodes can 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.

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
Build chatbots that can revise earlier questions, invalidate assumptions, and re-route based on real-time data changes.

Dynamic product configurators
Create configurators that adapt when inventory changes, prices update, or compatibility rules shift.

Complex approval workflows
Design multi-stage processes that re-route when stakeholders change, budgets shift, or requirements evolve.

Adaptive onboarding and wizards
Build user journeys that adjust based on verification results, user preferences, or external system states.

Real-time decision engines
Implement business rule systems that continuously re-evaluate as conditions change.

The Technical Foundation: What Makes RGS Different

Let me break down what separates RGS from other flow technologies:

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 they 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. 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