AI Agents Answer the Easy Tickets. Who Handles the Ones That Need an Engineer?

Signup Write New Story AI Agents Answer the Easy Tickets. Who Handles the Ones That Need an Engineer? by Lukas Böhler by Lukas Böhler | @ lukas-bohler CEO and co-founder of Gleap

At Gleap, three out of four support requests are now handled by an AI agent. That’s not the interesting part. The interesting part is which ones: not password resets, but tickets that used to land on one of our five developers.

Every software company has the same leak in its feedback loop. A customer reports that something is broken. Support can't reproduce it. Engineering is busy. The ticket sits. Weeks later, someone fixes the bug as part of an unrelated change, and nobody tells the customer.

AI support agents have gotten very good at the start of that loop. Ask "how do I reset my password?" or "which URLs do I need to whitelist?" and an agent trained on your docs will answer in seconds, at any hour. That part is close to solved.

But the tickets that actually hurt aren't the ones your docs can answer. They're the ones where the honest reply is "let me check with engineering." Those tickets aren't a knowledge problem. They're a debugging problem. And most AI support tools stop exactly there.

This post is about what happens after the first-level agent gives up: how we built Kai Resolve, an AI agent that investigates hard tickets like a second-level support engineer, and how it hands confirmed bugs to Kai Code, which writes the fix.

Here's a typical one, taken from our product walkthrough:

"The CSV export stops at 1,000 rows. Our segment has 4,200 contacts, so the file is incomplete."

No help article answers that. To reply honestly, someone has to look at the export logs, check the customer's account, and read the code that paginates the export. That's three different systems and, in most companies, at least two different people.

What usually happens next is a relay race: support asks for screenshots, engineering asks for steps to reproduce, and every hop adds a day. The customer just sees silence.

When we looked at that chain, the expensive part wasn't writing the fix. It was the digging: collecting evidence, reproducing the issue, and finding the line of code responsible. So that's what we built an agent to do.

A first-level support agent is built for conversation: understand the question, find the answer, reply. A second-level agent needs a different shape. It has to gather evidence, form a hypothesis, check it against the code, and come back with either an answer or a diagnosis that someone can act on.

Kai Resolve runs every ticket that needs an engineer through the same four steps.

The biggest reason second-level support is slow is missing context. So the investigation starts from evidence captured at the moment of the report, not from a follow-up email.

With in-app bug reporting, that evidence is collected automatically:

On top of that, teams can give the agent access to their repositories and, via MCP, to data sources such as a Postgres database. Both are opt-in, and both are read-only.

This is where Kai Resolve differs from a support chatbot. Repositories are cloned into a sandbox, and the agent traces the report through the actual source. It doesn't commit and it doesn't push. Database access through MCP is read-only too, and destructive database operations and billing operations are blocked.

We made this a hard boundary on purpose. An investigation should never be able to turn into an incident. The agent that diagnoses a problem shouldn't also be able to change production. If you've ever given a script more permissions than it needed "just for now", you know why.

Setup means installing the Gleap SDK, which captures the logs, replays and click trails, and connecting your repositories from GitHub, GitLab, Bitbucket or Azure DevOps. It takes about ten minutes. The agent reads the source directly, so it works regardless of language, and in large monorepos you can limit it to the folders that matter, so only those files are downloaded.

A diagnosis is only useful if an engineer can check it quickly. So findings cite the files and lines the agent actually read. Here's what that looks like on a sample bug from our product walkthrough, where survey notifications never reach signed-out visitors but chat notifications do:

Found a likely bug in pushGate.ts:142: survey pushes return early when the contact has no email.

Chat pushes skip that check at pushGate.ts:128, which is why they arrive.

That's the difference between "there might be a problem with notifications" and something an engineer can confirm by opening one file. It also explains why the bug happens: the agent compared the path that works with the path that doesn't.

The most dangerous failure mode for an AI agent in support isn't a wrong answer. It's a confident one. An agent that can't find a bug and reports "no issue found" quietly closes a ticket that's still broken for the customer.

So Kai Resolve follows a strict rule: an inconclusive investigation is never turned into "no issue". It gets one re-investigation. If it's still inconclusive, the agent asks the team.

Those questions arrive as a decision card with concrete options, not as an open-ended chat. For example, "Which push provider does this account use? OneSignal or Firebase?" or "Should teammates be able to open Reports? Yes, it's a bug / No, admins only." A teammate clicks an answer, and the investigation resumes with that context. A human spends a few seconds on a decision instead of an hour on reproduction.

Not every ticket that needs an engineer turns out to be a bug. An investigation ends in one of three places:

Investigations start automatically when a new bug report comes in, as an escalation when the first-level agent can't answer, or manually from any ticket.

On cost: an investigation averages about $0.49, billed for the work the agent actually does.

A diagnosis on its own still leaves the loop open. Someone has to write the fix, ship it, and tell the customer. That's the part most teams lose track of.

When Kai Resolve confirms a bug, the coding task lands in the ticket with the evidence attached. From there, the team decides:

Kai Code doesn't merge or deploy. Your engineers review and merge the pull request, the same way they would review a colleague's.

Then comes the step that's easy to forget: a merge isn't a release. With the default follow-up setting, a teammate confirms the fix is actually live. Only then does the customer get a reply, in the original ticket, saying their issue is fixed.

Customer report → Kai Support answers or routes → Kai Resolve investigates → Kai Code opens the PR → your team reviews and ships → the customer hears back.

Plenty of tickets that need an engineer aren't bugs at all. The customer wants something the product doesn't do yet. Kai Resolve matches the ticket to an existing feature request and subscribes the customer to updates, so the request doesn't disappear with the closed ticket. Kai PM picks it up from there. It compares requests against customer demand, revenue and your goals, and recommends what to build next. Your team makes the call, and an approved request goes to Kai Code just like a bug fix. Here's the loop for a feature:

Customer report → Kai Resolve links the feature request → Kai PM recommends priorities → your team approves → Kai Code opens the PR → your team reviews and ships.

We run Gleap's own support on Gleap. Today, Kai Resolve handles 75% of our support requests. The remaining 25% are either handed over to Kai Code as a coding task or handled by someone on our team.

For a small team, that changes what engineering time is spent on. Instead of reproducing bugs from half-complete reports, we review diagnoses and pull requests.

Across our EU customers, Kai Resolve ran 1,368 investigations in the last 30 days. In a sample we graded by hand, 70% ended in a correct result, 28% were partly right and 2% were wrong, and 80% were finished without a human having to step in. Between 2% and 13% of investigations end as inconclusive, depending mostly on whether the team has connected the data the agent needs to check.

Customers see it too. After moving from email support to Gleap, Gather's team passes technical issues to engineering with the context needed to investigate, and response times dropped from around 30 minutes to about five.

"Gleap saves us a lot of time and our users find it incredibly useful." Sasha King, Product Specialist, Gather

Our worst week came from a dependency update, not a bad prompt. An update to the coding-agent adapter made its read-only mode truly read-only, so the agent could no longer write its own report. For two days, every investigation came back empty. The inconclusive rule did its job: instead of saying "no issue", Kai asked the team, and those questions jumped from 18% to 53% of tickets. That's how we noticed. Now an empty report counts as a failed run and triggers an alert, and every adapter update gets a live test first. Where it still struggles is missing data: if a team hasn't connected its database, the agent can't check the customer's records, and infrastructure problems that never show up in logs stay hard to diagnose.

Kai Resolve is part of Gleap, the AI-native help desk for software teams, used by more than 4,500 teams. It's included from the Team plan, and you can run your first investigation on a ticket from your own queue with a 7-day free trial, no credit card required.

AI agents already answer the easy tickets. The interesting work now is closing the loop on the ones that need an engineer.

This article was published under HackerNoon's Business Blogging program.