Most configurators ask you a list of questions. Wanderer asks the right questions, in the right order, and quietly rewrites itself whenever you change your mind.
To show what Reactive Graph Sequencing (RGS) actually feels like in practice, let's build something familiar: a pizza configurator. You can try the live demo right on this page.
The configurator walks you through a series of choices. Dough. Sauce. Cheese. Crust. Toppings. Each answer feeds into the next, and at the end you get a clean summary of your pizza.
So far, nothing unusual. Any form builder can do this.
But here's where it gets interesting.
When you pick size, you can choose between small, medium, large, and party pizza. If you pick party pizza, a new question appears: do you want it pre sliced? If yes, another question follows: how many slices?
That slice count then shows up in the final summary, right next to your toppings.
In a traditional flow builder, you'd wire this up with conditional branches, store the slice count in a variable, and write a bit of glue code to make sure the summary reflects the choice. Doable, but tedious.
In Wanderer, you just draw it. The graph handles the rest.
Now imagine you've finished configuring your party pizza with 12 slices. You scroll back through your answers and decide that actually, you want a small pizza instead.
You click on the size question. You change party pizza to small.
Three things happen automatically:
You didn't write any logic for this. You didn't define rollback rules. You didn't mark dependencies. The graph already knew that the slice questions only existed because of the party pizza choice. When that premise disappeared, everything downstream of it disappeared too.
This is retroactive adaptation, and it's the defining feature of RGS.
Every node in the graph holds state. Every edge carries a condition. When you change an answer, the graph doesn't just move forward to the next question. It re traverses itself from scratch, evaluates which paths are still valid given the new state, and collapses into a fresh sequence.
The questions that no longer belong simply aren't part of the new sequence. Their state is invalidated. Their entries in the summary vanish. The flow resumes at the first unanswered question in the new path.
You're not patching a flow. You're regenerating it.
If you've ever built a wizard, a configurator, or a chatbot with conditional logic, you know the pain. Forward flow is easy. Backward flow is where things break. Users change their minds, and suddenly your state is inconsistent, your summary is wrong, and you're writing invalidation logic by hand for every possible dependency.
RGS handles this by default. Backtracking, follow up questions, and data invalidation all happen on their own, because the graph itself encodes the dependencies.
That means:
The pizza configurator on this page is running on Wanderer right now. Change your mind as often as you like. Jump backwards. Pick party pizza, set your slice count, then switch to small and watch the slices quietly disappear.
The graph is doing all of it for you.
That's what reactive means when sequencing is built on it from the ground up.