Support on Steroids: How We Use AI to Investigate, Fix, and Answer Customer Bugs

A customer emails: something’s broken. By the time anyone on your team can confirm whether it’s a real bug or their own mistake, you’ve burned a week.

Here’s the path that email takes. Support reads it and opens a ticket. They poke at the account, find nothing obvious, and rope in an engineer. The engineer checks the logs, queries the database, reads the code, and figures out whether the customer hit a real bug or just clicked the wrong thing. If it’s a bug, it lands in the backlog for next sprint. Then it waits for a deploy. Then someone confirms the fix took in production. Then, finally, support circles back to the customer. Meanwhile you’ve told them it’s “being looked into.” Both of you know what that means: nothing, for now. Every day the bug sits there, they trust you a little less.

Two weeks later you have a fix and a customer who spent two weeks watching it stay broken.

We collapsed that whole path into a background task. Here is what we built, and why it matters for any business that runs support.

What the agent actually does

We gave Claude the same access a senior engineer gets on their first day:

• It reads our support inbox in Gmail, so it sees the complaint the moment it lands.
• It reads Sentry, our error logging, so it can check whether the customer’s problem threw an error.
• It reads real customer data through the same access-controlled internal tools our engineers use, so it can see exactly what the customer sees. Its access is scoped and audited like a person’s, and every lookup is read-only.
• It reads our codebase, so it can trace a bug back to the line that caused it.

When a complaint comes in, the agent goes to work on its own. It reads what the customer said. It pulls up their account. It checks whether anything errored. It compares what the data should look like against what it actually looks like. Then it reads the code to find the bug.

What lands in front of a human is a full report: here’s what the customer reported, here’s what we found, here’s whether it’s a real bug or a misunderstanding, and here’s the proof.

It doesn’t stop at diagnosis

Diagnosis is just the part everyone pictures. The slow, expensive stretch is everything around it: confirming the bug is real, writing the fix, shipping it, cleaning up the mess it left, and answering the customer. The agent doesn’t hand you a diagnosis and stop. It does all of it.

If it’s a real bug, the agent writes the code change, makes it, and gets the fix deployed. If the bug left bad data behind, it lays out the exact steps to correct that data. When the investigation is done, it drafts the reply to the customer: what we found, what we fixed, and what happens next.

A person reviews every draft before it goes out. The agent does not send email on its own, and it can’t change a customer’s data: its access is read-only, scoped and logged exactly like an engineer’s. It investigates, it proposes, it prepares. A human approves.

A real one, from last week

A customer ran their first event with us, then came to us with a bunch of questions about what they were seeing in their CRM. Some scanned contacts were missing the tag that groups them by event. A custom “event scanned” field sat blank on every record. A few leads showed the wrong owner and a date that didn’t match the day they were scanned. Looking at the CRM cold, it read like the integration was broken. It was their first event with us, and the person asking hadn’t been at the booth, so it was anyone’s guess whether they’d hit real bugs or were just seeing the product work in a way nobody had walked them through.

That’s the classic two-week ticket, and the hardest part isn’t fixing anything. It’s telling the two apart. Is this a real bug, or someone who hasn’t learned the product yet? You can’t answer that from the email. Someone has to reconcile what’s in the CRM against what we actually sent, then read the sync code, lead by lead, until each question resolves into “bug” or “works as intended.” That sorting is what eats the days.

I gave the agent one instruction: read the email, then go find out what went wrong. It went spelunking. It pulled the customer’s records, compared the CRM against our own data, and traced every discrepancy to its cause. Two were real bugs on our side. The CSV export was dropping the ID columns, so leads uploaded by hand came in untagged. Empty badge-only scans were syncing a stray note that added nothing but clutter. The rest had a duller cause: several reps had scanned leads before connecting HubSpot, so the automatic tagging never ran, and those records landed under whoever synced them later, dated the day they synced instead of the day of the scan.

Then it fixed the bugs it found. It reproduced them on a local copy, wrote tests that failed, and made the tests pass. The export now carries the IDs, empty leads no longer push a junk note, and synced notes show the real scan date and the right owner. It laid out the steps to clean up the records that had already gone over. Then it drafted the reply: here’s what was a genuine bug, here’s what came from connecting late, here’s exactly what we changed, and here’s the proof in your own data.

From the first email to a finished reply, the whole thing took under two hours: diagnosis, investigation, a local reproduction, the fix deployed, the cleanup steps, and the customer response written. Almost all of it was the agent running on its own. I checked its work at a few points, kicked off the deploy, and scheduled the reply to send first thing in the morning. And none of it lived in my head. While the agent dug through the systems, I kept shipping features, with other agents working their own jobs in the background. The bug never blocked me. Two hours, not two weeks.

The job changed from doing to checking

This is the part that’s hard to believe until you’ve watched it happen.

The human job used to be hours of grind: matching data across the inbox, the error logs, the customer records, and the code, then debugging, then writing the fix, then writing the customer back. Now the human job is a five-minute spot-check. Is the diagnosis right? Is this a customer issue or a real bug? Does the fix make sense? Does the reply read well? Approve.

We took that whole chain, not just the investigation, and turned it into something that runs while we do other things. While one agent works through a support complaint, four others are off doing unrelated work. The queue works itself down on its own and surfaces finished drafts for a signature.

How fast

For a real bug that needs a code change, a data fix, and a customer reply, the whole thing usually finishes in an hour or two. That’s wall-clock time, not hands-on time. The agent does the work in the background while everyone gets on with their day.

For the common case, a customer asking how something works or where a piece of their data lives, it’s faster. There’s nothing to fix. The agent reads the question, checks the system, and drafts an accurate answer in minutes.

Compare that to the two-week version. It’s a different category of support.

Why this matters

Slow support costs you in ways that never show up on a line item. A bug that festers for two weeks is a rep who can’t find the leads they paid to capture, and a buyer staring at a CRM full of contacts with no event attached to them. A “we’re looking into it” is a customer doing the math on whether to renew. The vendor who answers by morning, bug already fixed, is the one that keeps the contract.

None of this required a research lab. It’s Claude, a handful of connectors, and a Gmail tool. The pieces are sitting there for any business willing to wire them together. What you get back is support that moves at the speed of the question instead of the speed of your queue.

The slog of support, the spelunking through systems, the fix, the cleanup, the careful reply, is exactly the work AI is good at. We handed it that work. We kept the judgment. Our customers get answers in hours that used to take weeks.