How we get urgent support tickets to the right team
The ticket that should skip the queue rarely looks special at first glance. You only spot it when you read carefully: the SLA timer with minutes left, the sender who turns out to be one of our largest customers, the "small bug" that is really the whole product being down. On a hectic day, those tickets wait their turn in arrival order like everything else. And whoever is meant to spot and route them is busy answering the queue themselves.
So we run an escalation agent on Machine. Every 15 minutes it looks through the Plain queue, picks out the tickets that match our escalation rules, hands each to the internal team that owns it, files a connected Linear issue if engineers need to get involved, and posts the lot to our escalation channel in Slack. Routing, linking and flagging is the whole job. Closing tickets is not part of it, and neither is telling a customer how or by when their problem gets fixed.
The problem
Tickets that deserve escalating do not wave a flag. Spotting an SLA breach means someone actually comparing timestamps. Knowing an account is a VIP means looking it up in a sheet or your CRM, because the ticket will not tell you. Judging severity means reading what the customer wrote, not just glancing at the tags. Any one of these slips by easily when the inbox moves so quickly that nearly everything is answered first come, first served.
The usual safety net is a teammate who glances over the queue now and then for anything alarming, while also working through their own tickets. That holds up until the day gets busy. Then the ticket about to breach its SLA and the VIP's ticket sit behind ten routine questions, and a bug report that should be a Linear issue by now is still a few lines in a support conversation no engineer has opened.
What we built
Every 15 minutes, a cron job on Machine starts a new agent session: a fresh cloud computer (a sandbox) for that run alone. The agent reads the Plain queue as it is right now and tests every open ticket against three rules: has it breached its SLA, is it a VIP account, is it high severity. Anything that passes a rule goes to whichever internal team owns it. If engineers are needed, the agent also files a Linear issue tied to the ticket. Then it drops one Slack message per escalation into the escalation channel, giving the reason, the team and the issue link. It does not close tickets, and it does not say a word to the customer.
How it works
Start fresh every 15 minutes
A cron trigger goes off every 15 minutes, and each time a new session starts with no recollection of the previous run. The agent checks the whole open queue against Plain as it is now, instead of relying on what it decided a quarter of an hour ago. No state is carried over, so stale notes can never cause a miss.
Write down your escalation rules
What counts as an escalation is kept as a skill, the playbook the agent follows. It holds the SLA target for each severity level, the accounts we treat as VIPs, where the high-severity line sits, and a lookup that maps each kind of ticket to its owning team. Tighten an SLA or name a new VIP, edit the skill, and the very next check picks it up.
Connect the queue, the tracker and the channel
Connectors and secrets give the agent scoped access to your tools. The keys are handled on our servers, so the model never holds a raw credential. With them the agent:
- Sorts the Plain queue: fetches every open ticket, looks at SLA clocks and account details, and tags or assigns the ones that qualify to the internal team that owns them. Closing or resolving a ticket is not something it can do.
- Ties in Linear: if a ticket calls for engineering, it creates an issue on that team's board carrying the ticket's background, then cross-links ticket and issue so either one leads to the other.
- Flags it in Slack: one message per escalation in the escalation channel, naming the ticket, why it was escalated, which team now has it, and the Linear link if there is one.
Draw the lines it cannot cross
In Plain the agent can route, not resolve. Tagging and assigning a ticket are allowed. Closing one or marking it resolved is not. It never writes to the customer or sends them anything, and it never states or hints at when a fix will arrive. Its output is three things only: the routing change in Plain, the Linear issue tied to the ticket and the Slack message.
Route it, link it, flag it
Once this runs, the queue is checked every 15 minutes against the live SLA clock, the latest VIP list and how severe each open ticket is right now. Any ticket that passes a rule lands with its owning team, picks up a Linear issue if engineers should see it, and shows up in the escalation channel along with why. What happens next is up to your team.
The pattern
Every 15 minutes a cron opens a fresh session that checks the Plain queue against SLA targets, VIP names and a severity line, all set in a skill. Qualifying tickets get routed, engineering ones get a linked Linear issue, and Slack hears about each. Tickets stay open, and customers are promised nothing.
Guardrails
This agent can make changes in both the support inbox and the engineering tracker, so we fence its powers in at sorting and flagging:
- Isolation. Each run happens in a private sandbox. The session can reach Plain, Linear and the escalation Slack channel, and nothing beyond them.
- Scoped secrets. Our Plain key sits encrypted in the Secrets Manager until a run begins, when it is passed into the sandbox. Linear goes through a connector on our servers. Every secret is only handed to the agents you grant it to.
- Routing only, never resolving. Tagging, assigning and filing a tied Linear issue are all it can do. Closing a ticket, marking it resolved or anything else that ends the customer's case is beyond it.
- Nothing promised to customers. It never writes or sends a message the customer will see, and it never names a fix date. All of its output stays inside the company: a routing tag, a Linear issue and a Slack message.
- Everything is code. SLA targets, VIP names, the severity line and the team lookup all live as files in the repo, kept in version control. Changing them takes a reviewed change request, not a dashboard setting.
The outcome
Urgent tickets used to wait in line until somebody happened to notice them. Now they are spotted within 15 minutes of crossing a line, sent to their owners and, when engineers are needed, already tied to a Linear issue without anyone asking. The agent sorts, links and flags. How each ticket gets solved is still your team's call.
More use cases
How we answer GDPR data-subject requests before the deadline
Our Machine agent checks each GDPR access or deletion request, finds the person's data across our product database, builds the report well within the SLA and hands it to legal before anything is sent.
How we keep our docs matching what the code does
Once a day a Machine agent reads every commit merged since its last pass, finds the doc pages those changes made wrong, rewrites them and sends you one pull request to review.
How we test every pull request without lifting a finger
Our Machine QA agent works with GitHub and our test environment. For each pull request it checks out the branch, runs the tests, tries the change for real, and posts what it found.
Put your first agentto work today.
- SSO
- RBAC
- Governed agents
- Full audit trail