Kai Resolve by Gleap - Support that does the digging for you.
byβ’
Kai Resolve is the AI agent for support tickets your docs can't answer. It reads the screen recording, logs, account data and your code, read-only, then answers the customer or escalates with a diagnosis. Confirmed bugs become coding tasks your team reviews.


Replies
Hey Product Hunt π
I'm Isabella, co-founder of Gleap. Our team builds AI-native customer support for fellow software teams, and today we're launching the newest member of our AI team: Kai Resolve.
Why we built it
Kai Support already takes care of the easy cases, quickly and with a low token cost. But some tickets need more than a good answer: someone has to dig into the data to really help the customer. That's where Kai Resolve comes in. It looks into the ticket, finds bugs and hands them to your team with a much better handover. It also picks up the context of the conversation, and through MCP it can add feature requests that come up in a chat straight to your roadmap. So one agent sorts it all out: inquiries, feature requests and bugs.
What Kai Resolve does
π looks at the screen recording, console and network logs and the click trail that came with the report
π§βπ» checks account data and your code, read-only, in a sandbox, and points to the exact file and line
β answers the customer, flags a likely bug for your team with the cause and the evidence, or adds the feature request to your roadmap
Based on our Gleap data, Kai Resolve resolves 75% of all tickets automatically. And when it isn't sure, it says so and asks your team instead of guessing.
Who it's for
Software teams whose tricky tickets wait for a developer: support leads, developers on support duty, product managers and founders.
Pricing
About $0.49 per investigation on average, billed for the work it does. Included from the Team plan, with a 7-day free trial and no credit card.
π Launch-day deal for the Product Hunt community: sign up today and get 50% off for one year with the code KaiResolve26.
What we'd love from you
Try it on a real ticket from your own queue and tell us where it got it right and where it didn't. Tough tasks are very welcome. Lukas will share more about the technical side right below, and the whole team is here all day to chat.
A big thank you to Thomas Schranz for hunting us, and to all of you for stopping by π
See you in the comments below π
@isabella_salzmannΒ the idea of tracing bugs back to the exact file and line is really useful for suport teams how well does it work with complex bugs that need multiple steps to reproduce?
Hey @shivam_kushwaha16,
Florian here, CTO at Gleap. I'm jumping in since this one is technical π
For multi-step bugs, Kai Resolve doesn't have to guess the steps. It reads what came with the report: the screen recording, the click trail, and the console and network logs. That lets it follow what the user actually did, step by step. It then compares that with the account data and reads your code, read-only, to find where things go wrong. Bugs like "change setting A, open page B, save C, and it breaks" usually work well, because the evidence shows the whole path.
How deep it can go mostly depends on what it can see. If you connect more sources through MCP, like your monitoring, it can also trace issues that never show up on the user's screen, like an error spike or a slow backend call. And when something is still unclear, it doesn't guess. It hands the ticket to your team with what it checked, what it found, and what's still open, so the developer doesn't start from zero.
If you have a nasty multi-step bug in your queue, give it a try and let me know how it did. I'm happy to look at the result with you π
@isabella_salzmannΒ kudos @ shipping & launching β΄οΈ
@__toshΒ Thanks π
Hey Product Hunt π
Lukas here, co-founder of Gleap.
Iβve been building software for most of my life, and the part I always hated was the gap. A customer reports a bug, it becomes a ticket, the ticket becomes a Jira issue, and weeks later someone ships a fix. The customer who reported it never finds out. The feedback loop justβ¦ never closes.
Thatβs why Iβm so excited about Kai Resolve. Itβs the first time support and engineering feel like one team.
Hereβs what happens when a hard ticket comes in:
π Kai Resolve investigates it like a developer would: logs, click trail, session replay, and the actual code in your GitHub repos
β It tells your team whatβs going on (bug, feature request or setup issue) and lists the files it read, so you can check its work
π οΈ For a real bug, it prepares a coding task. One click hands it to Kai Code, Claude Code, Codex or Cursor, and you get a pull request to review
π¬ Once the fix is live, the customer hears back on the same ticket they opened - automatically.
What I love most is that last step. The person who took the time to report the problem actually hears βwe fixed it, thank you.β I think thatβs what turns users into fans.
Your engineers stay in control the whole way: they review every PR and decide what ships. Kai Resolve just takes on the digging and the back-and-forth that used to eat our week. We run our own support on it every day, and itβs honestly changed how we build Gleap.
Iβd love your feedback, especially from devs and founders: how does the loop from customer report to shipped fix work on your team today?
Iβll be here all day π
@lukas_bohlerΒ kudos @ shipping & launching β΄οΈ
Telling the customer once their fix is live is the bit I like here. Easy for that last message to get lost after the engineering work is done.
@oleksii_sekundantΒ Thanks for sharing π From a product perspective I agree 100%. I would maybe add the fact that dev teams have more time focusing on building rather than support with Kai Resolve.
Hey, Luca here, software engineer at Gleap π
I built the setup and settings for Kai Resolve and worked a lot on answer quality. What surprised me was how often fixing one case would quietly break another. Testing every change against all our scenarios slowed us down, but itβs why I trust the answers now.
If you try it and something feels off, please tell me here. Iβd much rather hear it today than read it in a ticket next week π
Hey Product Hunt π Tobi here, co-founder of Gleap.
Weβve been building support tools for years, and one thing kept bugging me: the hardest part of support was never writing the reply. It was figuring out what actually went wrong. Teams spend hours jumping between logs, recordings and code just to understand one ticket, and the customer is left waiting the whole time.
AI got really good at answering questions, but most βAI supportβ stops right there. We wanted something that does the part that actually hurts: the investigation.
Thatβs Kai Resolve. It looks into every ticket like an experienced teammate would, answers what it can, and hands the rest to your team with the cause and the evidence ready. And the more context you give it (your docs, your code, your past tickets), the more it solves on its own.
For me, this is the support tool I always wished we had.
Iβd love to hear from everyone running support: whatβs the part of the digging that takes your team the longest? π
Hey Product Hunt π Florian here, CTO at @Gleap .
@isabella_salzmann covered the why, so here's the part I'm most excited about as an engineer: how Kai Resolve investigates.
When a tricky ticket comes in, it works like a good developer would: β follows the click trail and watches the session replay β reads the console and network logs to see what actually failed β checks the account data for anything unusual β reads your code and points to the exact file and line
The more it can see, the deeper it goes. Connect your monitoring or internal tools via MCP, and it can trace issues that never show up on the user's screen.
Send it the bug your team has been avoiding for weeks, and tell me how it did. I'm here all day for any questions about how it works under the hood π
Curious if multiple customers report the same bug in different ways, can Kai correlate those tickets to one investigation?
Hey @michelle_bankasΒ ,
Great question! Partly, today.
Kai Resolve searches past tickets by meaning, not keywords, so "export is broken" and "CSV download does nothing" still find each other. It uses how those similar tickets were solved as input for the new investigation. For feature requests it goes all the way: same need, one roadmap entry, and the customer gets subscribed instead of creating a duplicate.
For bugs, each ticket still gets its own investigation right now. Grouping all reports of one bug into a single investigation, with one root cause and one update for everyone affected, is the next logical step and something we're looking at.
Hi all, Hussein here, I lead Customer Success at Gleap π
What I keep hearing from second-level support teams: most of their day goes into tickets that just need digging. Checking logs, rewatching recordings, asking the customer for one more detail. The tricky, important cases end up waiting behind all of that.
Kai Resolve turns that around. It does the digging and handles the routine investigations, so your second-level team can finally focus on the tickets that really need them: the complex bugs, the key accounts, the decisions only a person should make.
Based on our Gleap data, Kai Resolve resolves 75% of all tickets automatically.
If you'd like to see it on one of your own tickets, I'd be happy to set it up with you: https://cal.gleap.ai/hussein
Congrats on the launch, Gleap team! At MailerCloud (mailercloud.com) we deliver 6 Billion+ emails every month, and our support team runs on Gleap. The slow part of every ticket is the digging: logs, account history, figuring out whether itβs a bug or a setup issue. Having Kai do that before a human picks it up is exactly what we need. Excited to roll it out!
@amar_cpΒ Excited to see what Kai Resolve can do for you and the team π»
Reading the screen recording and the logs before answering is what makes this interesting, since most support tools just paraphrase the help center and call it AI.
Thanks @karimbenkeroumΒ , that's exactly the gap we wanted to close π
Help-center answers are great for "how do Iβ¦" questions, and Kai Support already handles those. But when something is actually broken, the answer is rarely in the docs. It's in what the user did and what failed along the way. So Kai Resolve starts with the evidence (the replay, the logs, the account data, the code) instead of the knowledge base.
That also changes what your team gets when it can't solve a ticket itself: not "customer says it's broken", but what happened, where it failed, and the likely cause.