Can AI debug a customer's technical problem?

Almost all support AI is retrieval over documentation. It searches what you have written and rephrases the best match. That is a good description of answering a question and a poor description of diagnosis.

Why this one is different

A billing question has an answer that already exists somewhere. A technical fault does not — nobody wrote the article, because nobody knew this would break. The work is not retrieval, it is forming a hypothesis, testing it against evidence, and discarding it.

The specific failure mode

Not silence — confidence. A retrieval agent asked why an API returns 500 will find the nearest article about error codes and produce a fluent, plausible, wrong cause. The customer follows it, wastes an hour, and arrives at support angrier and further from a fix.

That is worse than no answer, and it is the outcome deflection metrics record as a success.

What is actually changing

The gap is closing from one direction only: access. Tools that read your observability stack rather than your help centre are a genuinely different proposition, because they can look at the failing request instead of searching for an article about failing requests.

Duckie connects to Datadog, Sentry and GitHub for exactly this reason. DevRev links a ticket to the engineering work item so customer impact is visible during triage. Both are young, neither has much independent evidence, and both depend entirely on your instrumentation being good — an agent reasoning over thin logs is back to guessing.

What has not changed is the hard part. Reading a trace is not the same as knowing which of three plausible causes is the real one, and the industry has no answer to that yet beyond a human who knows the system.

What to do in the meantime

• Automate the triage, not the diagnosis. Classification and routing are reliable and remove most of the delay.
• Use AI behind the engineer. Summarising a 40-message thread before a human reads it is real time saved with no risk.
• Correlate incidents. Recognising that thirty tickets describe one outage is high value and low risk.
• Set the confidence threshold high and make escalation fast. On this queue, admitting ignorance beats a fluent guess.
• Keep technical tickets out of your deflection target, so nobody is rewarded for automating them.

If a vendor demos technical troubleshooting, ask it about a fault specific to your product that is not in your documentation. That single question separates diagnosis from retrieval, and most demos are retrieval.