A customer opens the chat window: "I was charged twice for the Pro plan and the password reset email never arrived." That is two problems wearing one sentence. A single support assistant will grab the first one it recognises, answer half of it, and leave the rest to rot. The answer is not a smarter single assistant. It is a small team of narrow agents that pass a conversation between them cleanly — and the passing is the hard part.
Map the work before you build anything
Spend a week in your own support queue before you write a single prompt. Pull a few hundred real conversations and tag them. You are looking for categories, not individual tickets: billing disputes, account access, product how-to, bug reports, cancellations, pre-sales questions.
For each category, note how often it appears, how much it varies, and what it takes to resolve. A password reset is high volume and nearly identical every time. A complaint about a failed data export is low volume and different every time. The first suits an agent. The second usually does not.
Add a second column: cost of error. Getting a password reset wrong is annoying. Getting a refund wrong is money leaving the building. Rank your categories by volume multiplied by risk, then start building at the top of that list. Rare, messy categories stay with humans until you have evidence they deserve an agent.
Decide now what never gets handled without a person: security incidents, anything involving safety, anything with legal weight. If your product touches money, health, or legal matters, keep the decisions with qualified humans, and point customers to the appropriate professional when what they need is advice rather than support.
The triage agent: narrow job, strict output
Triage does four things and nothing else: it acknowledges the customer, identifies the primary intent, collects what is missing, and routes. It never tries to solve.
Give it a fixed output shape instead of free prose:
- primary_intent and secondary_intent — the second one matters when a customer mentions two problems
- urgency — is the customer blocked, or mildly inconvenienced?
- confirmed_facts — account number, order ID, the last four digits of a card
- missing_information — the one thing you still need
- destination — billing, technical, retention, or human
- confidence — plus a rule for what happens when it is low
Then write the conversational rules. Ask one question per turn, never two. Acknowledge specifically rather than generically: "That looks like a duplicate charge — I am sending you to billing" beats "I understand your frustration." And when confidence drops below your threshold, route to a human instead of guessing. A wrong guess costs more than a handoff.
Structured output is what makes everything downstream possible. A destination field your code can branch on is a routing decision. A warm paragraph of prose is a routing decision nobody can test.
The handoff contract
Define one packet structure that every agent writes and every agent reads. Same fields, every hop, no exceptions.
- The customer's original message, verbatim
- The chain so far, one line per hop
- Confirmed facts, and how they were confirmed
- What has already been promised or told to the customer
- The open question waiting for an answer
- What this agent needs the next one to do
- Sentiment and risk flags
Two failure modes show up again and again. The amnesia handoff makes the customer repeat themselves because context was dropped. The dump handoff does the opposite: the next agent greets the customer with a wall of "here is what I understood", which reads like a system log with a smile. The customer-facing side of a handoff should be one sentence; the internal side should be complete.
A handoff is a baton pass, not a summary.
One hard rule keeps this honest: an agent may never ask the customer for something already in the packet.
Specialists that stay in their lane
Each specialist gets one job, a written scope, and a written out-of-scope list. A billing specialist can explain a charge, apply a refund within policy, and update a payment method. It cannot reset a password, even if the customer asks nicely in the same message.
Decide which routes are allowed, then draw them as a graph. Triage can send anywhere. Specialists can send back to triage, or to human escalation. If every agent can talk to every other agent, you build a maze you cannot debug — the number of connections grows faster than the number of agents. Keep a hub and a few spokes until you have a real reason to change it.
Tools matter as much as prompts. Give the billing agent read access to invoices and a refund function with a cap. Do not give it the tool that deletes an account. Scope is easier to enforce in permissions than in instructions.
Escalation to a human, done warmly
Escalation is not failure; it is a designed exit. Define the triggers in advance:
- Confidence below threshold, twice in a row
- A loop — the same intent attempted twice without resolution
- An explicit request for a person
- Risk signals: threats, distress, mentions of security or account compromise
- Any category on your never-automate list
The handoff to a human should carry the same packet, plus a plain-language summary a support agent can read in five seconds. Do not make a person reconstruct what the bots already knew. And tell the customer what is happening: "I'm bringing in a colleague from billing who can look at your account" beats a silent transfer every time.
Test the handoffs, not just the agents
Most teams test each agent in isolation and then act surprised when the chain breaks. Test the seams instead. Build a small set of conversations that cross boundaries by design and run them end to end.
- A message with two intents that must be split cleanly
- A message carrying a fact already confirmed, to catch re-asking
- A message that should never be automated at all
- A message that triggers a loop, to see whether the loop breaker fires
- A message where triage is wrong, to see whether the specialist recovers or quietly complies
Score the conversation, not the reply. Did the customer repeat themselves? Did any agent speak outside its scope? Was a promise made that nobody kept? Those are the failures customers remember and the ones a single-agent evaluation will never surface.
Measure the right things, then grow slowly
Track three numbers per route rather than one overall satisfaction score. First, first-contact resolution: did the issue end without a second conversation? Second, average handoffs per resolved ticket — a rising number means your triage is getting worse, not that your specialists are busier. Third, escalation rate, split into correct escalations and lazy ones.
Read transcripts weekly and start with the longest ones. A conversation that took nine turns is usually a handoff problem, not a language problem. When you find the fix, put it in the packet or the scope rather than in a longer prompt.
The temptation is to launch a full org chart on day one. Resist it. Triage, one specialist for your highest-volume category, and a human exit will teach you more in two weeks than a six-agent build will in two months. Add a specialist only when a category's volume or cost of error justifies its own scope, its own tools, and its own tests.
An agent team is not built by adding intelligence. It is built by adding boundaries — and then making the crossings between them boring, predictable, and cheap.
Photo: Yan Krukau / Pexels
