The queue is sorted by severity
Every ticket arrives already read, tagged and ranked, so the first hour of the day is spent on the worst one rather than on finding it.
Support triage
An agent reads the ticket, checks who sent it, and either answers in the thread or opens a case with the evidence already attached — so a reviewer makes a judgment instead of an investigation.
The problem
Every support queue is sorted by the one thing that does not matter — when the ticket arrived. The thing that does matter, how bad it is, is sitting in the ticket body in a customer’s own words, and reading it is the first hour of somebody’s day.
Keyword rules do not survive it. "Charged twice" and "paid for the same thing on two cards" are the same problem and share no words. What is needed is something that reads, and something that can be held to a fixed output shape once it has.
What the flow looks like
Numbered because the order is the execution order, not because it is a list. However many steps it has, the whole thing is one run.
Your helpdesk, your shared inbox or your in-app form posts to a URL and the run starts. Nothing waits for a poll.
An agent with a standing brief, a set of tools it may use, and a required output shape — severity, product area, a one-line summary. A response that does not match the schema is retried, not passed on.
Plan, tenure, open incidents and earlier tickets. Severity is not a property of the message alone; the same complaint from a trial and from your largest account are different tickets.
What counts as urgent, written where the support lead can read and change it — not inside a helpdesk’s automation tab and a Slack workflow at the same time.
Urgent goes to a queue with a person on it. Standard gets an acknowledgement and a tag. Each branch is explicit, so the reason a ticket was not escalated is a path, not a guess.
The reviewer gets a case carrying the summary, the customer record and the earlier tickets. The run does not wait for them — it carries on to its last step.
Reply in the Slack thread, tag the ticket in your helpdesk, and post the urgent ones where the on-call person actually looks.
Severity, area and summary go back in the response, so your helpdesk can store the same values the flow decided on.
What the flow can reach
A Connection node calls one of 52 packaged providers, or any HTTPS or JSON API you have credentials for. Six databases connect directly. Every call happens inside the run, with your credentials, and lands on the same trace as the rest of it.
What changes
Every ticket arrives already read, tagged and ranked, so the first hour of the day is spent on the worst one rather than on finding it.
Every iteration, tool call and retry is recorded with its tokens, its latency and its cost. When a ticket is mis-triaged you can open the run and see what the model was given and what it returned.
A case carries the summary, the customer record and the earlier cases. The reviewer decides; they do not go looking.
Questions
A required output schema. An AI step and an Agent both declare the exact fields they must return, and a response that does not match is retried rather than passed to the next node. The next step branches on a value, never on a paragraph.
No, and that is the difference between the two human-in-the-loop nodes. A Create Case node opens a case in a queue and the run carries on to its last step. A Manual Review node is the one that pauses the run and resumes it from the same node once the reviewer answers.
Yes, per run. The run records iterations, tokens in and out, latency per step and the cost of the whole thing, and the workspace’s AI usage page totals it. An agent is a step you can put a number against.
Ready when you are
Build the flow in Sandbox, run your own cases through it, and read the trace before anything reaches a customer.