L4 Routing Rules

Audience: workflow authors + reviewers. How to write IF/THEN rules that control what the agent does when a customer says something off the happy path.

TL;DR cheat sheet

goto = jump to a real step in the graph (it has its own prompt, niti rules, sub-flow).
say = speak THIS exact phrase, pre-cached as TTS, deterministic. 0 ms latency.
say + return_to_cursor: true = reassure / explain → resume where customer was.
say + end_call: true = polite close → terminate gracefully.
Workflow-level (Global) = applies at every step (cancel, fraud, interest, off-topic).
Step-level = applies only here (loan-type pick, salary hesitation, branch-specific).
say is pre-built into the TTS cache when you click Apply. Editing the text re-builds on next Apply.

Quick-decide examples

L4 Prompt vs L4 Routing Rules — the big distinction

Both shape what L4 BUDDHI does at a step, but they answer different questions. Mixing them up is the #1 authoring mistake (the 2026-06-09 + 2026-06-10 Cab Booking traces both had routing intent described in the L4 prompt textarea, where L4 ignores it).

Mental model

L4 prompt = the agent's personality + rules for this step (tone, what to validate, what to never do).
Routing rules = shortcuts — pre-written decisions for specific customer intents that skip reasoning entirely.

6 worked examples — which goes where?

1. Reject single-digit salary answers

Need On the salary-collect step, accept "5 lakh" but re-ask on bare "5".

Use L4 Prompt.

Why Validation behavior — L4 still reasons each turn, but with a stricter rule.

2. Fraud reassurance — exact wording, anywhere in the call

Need Customer asks "ये fraud तो नहीं?" at any step → reply with one EXACT line, then continue.

Use Routing Rule (workflow-level, say + return_to_cursor).

Why Universal intent + exact wording required + must resume current step.

3. Loan-type pick — branch into sub-flow

Need On loan-type step, "Personal loan" → jump to personal-loan sub-flow.

Use Routing Rule (step-level, goto).

Why Branching into a multi-step sub-flow with its own collection logic.

4. Stop English drift

Need L4 keeps switching to English on Hindi-speaking customers.

Use L4 Prompt.

Why Style/persona constraint — applies to every L4 turn, not a specific intent.

5. Polite cancel — end gracefully

Need Customer says "रहने दीजिए" / "cancel कर दो" → one polite line + terminate.

Use Routing Rule (workflow-level, say + end_call).

Why Universal intent + exact wording + must terminate.

6. Never accept "skip" on a required slot

Need On the date-collect step, never let customer bypass with "skip" / "baad mein".

Use L4 Prompt.

Why Step-specific validation rule. Not navigation — just a what-NOT-to-do directive.

Decision flow (when in doubt)

Common mistakes — anti-patterns

The four places L4 reasoning lives

D is a property of a rule, not a separate storage location. A single rule can use either goto (jump) or say (canned response).

Rule schema — the two flavours

Flavour 1 — goto (jump to a real step)

Use when the next thing isn't just "say one line" — it's a whole sub-flow with its own collection logic, branches, sub-steps.

Flavour 2 — say (canned response, pre-cached)

Use when you want to say one specific phrase and then resume the conversation where the customer was. Pre-cached at apply time, 0 ms latency, identical wording every call.

Flag combinations on a say rule

The decision rule (four-way)

For each rule, ask in order:

1. "Could the customer say this at MORE THAN ONE step?"
   Yes → workflow-level (A)
   No → step-level (B)
2. "Is the response a one-line reaction or a multi-step branch?"
   One-liner / single sentence → say (D)
   Multi-step (own collection, own branches) → goto
3. "After speaking, where should the cursor go?"
   Back to the same step where customer was → return_to_cursor: true
   End the call → end_call: true
   Advance normally to next step → leave both off (rare)
4. "Is this about style/persona, not navigation?"
   Yes → it belongs in step.l4.prompt, not a routing rule.
   Example: "On THIS step, never accept a salary range — only a single number"

Complete example — Loan Eligibility (copy-pasteable)

How the parser interprets it

How the pre-caching works

When you click Apply on the Designer panel:

1. The parser splits the script into global + per-step buckets and writes them to the workflow.
2. For every rule with a say field, the runtime:
   Computes a stable intent_key: routing_global_<idx>__<sha> or routing_step_<sid>_<idx>__<sha>
   Calls the workflow's TTS provider (Sarvam / ElevenLabs / etc.) with the workflow's voice + language
   Stores the resulting clip as a sample with step_role: "routing_response"
3. The Designer's response shows precache: {jobs_total: N, synthesised: N} so you can confirm.

At runtime — what L4 sees

Override pattern (rare but important)

When a global rule needs a DIFFERENT target on a specific step. Example: globally, "ask about interest rate" → generic explainer. But on collect_loan_type, asking about interest rate is suspicious (no loan type picked yet) — redirect back into the funnel.

The step-level rule wins on label collision (case + whitespace insensitive). L4's prompt for collect_loan_type shows only the step-level version. Other steps see the global rule normally.

Where does this rule belong? — full cheat table

Common mistakes

1. Putting universal rules per-step — copying "interest rate question" onto every step's rules will drift. Edit on step 1, forget on step 7. Use workflow-level.
2. Putting step-specific rules at workflow level — "Personal loan" at workflow level would fire on the salary step too, causing weird jumps. Use step-level.
3. Using L4 prompt for routing decisions — the L4 prompt is for how to talk, not where to go. Use routing rules for navigation.
4. Missing the goto target — make sure the target step exists in the workflow. The parser surfaces unmatched ones in "⚠ Unmatched headings" — fix those before testing.
5. Vague when clauses — "customer is unhappy" → too vague, L4 won't classify reliably. "customer expresses frustration about long wait time" → much sharper. Be specific.
6. Forgetting return_to_cursor on canned responses — without it, the agent says the canned line and then the cursor advances. Most reassurance / explainer flows want return_to_cursor: true.
7. Editing say text but not clicking Apply — the rule field saves on edit, but the new audio isn't synthesised until Apply runs. Stale audio plays until then.
8. Mixing end_call and return_to_cursor — contradictory. Designer clears one when the other is set; parser drops return_to_cursor when it auto-detects an end_call closing phrase like "शुभ हो" / "have a good day".

Performance + cost reference

The say field is what makes "I want the agent to say EXACTLY this" achievable without bloating the step graph with one-line reaction steps.

Appendix — Pure JSON examples

For reviewers reading the parsed result rather than the IF/THEN script.

Workflow-level rules (wf.global_l4_routing_rules)

Step-level rules on collect_loan_type (step.l4_routing_rules)