How to route unclear or unsupported requests to a fallback agent

A fallback agent is not a dumping ground; it is a specialist for clarification, unsupported requests, conflicting intents, and safe recovery. The fallback can either complete the conversation or return a clarified signal so the supervisor can resume routing. Use this when the supervisor cannot confidently choose a specialist or when the user asks for something outside the supported intent catalog.

Concept

Keep clear deterministic or intent routes first, and put a quoted semantic fallback condition last for vague, unsupported, or conflicting requests. When the fallback should re-enter normal routing after clarifying, use EXPECT_RETURN: true with ON_RETURN: { action: resume_intent, MAP: {...} } — the fallback child gathers whatever’s missing, and MAP copies its result back into a parent-owned variable your supervisor can route on next turn. One thing affects how this looks once you look past the syntax: HANDOFF history defaults to full when omitted. Every route below omits HISTORY, so each child (including the fallback) now receives the entire conversation by default.

Minimal working example

SUPERVISOR: Fallback_Routing_Supervisor
GOAL: "Send clear requests to specialists and unclear requests to a fallback agent"

INTENTS:
  billing: "Billing and payment requests."
  technical_support: "Product troubleshooting requests."

HANDOFF:
  - TO: Billing_Agent
    WHEN: intent.category == "billing"
    EXPECT_RETURN: false
    CONTEXT:
      pass: [customer_id, account_id]
      summary: "Customer needs billing help."

  - TO: Technical_Support_Agent
    WHEN: intent.category == "technical_support"
    EXPECT_RETURN: false
    CONTEXT:
      pass: [customer_id, issue_summary]
      summary: "Customer needs technical support."

  - TO: Fallback_Triage_Agent
    WHEN: "the request is vague, unsupported, conflicting, or missing enough information to choose a specialist"
    EXPECT_RETURN: true
    CONTEXT:
      pass: [customer_id, conversation_summary]
      summary: "Clarify the customer's request and return if a specialist can be chosen."
    ON_RETURN:
      action: resume_intent
      MAP:
        clarified_intent: clarified_intent

AGENT: Billing_Agent
GOAL: "Resolve billing requests"

AGENT: Technical_Support_Agent
GOAL: "Resolve technical support requests"

AGENT: Fallback_Triage_Agent
GOAL: "Clarify unsupported or ambiguous requests"

MEMORY:
  SESSION:
    - clarified_intent

GATHER:
  clarified_intent:
    TYPE: string
    PROMPT: "Which area should handle this request?"
    REQUIRED: true

COMPLETE:
  - WHEN: clarified_intent IS SET
    RESPOND: "Thanks, I captured the clarified route."

customer_id, account_id, issue_summary, and conversation_summary are shown as passed context with no declared source in this example — treat them as project-local assumptions (typically populated from authentication or an earlier turn) and declare them via MEMORY in your actual project.

How it works

The fallback route’s WHEN is a quoted natural-language condition, evaluated only when neither deterministic route above it matched.
EXPECT_RETURN: true makes Fallback_Triage_Agent a temporary child: it gathers clarified_intent from the user, then its COMPLETE fires once that field IS SET.
ON_RETURN.action: resume_intent tells the supervisor to resume routing after the child returns. MAP: { clarified_intent: clarified_intent } copies the child’s gathered value (left side, child key) into the parent supervisor’s own clarified_intent session variable (right side, parent key) — declared here in the supervisor’s own MEMORY.SESSION.
If you don’t need to map any fields back — the fallback child only needs to signal “done, try routing again” — you can use the simpler shorthand ON_RETURN: "resume_intent" instead of the structured action/MAP block.
Since HISTORY is omitted from every HANDOFF, each child (including the fallback) receives the full conversation history by default.

Common variations

Clarify and return to the supervisor (shown above).
Complete unsupported requests directly in the fallback agent with a safe explanation, without ever returning to the supervisor (EXPECT_RETURN: false, or omit ON_RETURN and let the fallback’s own COMPLETE end the conversation).
Escalate to a human after repeated clarification failures instead of looping the fallback indefinitely.
Use the plain string shorthand ON_RETURN: "resume_intent" when the fallback child doesn’t need to map any fields back.

Verification

Parse and compile the ABL and confirm there are no parser or compiler errors/warnings.
Test at least one matching utterance for each specialist route and one clearly ambiguous utterance that should hit the fallback.
Confirm the fallback’s COMPLETE fires once clarified_intent IS SET, and that the parent’s clarified_intent reflects the child’s gathered value after return.
Inspect the trace for the selected target, the evaluated condition (matches your literal authored text for the deterministic routes), and the ON_RETURN/MAP application on return.

Production readiness checklist

Every specialist route has a clear owner and a concise context summary.
The fallback’s MAP targets a variable the parent actually declares and routes on next turn.
Semantic conditions are quoted as natural-language WHEN text.
Fallback behavior is explicit and does not hide missing intent coverage — use trace review to find requests that keep landing in fallback and add real routes for them.
Any variable assumed to already exist (like customer_id above) has a real declared source in your project.

Common mistakes

Mistake	Why it happens	How to avoid it
Using literal `true` as the only route	Looks like a simple catch-all	Only do this intentionally, and document that it’s a deliberate catch-all, not a missing condition
Mapping a clarified field the fallback child never produces	`MAP` target doesn’t match anything the child’s `GATHER`/`COMPLETE` actually sets	Confirm the child key in `MAP` matches a field the child truly returns
Letting fallback silently absorb missing intent coverage	Fallback “just works” so gaps go unnoticed	Review fallback-route traces periodically and add real specialist routes for recurring patterns

Troubleshooting

Symptom	Likely cause	What to check
The parent’s `clarified_intent` is never updated after the fallback returns	`MAP` key mismatch, or the child never actually sets the mapped field	Confirm child-side field name in `MAP` matches what `GATHER`/`COMPLETE` produces
Routing doesn’t resume after the fallback returns	`ON_RETURN.action` isn’t `resume_intent`, or `EXPECT_RETURN` was `false`	Confirm `EXPECT_RETURN: true` and `ACTION: resume_intent` are both set
A specialist route unexpectedly falls through to the fallback	The referenced field wasn’t populated yet, or the condition evaluated differently than expected	Inspect the trace’s evaluated condition and `evaluatedContext`
Child agent has more/less conversation context than expected	`HISTORY` omitted; current default (`full`) applied	Set an explicit `HISTORY` strategy if bounded/summary history is intended

​Concept

​Minimal working example

​How it works

​Common variations

​Verification

​Production readiness checklist

​Common mistakes

​Troubleshooting

​Related articles