Topic 58

Sundry: Triage and Specialists

Case Study

The split that worked at Sundry was not a team of role-players. It is a cheap triage agent that classifies every ticket and answers the simple majority itself, plus two specialists — returns and damage claims — each with a narrow tool list and a prompt written for one kind of work. It shipped, it is still running, and the conditions for taking it out again are written down.

Here are the numbers, including the one that got worse. Cost per ticket went up 11%, and no amount of enthusiasm about the architecture changes that.

The split that shipped, with the three numbers that got better and the one that did not
Every ticketone owner, start to finish
Triagesmall fast model · 4 tools, none move money
55% END HEREAnswered at triagep95 to a first useful message 21 s → 12 s
45% HANDED OFFReturns or damage specialist7 tools each · wrong tool calls 14% → 7%
NOT A SAVING$0.11 → $0.12handle time 34 s → 19 s, and this is the bill for it

The Shape

Triage runs on a small fast model with four tools, none of which moves money: search_orders, get_order, track_parcel and escalate_to_human. It classifies the ticket, and for the 55% of the queue that is order status and delivery it answers directly from a template, exactly as the routing table in Chapter 7 already did. Anything it cannot finish gets a handoff object and an owner change: returns and refunds, and the product questions that turn on a policy clause, go to the returns specialist; damage claims and Chapter 7's unenumerable residual go to the damage specialist.

The returns specialist carries seven tools — triage's four plus search_policy, start_return and issue_refund — and runs inside the five-state machine from Chapter 7, so its phases and its guards are unchanged. The damage specialist carries seven as well, swapping the two return tools for message_seller and offer_replacement, because its work is establishing seller liability rather than processing a return. Escalation is on every agent's list at every level, and the $150 approval ceiling lives in the dispatcher rather than in any agent, so it does not multiply with the number of agents that can reach a payment.

Why This Split Is Justified

Three arguments, and all three are context arguments rather than role arguments. Narrower tool lists select better: Chapter 3 measured 97% correct first calls on four tools against 93% on nine, and the specialists at seven tools land at 96% across the returns flow. Smaller contexts hold quality on long tickets, which is the whole of Chapter 5. And the 55% majority never loads the specialist machinery at all — no policy retriever, no state machine, no money tools within reach on the turn where the agent is working out which parcel a buyer means.

That last one is worth separating from the performance argument, because it is a security property that shows up in no latency chart. The tickets that carry no money now run through a configuration that physically cannot move any, and Chapter 12's job gets smaller by exactly the share of the queue that never touches a write tool.

The Numbers

Both configurations ran against the 120-ticket eval set and against a week of production traffic, and the eval report is the five numbers from Chapter 9 with the queue's own handle time added.

MeasureOne agentTriage + specialistsReading
Handle time, median34 s19 sThe reason it shipped
p95 to first useful message21 s12 sTriage answers without loading the specialists
Resolution, 120-ticket set86%88%Two points — inside the noise, not evidence
Runs with a wrong tool call14%7%Measured on the 200-ticket labelled set
Cost per ticket$0.11$0.12Up 11%, from handoff overhead
Invariant violations00Blocking either way, unchanged

The honest reading starts with the row everyone wants to quote. Resolution moved two points, and two points on a 120-case set is about two and a half tickets changing verdict, which is inside the band Chapter 9 measured on the unchanged agent. This set detects a seven-point change and cannot see a two-point one. So the correct statement is not "resolution improved slightly" — it is that the outcome number says nothing, in either direction, about this split.

What the split actually bought is on the first two rows: handle time nearly halved, and the p95 to a first useful message came down to twelve seconds. That is a product improvement a customer can feel, and it is the argument that shipped. The quality claim, such as it is, rests on the fourth row rather than the third: wrong tool calls per run halved on a 200-ticket labelled set, where the effect is large and the noise is small. That is Chapter 9's own advice taken literally — when the headline set cannot see the effect, measure the mechanism the change targets on a set built for it.

And the split costs money. Every handed-off ticket pays the specialist's own prompt and schemas on each of its turns, plus the envelope and the summary, which came to about 2,600 extra billed input tokens on the 45% of tickets that leave triage — 11% on the blended average, taking cost per ticket from 10.9 cents to 12.1 — the $0.11 and $0.12 the chain reports, rounded. This is not a saving and must never be reported as one. Chapter 13 gets to six cents a ticket from here, and this split made that distance longer, not shorter.

What Broke

Multi-intent tickets, immediately, and in the worst possible way: silently. The canonical ticket is one — a cracked side panel on order SU-88421 and a duplicate delivery charge in the same paragraph. Triage split it, sent the damage half to the damage specialist and the billing half to the returns specialist, and each of them resolved its half competently and marked the ticket done. The $9.95 delivery charge was never refunded, and the ticket closed as a success twice. Fourteen tickets went out that way in nine days before a buyer's second complaint made it visible.

The fix was an ownership rule, not more agents. One owner per ticket, holding the subtask list from Chapter 7, and a ticket cannot close while any subtask is open. A second specialist is now a consult: it receives an envelope, returns a finding, and never becomes a co-owner. That is the single-owner rule the handoffs topic set down, and it is the rule that makes multi-agent work at all — several agents may touch a ticket, but exactly one of them is answerable for it at any moment.

What Was Rejected

A critic agent reviewing every outbound reply was built, measured and deleted. Across the 120-ticket set it changed five replies. Three of those were things the deterministic checks from Chapter 9 already blocked before a customer saw them — a missing policy citation, an amount above the ceiling, a reply containing an order id belonging to somebody else. The other two were wording preferences. For that it added about $0.02 and six seconds to every ticket in the queue, including the 55% that were already correct and already fast. The grounded critique before money moves stayed, because it was measured on the decisions that actually carry risk and earns its place there; the version that reviews everything does not.

A planner agent was rejected for a duller reason: the returns flow already had one. The five-state machine fixes the phases and guards the transition where money crosses, so a planner's output was a plan the machine then re-derived from its own state. Measured, it moved nothing on the eval set, added one model call and 0.9 seconds, and gave the team a second place to look when a run went sideways. Two components with the same job is worse than either component alone.

Conditions for Merging Back

Four conditions are written next to the routing code, and the comparison is re-run every quarter with both configurations still in the eval pipeline. If the triage-answerable share of the queue falls below 40% — it is 55% today — the routing serves a minority while every ticket still pays the handoff. If a model handles the full nine-tool surface at the accuracy the specialists get on seven, the narrow-list argument disappears and the split becomes overhead with a diagram. If handle time stops being the binding constraint, fifteen seconds is not worth 11% on every ticket. And if multi-intent tickets rise past 15% of the queue — they are 9% now — the ownership machinery costs more than the routing saves.

Writing those down is the part of this topic worth copying. An architecture with no stated expiry conditions is one that survives its own justification, and the next team inherits a shape nobody can argue with because nobody remembers what it was for. Merging back at Sundry is a configuration change and one afternoon of eval runs, which is the only reason the question can be asked seriously every three months.

Common Mistakes
  • Presenting the two-point resolution gain as the reason for the split — it is inside the noise band of a 120-case set, and the real win was latency, which the same report measured cleanly.
  • Splitting a multi-intent ticket across two specialists without an owner — each half is resolved competently, the ticket closes as done twice, and a $9.95 charge nobody refunded surfaces nine days later.
  • Adding a critic agent because it is a known pattern — measured, it changed five replies out of 120 and three of those were already blocked by two-line assertions.
  • Keeping the split after its justifying conditions change — a queue mix that shifts or a model that handles nine tools well turns the whole arrangement into overhead nobody re-measures.
Best Practices
  • Justify each agent by the specific number it moves, name that number in the design note, and report the numbers it made worse in the same paragraph.
  • Give each agent the narrowest tool list that lets it finish its own work, and keep the money ceiling in the dispatcher so it does not multiply with agents.
  • Assign exactly one owner per ticket even when several agents touch it, and block closure while any subtask is still open.
  • Write the conditions under which the architecture should be reconsidered, re-run the comparison on a schedule, and keep merging back a configuration change rather than a project.
Comparable toolsTiered helpdesks the human version of the same argumentFramework routers classification plus dispatch as a primitiveLangGraph the router and specialists as explicit nodesYour eval report the artefact the decision was made on

Knowledge Check

Which reading of Sundry's split is the honest one?

  • It bought latency and paid 11% more per ticket, with the resolution move too small to mean anything
  • It bought both speed and savings, since the narrower prompts made each specialist cheaper to run per turn
  • It bought a genuine quality gain, since resolution rose from 86% to 88% across the whole eval set
  • It bought nothing measurable at all, since every number in the report moved by less than its own noise band

What makes triage-plus-specialists different from a researcher-writer-critic team?

  • Each agent's justification is a measured tool-list and context effect rather than a job title in a prompt
  • It uses three agents rather than three plus an orchestrator above them, so there are fewer boundaries to cross
  • It passes structured state between the agents, which a team of role-players is unable to do by construction
  • It puts a small fast model in front, which is what makes the arrangement pay for itself

The cracked-panel ticket also carries a duplicate delivery charge. What went wrong when triage split it across two specialists?

  • Each specialist resolved its own half and marked the ticket done, so an unrefunded charge closed as a success
  • Both specialists refunded the delivery charge, and the buyer received the same $9.95 twice over
  • The two specialists passed the ticket back and forth until the turn limit ended the run
  • Triage misclassified the ticket as damage-only, so the billing intent was never seen by any agent

Why was the critic agent rejected while the grounded critique before money moves was kept?

  • It mostly repeated the deterministic checks, and charged every ticket $0.02 and six seconds for two wording changes
  • It graded work produced by the very same model family, so its approvals came back inflated and unusable
  • It had no tools of its own, so it could not check any claim it was reviewing against a source
  • It rejected too many correct replies, and the false-rejection rate made the queue slower for customers

Sundry wrote four conditions under which it would merge the agents back into one. What is that for?

  • So the decision stays revisitable, because the facts that justified the split will not hold forever
  • So the system reconfigures itself automatically once one of the four conditions is detected in production
  • So there is a rollback path on the day the specialists cause an incident in production
  • So the architecture can be signed off by a compliance reviewer who needs a documented exit

You got correct