What role does a triage agent play in a handoff-based support swarm?
answer
- the swarm's front door
- classify, do not resolve
- keep its tool list nearly empty
- cheap model, short prompt
- needs an I-cannot-tell destination
basics
~20 sA triage agent is the swarm's front door. It holds the opening turns, works out what the customer actually needs, and then transfers the conversation to the specialist peer that owns that need instead of answering itself.
solid answer
~50 sIn a swarm, every agent can transfer the conversation to a peer, and the triage agent is simply the one that starts holding it. Its job is classification, not resolution: gather just enough from the customer to decide which specialist owns the problem, then call the transfer tool for that peer. In a mobile-carrier support swarm, triage decides between billing, device repair and retention, and hands over. The design consequence is that triage should be **deliberately thin** — a short prompt, a narrow set of transfer tools, and almost no domain tools of its own. Giving it the specialists' tools tempts it to half-solve the problem and produces answers with none of the specialist's guardrails. A good triage agent is also allowed to say it cannot place the request, and escalate to a human rather than guess a destination.
go deeper
Be able to say plainly that the triage agent is the entry point of a swarm and that its job is to classify the request and transfer it, not to solve it.
Explain the design discipline: a short prompt, transfer tools only, a cheap model, and an explicit fallback destination for requests it cannot place. Say why giving triage domain tools backfires.
Show you would instrument it — first-hop routing accuracy, hop count, per-destination confusion — and discuss the trade-off between asking more up front and routing faster with less information.
Own the question of whether triage should exist at all: a menu, a classifier model or a deterministic rule table may beat an LLM front door on cost and predictability, and the answer depends on how ambiguous real user phrasing is in your product.
## What triage means in a swarm A handoff swarm is a set of peer agents where any agent can pass control of the live conversation to another by calling a transfer tool. There is no central router sitting above them deciding each turn. But a conversation still has to *start* somewhere, and the agent that receives the first user turn is the triage agent (sometimes called the front-door or intake agent). Triage is a role, not a special mechanism. It uses exactly the same transfer primitive every other agent uses. What distinguishes it is scope: its purpose is to decide *who* should handle this, not to handle it. ## Why the role exists at all Users do not open a conversation with a well-formed request. "My bill is wrong and my phone keeps dropping calls" contains a billing intent and a device intent. A single mega-agent that owned billing, repair and retention would need every tool and every policy in one prompt — which is where tool-selection accuracy degrades and instructions get forgotten. Splitting into specialists keeps each prompt small and each tool set narrow; triage is the price you pay for that split, because someone has to make the first routing decision. ## What a good triage agent looks like **Thin prompt.** Its instructions describe the destinations and the signals that distinguish them, not the domains themselves. It does not need to know refund policy; it needs to know that refunds live in billing. **Almost no domain tools.** The classic mistake is giving triage the specialists' tools "just in case". It will then answer a billing question directly, without the billing agent's policy text, disclaimers or authorization checks. If triage can act, it will act. Restrict it to transfer tools plus, at most, cheap identity lookup. **Cheap model.** Classification is the easiest job in the system, so triage is a natural place to run a smaller, faster model and reserve the frontier model for the specialist that does the real work. **An explicit fallback.** There must be a destination for "I cannot tell" — a human queue or a generalist agent. Without one, an unclassifiable request gets forced into the nearest specialist, which then transfers again, and you have paid two extra hops and a confused customer. **Minimal collection.** Triage should ask only what changes the routing decision. Asking for an account number, a device model and a contract date before deciding where to send someone is a bad experience and, in a swarm, often wasted — the specialist may re-verify anyway. ## Triage in a swarm versus triage under an orchestrator In a swarm, triage's authority ends the moment it transfers. It does not get the conversation back, it does not supervise, and it does not see what the billing agent does afterwards. The specialist that receives control is free to transfer onward to another peer — billing to retention, say — without triage's involvement. That is the defining property of the topology, and it means triage's misclassifications are *recoverable*: the receiving specialist notices the mismatch and forwards. The cost is an extra hop and some latency, not a dead end. That recoverability is also the trap. Because a wrong route self-heals, teams stop measuring it. You should still instrument first-hop accuracy — the share of conversations whose first transfer was the final one — because a triage agent that is right 60% of the time doubles the cost and roughly doubles the time-to-first-useful-answer for four conversations in ten. ## Common failure modes - **Triage answers the question.** Symptom: customers get billing answers with no policy citation. Cause: triage was given billing tools or a prompt that says "help the customer". - **Triage interrogates.** It collects a full profile before routing. Fix: list, per destination, the minimum signal needed to choose it. - **No unknown bucket.** Every request is forced somewhere. Fix: an explicit human-escalation destination. - **Triage as a bottleneck by accident.** Some teams route every subsequent turn back through triage. That is no longer a swarm — it is a central router with extra steps, and it should be designed as one deliberately if that is what you want. ## What to say in an interview Define triage as the entry agent of a decentralized swarm; stress that it classifies rather than resolves; explain the thin-prompt and no-domain-tools discipline; and name first-hop routing accuracy as the metric you would watch. Mentioning the unknown/escalation destination signals that you have actually operated one of these.
- Why not just skip triage and let the customer pick the specialist from a menu?You can, and for narrow products a menu is cheaper and more predictable. Triage earns its place when intents are ambiguous, overlapping or phrased in the user's own words — "my bill is wrong since I changed phones" fits no menu item cleanly. A hybrid is common: a menu for the obvious cases, triage for free-text entry.
- What metric would you watch to know triage is doing its job?First-hop routing accuracy: the share of conversations where the first transfer was also the last. Pair it with the average hop count per conversation and with per-destination confusion — knowing that device-repair requests keep landing in billing tells you which prompt line to fix, where a single accuracy number does not.
- Should triage stay in the conversation after transferring?In a swarm, no — that is the point of the topology. Control moves to the specialist and triage is out. If you want triage to keep supervising and reclaim control each turn, you have chosen a centralized router instead, and you should adopt its trade-offs deliberately rather than by drift.
Triage is the receptionist at a clinic: they take your name, work out which department you need, and walk you to that door. A receptionist who starts prescribing is the problem, not the plan.
saying these in an interview costs you the question
- Says triage should answer simple questions itself to save a hop
- Gives the triage agent every specialist's tools as a fallback
- Assumes triage supervises the conversation after handing off
- Has triage collect full customer details before routing
- Ignores the need for an unknown or human-escalation destination