Why we don't let AI agents auto-close tickets, even when the fix obviously worked

It is tempting to build this feature, and we get asked for it constantly: a printer comes back online, a disk fills up and the agent clears temp files, a service restarts and starts responding — so why not let the agent close the ticket itself? The fix clearly worked. A human confirming it feels like busywork layered on top of a result the system already verified.

We don't build it that way, and the reason isn't caution for its own sake. It's that "the technical symptom resolved" and "the ticket is actually done" are not the same fact, and an agent can only ever verify the first one.

What "obviously worked" leaves out

• A printer coming back online doesn't tell you whether the underlying cause — a flaky network switch, a driver that needs updating — will recur next week. Closing the ticket erases the paper trail that would have caught the pattern.
• A disk that stopped filling up after a cleanup script ran doesn't tell you why it filled up. If it was a runaway log from a misconfigured service, the symptom is gone and the cause is still live.
• A service that's "responding" again isn't the same as a client who considers the issue resolved — sometimes the client wanted an explanation, a timeline, or reassurance it won't happen again, none of which a status check can confirm.
• The ticket record itself is often the only evidence an MSP has, months later, that a recurring problem is in fact recurring. An auto-closed ticket with no human eyes on it is a weaker record than one a tech actually reviewed.

This is the same design principle behind the rest of the AI layer at Nexus, stated plainly: an agent can look at everything and draft anything, but it does not get to be the last check on its own work. For ticket resolution specifically, that means the agent can diagnose, propose a fix, even execute a low-risk remediation under a tenant's configured automation policy — but closing the ticket, the action that tells a client "we consider this done," stays a human decision.

A model can verify that a symptom went away. It cannot verify that the problem is understood, won't recur, or that the client agrees it's resolved. Those are judgment calls, and closing a ticket is a judgment call dressed up as a status update.

There's a second reason, less philosophical and more practical: SLA and CSAT data only mean something if "resolved" reflects a consistent standard. If an AI agent and a human tech apply different bars for what counts as done, your resolution-time metrics quietly stop measuring the same thing across tickets, and nobody notices until a client disputes a number in a QBR. Keeping closure a human action keeps that bar consistent, because it's the same kind of person making the call every time.

None of this is us being precious about automation generally — Advisory and Assisted policy modes exist specifically so a tenant can let routine, non-destructive classes of work move faster as they earn trust. Ticket closure isn't one of the classes that graduates out of human review, because it isn't a technical action with a technical success criterion. It's a statement to a client, and we think a person should be the one making it.