Catch unexpected inputs with Try and Throw nodes

Users don't follow scripts. RGS makes that a feature, not a problem.

The Scenario

A customer opens your e-commerce support chat. The flow is straightforward:

1. A Prompt node captures the user's initial message.
2. A GPT node classifies the intent.
3. A Queue node routes to the matching Task node — here, "Order Details."
4. Further down, a second Prompt node asks for the order number.

Now the user types: "What's your address?"

This has nothing to do with order tracking. In most chatbot systems, this is where things break. In RGS, it's where things get elegant.

5. A Throw node on the order-number prompt performs a clean exit and pushes its state upward to a Try node sitting before the GPT node at the top of the graph.
6. The GPT node re-evaluates the intercepted input, classifies the new intent, and the Queue and Task nodes react accordingly.

The conversation pivots seamlessly. The user notices nothing.

Why This Works in RGS

The core mechanism: Throw pushes state to an earlier node, and when any node's state changes, the entire graph re-sequences.

RGS doesn't "continue from where it left off." It re-evaluates everything. The GPT node sees the new input. The Queue picks up the new intent. The downstream sequence recalculates. No special-case logic, no rewiring — the behavior emerges from the graph structure itself.

This is fundamentally different from traditional try/catch in programming. The Throw node doesn't signal an error. It signals "this input belongs somewhere else" — and uses a control edge to send it there. The graph then asks: "Given everything we know right now, what should be happening?" — and re-answers that question from scratch.

Each node keeps a single responsibility. No node needs to understand the full flow. Add a new intent? Add a new task node. The Try/Throw pattern handles rerouting automatically.

How Traditional Builders Handle This

Short answer: not well. Most flow builders are linear — once you're in a branch, you're stuck. The usual workarounds:

• Fallback intents that don't know the current context and just say "Sorry, try again."
• Global intents that compete with local ones and create priority conflicts.
• Manual state management in custom code — functional but fragile and hard to maintain.

The fundamental limitation: traditional builders execute forward. Once a node has run, its result is final. There's no way to retroactively change an earlier node's state and have everything downstream recalculate. RGS can do exactly that, which is why late intent switching isn't an edge case — it's a natural consequence of how the system works.

---

Try the live example above, or start building your own adaptive conversations at wanderer-flow.de.