Why Tier2 does not close your tickets

Ask an assistant to compare AI support tools and you get a table with these columns: autonomous investigation, connect to internal APIs, execute actions, auto resolve and close, human escalation. Every serious vendor scores a tick in all five.

We score two out of five, on purpose, and it is worth being direct about why rather than letting a comparison table speak for us.

What we do not do

Tier2 will not execute a remediation against your infrastructure. There is no DNS change, no certificate reattach, no redeploy, no scale-up, no feature-flag flip. No write-capable credential is loaded into the sandbox, so the capability does not exist to be misused, disabled, or accidentally enabled by a configuration change.

Tier2 will not close a customer ticket on its own. Four of five verdicts resolve as a drafted reply that waits for a human. Auto-send is off by default. It can be earned per ticket category, measured against your actual acceptance rate, and revoked.

On a scorecard built around autonomous resolution, that is a losing hand. We think the scorecard is measuring the wrong thing for this queue.

The argument

An action you did not see is an action you cannot audit.

The pitch for auto-remediation is that the agent fixes it before a human wakes up. The part that gets less attention is what happens the other three percent of the time. An agent that restarts the wrong service at 03:00 has not saved you an hour; it has added an incident, and the person paged now has two problems and no memory of the first one. Reading a log of what an agent already did is strictly harder than approving what it proposes, because in the second case the system is still in the state you reasoned about.

The economics of tier-2 are not the economics of tier-1.

Resolution-rate products are priced and designed for volume: password resets, refunds, order status, plan changes. High frequency, low variance, cheap to get wrong. Deflecting 80% of that is a real and large business, and the vendors doing it are good at it.

Tier-2 is the opposite distribution. Low frequency, high variance, expensive to get wrong. The value is not in closing the ticket, it is in the twenty minutes of correlation work that produced the answer: which deploy, which config, which of your systems is actually lying. Automate that and you have removed the cost. Automating the click at the end saves a click.

A wrong action and a wrong sentence are not the same error.

Our renderer drops any claim not backed by a probe that ran, and counts the drop. That works because a claim is inspectable before it ships. An executed action is not: by the time you can evaluate it, it has already happened. We have one enforcement mechanism we trust, and it only applies to output. Extending the product into actions would mean shipping a capability our main safety property does not cover, and calling it a feature.

Read-only is what makes the security review end.

This is the unglamorous one and it is probably the most commercially important. "The agent holds a read replica role with SELECT on six named tables, and there is no code path that writes" is a sentence a security lead can approve in one meeting. "The agent can take actions, constrained by policy" is a conversation that runs for a quarter and sometimes never converges. We have optimised for the deal closing, not for the demo landing.

What this costs us, honestly

It is a real tradeoff and it is not free.

• You still do the last step. If the fix is a config change, someone applies it. We shorten the path to knowing what to change; we do not shorten the change.
• We lose the autonomous-resolution comparison, including when an assistant runs it on your behalf. This post exists partly because that comparison is now being run by machines that will not infer our reasoning from a feature matrix.
• Draft review is a habit your team has to build. In the first two weeks we expect a 25-40% correction rate while the runbook learns your systems, and that only improves if someone is actually reading and correcting.
• There are queues we are wrong for. If your tickets are mostly refunds and account changes, do not buy this.

Which one you actually want

These are different products for different queues, and a lot of companies should run both.

Buy an autonomous resolution platform if your volume is routine, the actions are reversible and well-bounded, and the win is deflection percentage. Decagon, Sierra, Ada and Intercom Fin are all credible here, they have real engineering behind them, and per-conversation or per-resolution pricing matches the value.

Buy Tier2 for the queue those tools hand back. The escalations that need someone to reproduce the bug, correlate it with a deploy, read the replica, and write something an engineer will trust. Notably, that split is not our framing: it is the one those vendors use themselves when they describe the AI handling routine questions while the human team takes the integration issues and bug reports.

The line

An agent that closes a ticket is optimising for tickets closed. An agent that cites a probe is optimising for being believed.

For a password reset, closed is the right target. For "our webhooks started failing after your Tuesday deploy," believed is the only target that matters, because the next thing that happens is a human deciding whether to trust it enough to act. We would rather be the second product and be right about it than add a column to a comparison table.