Chaining specialists

A chain is a deliberate sequence of specialists for a known, ordered workflow. Each specialist completes its task and, as its success signal, emits the next specialist’s token — handing the visitor straight on to an agent with a follow-on job. (New to routing tokens? Read multi-agent routing first.)

When to chain

Chain when the journey is predictable and ordered — you know what task comes first, what “done” looks like, and which task follows. Each link stays small and does one job well, and the visitor experiences one continuous conversation. If instead visitors arrive with unpredictable needs and you’re choosing between several specialists, that’s a front-door problem — use a concierge.

Two properties make chains feel seamless:

• No concierge is involved. The handoff is the designed outcome, written into each prompt as a clear success condition — the visitor simply sees the conversation continue.
• The whole conversation travels with the visitor, so the next link picks up the thread — names, details, decisions — without a recap.

Routing forward from a specialist

The handoff isn’t an exception — it’s the finish line. When a link completes its task, its success message is the next specialist’s bare token. Three rules:

1. Make “done” concrete. The prompt must state exactly what task completion looks like — e.g. “you have the visitor’s name, email and preferred date” — so the model knows the precise moment to hand on, and doesn’t jump early.
2. No announcement, no farewell. Exactly as with routing back in a cluster, the token stands alone as the very first thing in the reply (no summary or goodbye wrapped around it) — moving on is the successful outcome, and the next agent sees the conversation so far, so it picks up the thread without a recap.
3. Forward only on success. The forward token is reserved for the completed-task handoff. An out-of-remit request mid-task is a routing-back problem — never route it sideways to the next link.

Drop a <forward_routing> block like this into each chain link, filling in the success condition and the next agent:

<forward_routing>Your task is complete when [concrete success condition — e.g.
you have collected the visitor's name, email address and preferred date]. At
that exact point, your entire reply is the token #[next-agent]# and nothing
else — no summary, farewell, explanation or punctuation. This silently hands
the visitor to [next-agent], which [what it does next — e.g. books the
appointment]; the visitor simply sees the conversation continue.

Do not announce the handoff or ask permission — handing on is the successful
outcome of this conversation, not a transfer away from it. The next agent can
see the conversation so far, so do not recap or restate what you've gathered.

Until the condition is met, keep working the task: do not emit the token early,
and never emit it because a request is out of scope — out-of-scope requests
follow your return-routing rules instead.</forward_routing>

A worked example: intake, check, confirm

A three-link chain for a long intake — a registration, application or booking questionnaire with lots of questions. Splitting it keeps each prompt small and single-minded: the asker isn’t also burdened with auditing, and the audit isn’t done by the agent that might have skipped the question in the first place.

1. The intake specialist works through the question list conversationally, a couple at a time, adapting to how the visitor answers. Its success condition: every question on its list has an answer. At that point its entire reply is #completeness-check#.
2. The completeness checker is a finishing inspector: it reads the whole conversation against the required list. If anything is missing or ambiguous, it asks for just those pieces — nothing else. The moment nothing is missing, its success message is #confirmation#.
3. The confirmation specialist plays everything back to the visitor as a structured, clearly labelled summary — name, contact details, answers grouped under headings — and asks them to confirm it’s correct. If they correct something, it updates the summary and asks again; only on an explicit “yes, that’s right” does it close out (or hand back to a concierge, if one fronts the chain).

Notice how this sits inside the hop budget: intake’s handoff is hop one, and when the checker finds nothing missing, its immediate forward to confirmation is hop two — the visitor sees one seamless reply. The checker forwarding straight away isn’t a wasted link: the verification is its work, whether the output is a follow-up question or the token.

Mixing with a concierge

Chains and clusters combine happily. A chain can sit behind a concierge: the concierge routes the visitor into the first link, and the final link hands back with the concierge’s token when the sequence is done. The rule of thumb: route back through a concierge when a request has drifted outside a specialist’s remit, and route forward to a named specialist when your workflow says “this task is done, the next begins”.

A quick checklist

• Every link’s <forward_routing> states a concrete success condition — the model knows exactly when to hand on.
• The forward token is emitted alone, on completion only — no farewell, no summary, never early, never for out-of-scope requests.
• Each link does real conversational work before handing on (the two-hop budget rules out links that only forward).
• Every #next-agent# reference names a real, live agent (slugs kept in step after renames).
• If the chain sits behind a concierge, the final link hands back with the concierge’s token; mid-chain out-of-remit requests follow the routing-back pattern, not a sideways hop.
• Sensitive or safety-critical messages are handled in place, never routed away.

Fielding unpredictable visitors instead of a fixed workflow? See using a concierge. Want a complete specialist to adapt? See the starter cluster.