Support Ticket Triage Agent Blueprint

The first five minutes of a support ticket decide how the rest of it goes, and in most queues those five minutes are done by hand, differently on every shift. Someone reads the message, works out what kind of problem it is, decides how urgent it feels, and picks a queue. A password question from a calm customer and a furious note that mentions lawyers can land in the same pile, in the same order, while the message that quietly reports an outage waits behind both.

Automating that step badly is worse than not automating it. A system that labels tickets with total confidence will misroute the hard ones at scale, and a system that replies on its own will eventually send the wrong words to exactly the wrong customer. So this open blueprint, the Support Ticket Triage Agent, takes a narrower job: it does the first five minutes as decisions, shows its working, and stops at the agent's gate. It has never sent a message to a customer. It is built so that it can't.

One honesty note before the machinery. Every ticket, customer and metric in the repository is synthetic, the routing rules are samples, and the agent has never touched a real support queue. It is a reference prototype. The architecture and the code are the deliverable, and both are public.

Decisions, not drafts

The engine never writes prose for the pipeline. For each ticket it answers a fixed set of plain questions: what kind of problem is this, which product does it touch, how urgent is it, how likely is this customer to churn, does it contain personal data, is it abusive, does it mention legal action, is it reporting an outage, does it need an engineer. The lead engine answering them is TypeSafe's Jev, a specialist model built only for decisions like these. Every answer comes back as a probability with room for doubt, not a label. A ticket can be mostly a billing question and partly an account problem, and that split survives into everything that follows.

Software, not the model, turns those answers into a priority and a queue. The scoring formula is written down in one place, and every ticket's record shows the arithmetic: which answers pushed the priority up, which pulled it down, and what the final number was. Routing follows a written table, with hard overrides that no score can outvote: a legal mention goes to compliance, an outage report goes to the incident queue, a ticket that needs engineering goes to engineering. When the score and an override disagree, the override wins, and the record says it happened.

The last check is the guardrails, and they are rules, not requests. If the answer to a question that decides the route is close to a coin flip, the ticket is marked for human review instead of being guessed into a queue. Tickets are also screened as untrusted text the moment they arrive, because customers write them: a sentence instructing the system to mark the ticket low priority and move on is flagged and fenced off as data, and the ticket is triaged on its substance. A duplicate check runs alongside, linking a re-sent ticket to the original instead of opening a second thread on the same problem.

The line it cannot cross

Every ticket ends in the same state: waiting for a named agent, with its scores, route and reasoning on the record. Nothing in the system can send, close, or promise anything to a customer. That boundary is the design, not a setting.

One narrow exception proves it. For the safest slice of the queue, a routine how-to question from a healthy account, answered with high confidence and carrying no safety flags, the system may prepare a first-response draft from an approved template. The draft still waits. An agent reads it, edits it and sends it, or bins it. The templates themselves are governed like policy: versioned, owned, promoted by a named approver who is not their author, and watched by their own results. When a template's replies stop resolving tickets, the numbers flag it for retirement, and a person decides whether it goes.

When fifty tickets are one incident

Queues fail in a particular way during an outage: the same failure arrives fifty times in fifty different wordings, and fifty agents start fifty separate investigations. The blueprint watches for that shape. When enough similar tickets land close together, it proposes them as one incident, with the evidence on the record. A person confirms or dismisses the proposal. Nothing is merged silently, no ticket is closed by association, and a dismissed grouping that gains another member comes back for a second look.

Reopened tickets get the same respect for history. A reply on a closed ticket reopens the thread with the whole conversation attached, so whoever picks it up sees what was tried before, and the customer's own words stay fenced as untrusted text even then. The customer's record travels with the ticket too: their earlier tickets, the account's standing, and what the system previously got right or wrong about them, all visible to the agent who decides.

The desk can check its own numbers

Triage quality usually gets argued from anecdotes. This blueprint keeps score instead. Every prediction is recorded, and when the outcome is known the two are compared: when the system said a ticket was highly likely to breach its response target, did roughly that share actually breach? A calibration report answers that per queue, and a drift watch flags when the answers stop matching reality, because a router that has quietly gone wrong is worse than one that was never trusted.

The clocks are kept by software too, against response targets set per priority. A breach watch ranks the open queue by time actually left, not by how worried anyone feels, and a lead can reassign from it with a reason on the record. At period end the desk gets an attainment report with honest denominators: tickets decided in the period, how many met their target, how many breached, and the ones still open listed as open, never quietly counted as met. Shift handoffs are composed from those same figures, so the incoming lead inherits numbers, not impressions.

None of this belongs to support alone, either. A SaaS company's desk asks its questions about plans and integrations, a logistics firm's about shipments and warehouses, a finance team's about accounts and payments — but the shape of the work is the same: read the request, score and route it by written rules, hold the risky ones for a person. Any operation that starts its morning sorting a pile of unstructured requests by hand is running the same first five minutes.

What the evals prove, and what they don't

The evaluation set is a set of synthetic tickets the builders wrote: routine questions, duplicates, reopens, instruction-injection attempts, outage floods, abusive messages, the works. The blueprint passes every one of them. Two reviewers independently scoring the same tickets are also compared against each other, so the desk can measure agreement between its own people — a rubric two leads apply differently is a routing problem too.

Read that set for what it is. These are cases the builders wrote, covering traps the builders thought of, so passing all of them means the code still passes its own known cases. It is a regression gate, not an accuracy claim about your queue. The discipline that makes it worth anything is unglamorous: when triage gets a ticket wrong in a new way, the case goes into the set first, then the behaviour changes.

Honest limits

The decision step is a component that can be swapped. The lead profile is a specialist model built only for decisions, TypeSafe's Jev, which is in early access, so live verification against it is still pending; general-purpose models answer the same questions today, and a built-in fallback keeps the pipeline running with no model connected at all. The fallback is honest about its weakness: it hedges on categories more than a connected model does, and the calibration report shows by how much. The scoring weights and the routing table are samples, written to be replaced with a desk's own in the first week of a real deployment. And the agent reads the ticket as written. A customer who describes the wrong problem gets a well-reasoned route to the wrong queue, which is precisely why the last step belongs to a person.

Work with us. If your support queue spends its mornings on the same first five minutes, start with Trida AI's intake: few questions, then a conversation with the founders and engineers who would build it.

Get the Code on GitHub: github.com/tridaai/blueprint-support-ticket-triage