Conditional-transfer reliability with many prompt conditions in a multi-agent (router → per-language component) flow

Support Help
1

Our setup

We run a Conversation Flow voice agent for a hotel that warm-transfers callers to ~15 departments. We use the multi-agent per-language isolation pattern (adopted on your earlier recommendation — it resolved our cross-language issues, so we’re committed to keeping it). The flow:

  1. A router agent hears the caller’s first request.
  2. It agent_swaps to the appropriate per-language agent.
  3. The per-language agent contains a Component. The first node after the component’s Begin node is a branch (logic-split) node holding all ~15 transfer conditions (prompt-type), each routing to a department, plus an else edge to our RAG/answer path. The branch intents:
  • Restaurant A / B / C / D — complaint or explicit staff request
  • Bakery — complaint or explicit staff request (general questions like hours/menu excluded)
  • F&B office — named staff member, or procurement/trade request
  • Banquet sales — travel-agency call or named staff
  • Banquet reservations — new booking / availability / quote (general questions excluded)
  • Lodging sales — travel-agency, named staff, or corporate contract
  • Room reservations — new booking / availability (general excluded)
  • PR/Media — press, media, PR, stakeholder
  • Accounting — invoices/receipts/payments
  • Procurement — purchasing/delivery
  • Facilities — construction/repairs/equipment
  • Front desk — direct transfer, same-day check-in change, late arrival
  • …(~15 total) + else → answer the question via RAG

Conditions are authored in the caller’s language (e.g. Japanese). They’re intent-scoped (complaint / new-booking / named-person / explicit staff request), with general informational questions explicitly excluded.

What we observe (A/B test)

The same prompt conditions route more reliably in a single-agent flow (prompt-type edges directly on a node) than in this multi-agent flow. In multi-agent we see more misroutes — most notably, an informational first utterance right after the swap gets pushed into a transfer that the identical question, asked a turn or two later, does not. Single-agent is consistently more accurate.

What we’ve confirmed from the docs (so you don’t need to restate these)

  • After agent_swap the destination agent has access to the full conversation history.
  • The logic-split node evaluates immediately/silently and always has an else, and the docs note a single node “can be hard for [the] agent to handle a bunch of conditions all at once, so this node can help break it down.”
  • For transition conditions, equation conditions are evaluated top-to-bottom (first-true wins); prompt condition ordering is not specified.

Questions

  1. Context/prompt behavior of a swapped-in branch node vs. a main-agent prompt node. Is there any difference in how prompt conditions are evaluated in a branch (logic-split) node inside a component reached via agent_swap vs prompt-type edges on a node in a single main agent? Specifically: when the per-language agent takes over and immediately hits the branch node, does that first branch evaluation use the full prior transcript the same way it would mid-conversation, or is context reduced on that first decision? (Docs confirm full history is available after a swap, but not how it factors into the very first branch evaluation — this is our leading hypothesis for the post-swap mismatch.)
  2. Chaining logic-split nodes vs. a single logic-split node. Given the doc’s note that one node can struggle to “handle a bunch of conditions all at once,” for our ~15 mutually-exclusive transfer intents do you recommend:
  • a single logic-split node holding all ~15 conditions, or
  • chaining multiple logic-split nodes — e.g. a first split by broad category (dining / events / lodging / admin), then a second split into the specific department?

What are the trade-offs (match reliability, latency, maintainability)? If chaining is preferred, is a hierarchical/grouped structure better than a flat sequential chain, and is there a practical max conditions per node? And is there any guaranteed ordering/priority among prompt conditions within one node?
3. Overall reliability suggestions for many multi-condition transfers in multi-agent mode. Since we’re committed to agent-swap per-language isolation, what would you recommend to maximize conditional-transfer accuracy across ~15 departments — node structure (single branch node vs. staged splits vs. prompt edges on a conversation node), condition wording, and any begin-node / component configuration that affects the first decision right after the swap?

We’re happy to share flow IDs / call IDs privately to help diagnose. Thanks!

2

Thanks for the detailed write-up, and you’ve already covered the docs, so I’ll stick to what I can actually add.

On the post-swap mismatch: I can’t confirm the internal eval (that’s Retell’s to answer), but your hunch matches what I’ve seen. The branch fires the instant the agent swaps in, judging that first utterance off the inherited transcript before the new agent has had a turn of its own. A turn later it routes fine because it’s now evaluating mid-conversation. The fix that’s worked for me is to not put the logic-split first. Drop a small conversation node ahead of it, even just a quick in-language “how can I help”, so the branch decides on a fresh user turn instead of the swapped-in one. That usually kills the first-utterance misroute.

For the 15 intents, stage the splits rather than cramming them into one node. Broad category first (dining / events / lodging / admin), then department. Easier to maintain, more reliable, and the extra hop costs almost nothing in latency. Prompt-condition order isn’t guaranteed anywhere, so don’t rely on it, just keep each condition narrow enough that two can’t both read as true.

The one thing worth confirming with Retell is that first-turn branch behaviour, since it decides whether the buffer node is a real fix or just a mask. Keen to hear if it closes the gap when you test it.

Russell

3

Hey @andrew3 Thanks for the details can you share any relevant call id. Since you have already reviewed the documentation for more information on these topics, I have forwarded your questions to the team for further review. We’ll get back to you with an update as soon as possible.

4

Here are 3 call IDs where an informational question is asked and it triggers transfer. Transfer reasons all explicitly list branch condition as complaint or request to speak to staff and exclude general info questions. Our test caller hears the transfer script start and immediately hangs up.

call_04a99a616afe9920624fcb31e6c
call_741111f70b4b13d0e6f0435f178
call_39f6f579ccc96e99a518251b6c1

5

When similar questions are asked later in the call (same branch conditions), transfer is not triggered:

call_1cd1eb590798343cca476b8e0e9
call_e54c24c84cf309094e5bf0861ac

Let me know if I can help in any other way.

Thanks,
Andrew

6

Hey @andrew3

**1. Branch (logic-split) prompt-edge evaluation, and what’s different right after agent_swap**

  • Prompt-type edges on a branch node are not evaluated one-by-one. They’re collected into a single multi-class LLM classifier call (one node-transition request, temperature=0) that returns the id of the chosen edge. There is **no ordering or priority among prompt conditions** — only equation conditions are evaluated top-to-bottom with first-true-wins.

  • The destination agent’s globalPrompt fully **replaces** the source agent’s; the prior agent’s general prompt is not carried into the classifier context.

**2. One 15-edge logic-split vs. chained / hierarchical splits**

  • More edges also = more confusable labels in one decision.
  • For 15 mutually exclusive intents we’d recommend a **2-level hierarchical structure** over flat 15:
  • Level 1: 3–5 broad buckets (e.g. Reservations / Dining / Events / Admin / Other).
  • Level 2: a small split per bucket (≤5 conditions) into the specific department.

**3. Reliability suggestions for your multi-agent setup (keeping per-language isolation)**

  • **Don’t make a silent logic-split the first node of the post-swap Component.** Put a short Conversation Node first (e.g. “How can I help you today — reservations, dining, events, or something else?”).
  • **Use equation edges wherever the router already knows the intent.** If your router classifies department before swapping, set a dynamic variable on swap and route the first split deterministically via equation conditions — first-true-wins, top-to-bottom, no LLM call involved

Docs for reference:

Thank You

7

Hi Mark,

Thanks for your response. This gives us a lot to experiment with.

Andrew