AI ticket triage: draft, label, and route without losing the thread

Support triage has a shape that makes it unusually automatable: most tickets are recognizable at a glance, the correct first action is usually one of four or five things, and the cost of a wrong guess is a human glancing at a mislabeled ticket. That combination — high volume, low branching, forgiving errors — is exactly where AI earns its keep. Triage is also where AI fails visibly when it is handed the send button instead of a draft queue.

What the agent actually does

Split the work into what is mechanical and what is not. The mechanical half:

• Label and route. A billing complaint goes to the billing project; a bug report links to the issue that will fix it; a feature request becomes a proposal instead of sitting in the inbox until someone remembers it.
• Draft the first reply. The agent writes the response a competent human would write after two minutes of looking things up, including the honest “we don’t know yet, here is what we’re doing.”
• Detect the repeat. Five tickets about the same thing become one linked cluster, and the fifth person to write in gets told a fix is already in flight instead of ticket number five of a silence.

The non-mechanical half is the send. Refunds, refunds-adjacent promises, angry customers, and anything with a contract number attached stay human. Not because the model cannot produce a reply, but because the reply commits the company to something, and commitment is what the human is for.

The pattern that survives contact with reality

The loop that works is draft, apply, send — with the human in the middle, every time, until the agent has earned a narrower leash. Concretely: the agent processes the inbox each morning, files each ticket to the right project, drafts replies, and marks its confidence. A human reviews the drafts in one batch — usually faster than triaging raw, because judgment on a pre-filed ticket is quicker than judgment on a raw one — edits the third of them that need it, and sends.

The review step looks like overhead and is actually the product. It is where the team learns what the agent gets wrong (tone on bad-news replies, edge cases in routing), and the fixes are cheap: a routing rule, a snippet, a state. An agent whose errors are corrected in public stays calibrated; an agent whose errors are silently reverted stays confidently wrong.

Why it has to live in the tracker

Triage done in a chat window dies the moment the conversation scrolls. The output has to be the ticket system’s own rows — a ticket moved to “waiting on customer,” a linked issue, an SLA clock paused — because that is what the rest of the team reads tomorrow. An AI summary next to the inbox is a shadow workflow; a ticket in the right state is the workflow.

That is the difference between an assistant and a teammate: the teammate’s work is visible in the same place everyone else’s is. For where a ticket should end up, see shared inbox vs. ticketing system; for the numbers worth watching once triage is automated, read helpdesk metrics that matter. The plumbing that lets an agent file tickets in the tracker’s own states is MCP.