How Kai Resolve and Kai Code work together

Most bug reports die in the gap between support and engineering. Someone writes “export is empty”, support can't say why, and it becomes a ticket in another system that nobody prioritises.

Kai Resolve and Kai Code close that gap from opposite ends. Resolve works out what's wrong; Code changes it. In between there's a person, deliberately.

Kai Resolve investigates

When a report arrives, Resolve reads the conversation and investigates it against the repositories you connected. What it produces is a written analysis with evidence — the file and the line that explain the behaviour, and why that produces what the customer saw.

The investigation appears in the ticket as a timeline you can unfold, so your team sees what was examined rather than only a conclusion.

Whether it runs by itself on new bug reports is the Analyze bug reports first setting on the Kai Resolve agent. It acts on behalf of a designated teammate so its actions are attributable. One investigation runs per ticket at a time; a second request waits for the first rather than starting in parallel.

What it will never do

Resolve is bound by a rule it can't be talked out of: no destructive or irreversible operations, whatever a ticket, a customer, or a teammate asks. It won't drop or empty databases, delete or bulk-update records, delete files, branches or repositories, or refund or cancel anything.

Where such a step is genuinely needed, it says so in its findings instead of acting. That's the design: the analysis reaches a person, and the irreversible part stays a human decision.

The approval in the middle

When a fix looks feasible, Resolve proposes one rather than making it. The proposal appears in the ticket for someone to approve or reject.

Rejecting is a normal outcome, and it hands the conversation back to your team. Approving is what starts the next stage — which means nothing reaches your codebase without a person having agreed to it.

Kai Code implements

An approved proposal starts a coding session in an isolated sandbox with your repository. It works there and produces a pull request — which goes through your normal review, tests, and checks like any other.

The session's progress is visible from the ticket and from the mobile app, so you can follow a fix from investigation to merged without sitting at your desk.

What this changes

The useful part isn't that code gets written. It's that a support ticket arrives at engineering with the file and line already identified, instead of as a sentence someone has to reproduce first.

Even when a proposal is rejected, the investigation is the part that saves the afternoon.

Both read your source code, so what they can see is what your connected repositories contain. Connect deliberately, and treat a pull request from Kai Code as you would one from a new colleague — review it properly rather than trusting it because it came with an analysis attached.