How AI Superchargers Support Troubleshooting

No customer has ever submitted this ticket: "The profile read path checks Redis before PostgreSQL, and the cache key isn't invalidated on write, so member lists serve stale display names for up to 24 hours."

Seriously, no one gives that much detail when submitting a ticket to support, ever. What they type is:

"I fixed my name on Monday and my study group still sees the old one. Why is is not saving??"

Tickets speak symptom. Tech stacks speak cause. And between those two languages sits the entire job of troubleshooting — a job that, for most of software history, support people couldn't do completely by themselves. The old loop had three laps: reproduce the issue by hand (if you could) in your demo account, poke around the outside of the system guessing at causes or try to replicate it in the customer's account, maybe check some logs (if they exists for this particular issue) and then ask a developer for a deeper look — and wait. Sometimes support wouldn't hear back for a day, multiple days, or weeks. The developer wasn't being difficult; they were busy working off a priority list of tasks set by their manager, team, and the company's overall needs. Deep looks are what they do all day. So the customer waited, the support person waited, and the truth about which layer was the guilty cause of the issue arrived whenever it arrived. While agentic AI has shortened this process a lot, it's still a process and when both sides (development and support) use an agent, then process gets even shorter. This means that time to from issue reported to resolution gets shorter.

Specifically this process gets shorter when the support person uses an agent like Claude — the same way I've been writing about since "The Co-Worker Who Always Has Time": the support person tells their agent what the basic tech stack is for the software (what the UI, the service layer, and database layers are), the agent tests, the agent inspects the code in the UI, checks the network traffic, the agent gives a best guess at where the cause of the issue is in the tech stack, and the support person stays in the conversation the whole time without having to read any code themselves.

Below are three examples, each a different kind of customer report, each landing in a different layer of the stack, and each showing how an agent can assist customer support with identifying the issue:

1. Reproduce the click path — a popup bug in the React layer.
2. Follow the evidence through the layers — a "didn't save" report that turned out to be a stale cache in Redis.
3. Measure instead of guessing — a "it's slow" report that turned out to be an unpaginated query in the API layer.

These examples are based on DuckBuddy's programming architecture, my personal project that I built for learning purposes, because its architecture is the same shape as a real SaaS company's.

DuckBuddy Architecture Explained

If you've read "It's Never Just a Button" or some other articles of mine, you've met DuckBuddy — the social platform I use to learn how real ones work. Here's the whole stack in one minute, because each example will land in a different spot:

• React (frontend) — everything the customer sees and clicks, rendered in the browser.
• FastAPI (Python backend) — the API layer. It receives requests from React, decides what to do, and talks to the databases.
• PostgreSQL — the main relational store. Profiles, settings, group memberships.
• Neo4j — the graph database. Connections between people, and the mutual-contact math built on top of them.
• Redis — the cache. It holds ready-made answers so hot reads don't have to rebuild them every time.
• MongoDB — chat and message content. (An innocent bystander in all three stories.)
• Cassandra — high-volume activity logs. (Also a bystander. It's never the logs. Okay — once it's the logs, but not today.)

And here's the insight that makes all three examples make sense: when something breaks, the cause almost always lives in one specific layer. The hard part of troubleshooting is not always the fixing, the dev team fixes things all day. The hard part is naming the layer. That's what starts the fixing process and that's what the agent is for.

Example 1: The Popup That Never Appears

The ticket:

"When I click Schedule a Meeting on someone's profile and pick a time, the form where I type the meeting details is way up at the top of the window. I have to scroll back up to find it before I can save anything. Really annoying!!"

The prompt (example):

Here's a customer report on DuckBuddy, our social platform (React frontend, FastAPI backend). Reproduce what they're describing: from a contacts list, click a profile icon, choose Schedule a Meeting, scroll down in the scheduler to pick a time and day, and select it. Watch what happens to the second popup — the meeting details form. Tell me if the second popup window with the form is appearing, where the forms appearing, and based on what you see and what you know about the software tech stack, give a short guess as what is causing the issue.

What the agent did: It walked the exact click path — contacts list, profile icon, Schedule a Meeting, scrolled down through the scheduler, selected a time - all while using Devtools and looking at the Network tab and HTML. Because it was also using Devtools and looking at the requests and responses from the UI in the browser, when it stumbled into the same issue: it noticed where the details form rendered relative to the scrolling. The form appeared at the top of the scrollable window — at pixel zero. But the customer (and the agent) had just scrolled 3,000 pixels down the scheduler to find next Thursday at 2:00 PM. And browsers have a rule nobody writes down: scroll position is sticky, and no browser, framework, or layer ever moves the viewport for you. React did its job perfectly — it rendered the form right where it was told to (programmed by development). The "bug" was that none of the tech stack layers were told to included "take the customer to the new form", after they select a date.

Where the issue lived: the React layer, in one component's opening moment. The dev team fixed it with four lines — when the details popup opens, tell the window to come meet it:

useEffect(() => {
  formRef.current?.scrollIntoView({ behavior: "smooth", block: "start" });
}, []);

What the agent handed back: a write-up of the repro steps, the finding (the form renders at the top of the scrolled window; nothing scrolls to it), and the suspected fix for the dev team — filed like a ticket with evidence attached — plus a draft reply to the customer in plain English: "We found it — the meeting details form was opening at the top of the window, and the window wasn't following you back up to it. We've released a fix; the window now comes to you."

The old loop: reproduce by hand, notice something's off with scrolling, write down all the specific steps taken to reproduce the issue, submit a ticket to development and ask a developer to look at the component, then wait.

The new loop: one conversation with agent, agent tests and records all the steps, uses Devtools to look beyond the UI and give a specific update, and the report arrived at the dev team with a detailed and accurate diagnose.

Example 2: The Profile Name That Wouldn't Update

The ticket:

"I changed my display name Monday and my study group still sees the old one this morning. Did it not save? I hit Save and it said Saved and it looks fine to me."

The prompt:

A customer says their display name change isn't showing for other members, but their own settings show the new name. On DuckBuddy: React frontend, FastAPI backend, Postgres for profile data, Redis as a cache in front of reads. Reproduce what the customer described, then use the network traffic as evidence to best guess what the issue is.

What the agent did: Again the agent can go beyond the UI and readily keep up with all the calls on the Network tab of Devtools, better than a human can. And in this case, that is super helpful. First it reproduced the save — then it saw the request go out to the server (my software company's server), FastAPI answered 200 OK, the settings page showed the new name in the UI. The save worked. Then my agent called the member-list endpoint the way any signed-in member's browser would — the request a study group member's page makes to load its contact list — and read the response body. The old name was in the response still. That single observation cleared half the tech stack in one step:

• React is innocent in this case. It displayed exactly what the API sent it.
• The save is innocent. The write went through.

So the staleness is upstream of React, in the read path. The agent traced FastAPI's read path: for member lists, FastAPI checks Redis first, and only asks PostgreSQL on a cache miss. And there it was — Redis still holding Tuesday's answer under the profile's cache key, because the cache had a 24-hour lifetime, and the code that saves a profile never told the cache the answer changed. PostgreSQL had the new name the whole time. Every layer did its individual job correctly. The bug was the missing handshake between two layers: a write that doesn't tell the cache.

Where it lived: the caching layer. The dev team's fix was essentially one line — when a profile is written, clear that profile's cache key — and the name now updates everywhere the moment it's saved.

What the agent handed back: the evidence chain written for the dev team (the endpoint, the stale response body, the read path, the un-cleared cache key, the suspected one-line fix), plus the customer reply: "Your change saved correctly on the first try — the delay was on our side. A cached copy of the old name was still being shown to other members. We've fixed that; updates now appear immediately."

The lesson for support people: when a customer says "it didn't save," the network tab tells you who's lying. Sometimes nothing is lying — the save reached the database and a middleman is repeating yesterday's answer. That's not a guess you want to make by hand. It's exactly what an agent checks in seconds.

Example 3: The List That Took Four Seconds

The ticket:

"My contacts page is so slow it's basically unusable. It just spins and spins. My friends say theirs is fine??"

The prompt:

A customer reports DuckBuddy's contacts page is extremely slow for them, but our test accounts feel fast. Reproduce the page load and measure it — don't guess. Compare what happens on a normal-sized account versus what would happen on an account with a very large number of connections. Tell me which request is slow, how slow, how big, and what in the backend makes it that way.

The agent's superpower in this one: it measured. "Slow" is a feeling; "slow" is not a bug report a developer can act on. The agent opened the contacts page and recorded what every request actually did. On the customer's account — a community organizer with 1,140 connections — one request to the connections endpoint took 4.3 seconds and came back 2.6 MB. On a support test account with 38 contacts, the same request took 90 milliseconds and came back 44 KB.

And there's the whole bug in two numbers. The page wasn't broken — it was size-dependent. The endpoint was built to return a member's entire connection list in one response, straight out of Neo4j, with the mutual-connections count computed for every single row. For 38 contacts that's nothing. For 1,140 contacts it's 2.6 MB of JSON the browser has to download, parse, and render — every single visit. Works on my machine, indeed: it works beautifully on every account the internal team tests with, because internal accounts are small. The customer's account was the test case we never had.

Where it lived: the API layer — an endpoint with no pagination. The dev team added it (the request now returns the first page of 50 contacts in about 60 milliseconds, and the list loads more as you scroll), and suddenly the "slow" page was one of the fastest screens in the product.

What the agent handed back: the dev ticket with the numbers attached — which endpoint, 4.3 seconds, 2.6 MB, at what connection count it turns painful — plus the customer reply: "We found it. Your network is much larger than most (impressive, honestly), and the contacts page was trying to load all of it at once. It now loads in pages — you should feel the difference immediately."

The lesson: performance reports are the vaguest tickets in the queue, and they hide the most fixable bugs. The agent turned a feeling into a number, a number into an endpoint, and an endpoint into a one-line diagnosis: it only breaks for customers unlike us. Guessing can't find that. Measuring does.

What the Three Stories Have in Common

Strip the details and it's the same pattern every time:

1. The ticket spoke about the symptoms. A stranded popup, a name that wouldn't change, a page that spun.
2. The agent reproduced it. Every report got treated like what it secretly is: a test case. (The QA tester in me loves this — every ticket is a bug report, and every bug report is a test script waiting to be run.)
3. The agent gathered evidence instead of guessing. Where the form rendered versus where the customer was looking. What the API response actually contained. How many milliseconds and megabytes, for which account.
4. The agent used context and named the layer. React. Redis. FastAPI. One layer guilty per bug — and, just as important, the innocent layers named too, so the dev team starts at the scene instead of re-interviewing the whole neighborhood.
5. The agent drafted both hand-offs. Evidence write-up for the developers, plain-English reply for the customer.

Notice what the support person's job became in every story: not a relay station, and not a coder — a first responder. You take the report, you hand it to your agent, you watch the investigation happen, you ask the questions only a human can ask ("does this match what other customers described last month?"), and you close the loop with the customer the same day. The support person stays in the conversation the whole time. The agent does the part that used to require borrowing a developer's afternoon.

And notice the translation direction reversed. Traditionally, someone had to translate the customer's words up to the developers — usually badly, through a game of telephone. The agent translates both ways: ticket → repro steps and evidence going up, root cause → plain English coming back down. The gap between "something's wrong" and "here's exactly why" — the gap I wrote about when an agent debugged a calendar embed that needed a library from 2006 — closes in one conversation instead of three loops.

The Bottom Line

Customer support has always been the department that hears the most about the product and can see the least visibility into how it all built or is supposed to work. This is the industry norm and yet support is in charge of identifying what is a true "bug" versus user error versus poor design etc. The workforce has always had symptoms at the front desk, causes in the back room, and to try to bridge these two, a queue of deep-look requests in between.

Agents have ended that order. Not because support people suddenly need to become engineers — they don't, and in these three stories the support person never read a line of code. But the co-worker who always has time can read it for them. It can reproduce the click path (again and again if needed), read the network traffic between the UI and the server, measure the slow thing, identify the break point, and quickly build a detailed report that a developer can use to prompt their agent to find the cause in the codebase and fix it. All the details about what the customer experiences, what testing was done, and what the result were versus the expected results are clearly laid out. This results in faster troubleshooting across the company and a faster time to resolution for the customer.

The ticket always report the symptoms. Somewhere in the tech stack lies the issue and it's up to support to try to accurately help a developer identify it. Agents can help customer support find and report issues so they can be resolved sooner. Gone are the days of manual testing. With AI, almost nothing is manual anymore, or at least it doesn't have to be. It's just up to everyone to use the newest tool on the job site.

For other support people out there, text time a vague ticket lands in your queue — "it doesn't save," "it's slow," "it doesn't show" — paste it to your agent with your stack's one-minute map and ask it to reproduce the report, gather the evidence, and tell you which layer is guilty. Then watch what used to be your hardest afternoon turn into your most interesting conversation.