Skip to main content
Findings reviews completed WhatsApp conversations with AI, records what it sees as structured events, and groups the recurring ones into findings you can investigate.

​
How it works

  1. A managed workflow evaluates each conversation when it ends and emits project events such as conversation.user_frustrated.
  2. Kapso compares the last 7 days against the previous 28 and opens a finding when a signal rises, falls, or keeps recurring.
  3. The Kapso Agent Investigator reads the evidence behind the finding, inspects your workflows, executions, logs, and connected repositories, and reports the cause with suggested fixes.
  4. You apply a fix and mark the finding as addressed. Kapso then watches new conversations to see whether the problem comes back.

​
Turn it on

Open Findings in the sidebar and complete the setup. It creates two components in your project:
  • Default event evaluator — a workflow triggered by whatsapp.conversation.ended that reads the transcript and emits events. It never replies to the customer and takes no outbound action.
  • Kapso Agent Investigator — a Kapso Agent mode that investigates a finding when you start an investigation.
During setup you can also review up to 50 conversations from the last 7 days, so you get findings without waiting for new traffic. Both components use AI credits when they run. Findings needs project events on your plan, and only evaluates conversations on production numbers.

​
Default events

The evaluator emits these events. Each one carries a short reason property with the evidence for it. A conversation can emit zero, one, or several of them. The evaluator optimizes for precision: with ambiguous evidence it emits nothing. The evaluator treats the transcript as untrusted data and never follows instructions found inside it.

​
How findings are detected

Kapso refreshes findings once a day. It compares a current window of the last 7 days against a baseline of the 28 days before it, counting distinct conversations. A rising finding needs all of:
  • At least 30 evaluated conversations in both the current and the baseline window
  • At least 5 affected conversations
  • An affected rate of at least 10%
  • A rate at least 5 points above the baseline
  • Evidence on at least 2 different days, with something in the last 2 days
A falling finding needs a rate at least 5 points below the baseline on at least 2 days, and a shortfall of at least 5 conversations. When there isn’t enough history for a baseline, a signal seen in at least 5 conversations over the last 2 days opens a recurring finding instead. Prompt injection attempts are always tracked as recurring. Recurring findings have no baseline comparison. What matters is that the problem keeps appearing. A finding that stops qualifying goes quiet and leaves the list: after 7 days without new qualifying evidence, or 14 days once it’s under investigation or monitoring.

​
Investigate with AI

Open a finding to see the evidence behind it: the affected conversations, the events that qualified it, and the workflow they run through. Click Investigate with AI to run the Kapso Agent Investigator. It reads the finding evidence, compares affected conversations against successful ones, follows them into workflow executions and execution events, searches your logs, and inspects any repositories connected to the project. The investigation is read-only. It never messages customers, changes configuration, edits repositories, or starts workflows. When it finishes, the finding shows:
  • Summary — what is broken and why
  • Causes — each with an explanation, a confidence of low, medium, or high, and evidence references
  • Suggested fixes — at most three, each with the target, the change, and how to verify it
  • Coverage limitations — what the investigator could not verify, so you can weigh it before changing anything
Evidence references link back to the source: the conversation, the workflow, the execution, the project events, or the log entry. An investigation that fails or times out can be retried, up to 3 attempts for the same evidence. A new investigation also becomes available when new evidence arrives after the last one ran.

​
Act on a finding

Mark as addressed after you apply a fix. Kapso records the current metrics as a baseline and starts monitoring:
  • If the signal doesn’t qualify again, the finding resolves.
  • If it qualifies again, the finding is marked as not improved and comes back.
You can only mark a finding as addressed once an investigation has completed and covers the current evidence. Dismiss a finding you don’t want to see. A note is required. If monitoring later detects the problem again, the finding can reopen.

​
Custom events

Findings works on your own project events, not just the default ones. Any active event definition with recent data is included in the daily refresh. Events linked to a conversation are measured as a rate over conversations. Events without a conversation are measured by volume, and qualify when the current window exceeds the expected count by at least 50% and 5 events.

​
From the Kapso Agent and MCP

Findings are also available to agents through the findings tool on the Kapso MCP server, with the actions list, get, read_evidence, start_investigation, dismiss, and mark_addressed.

​
From the API

The Platform API exposes the same operations with a project-scoped X-API-Key. The project comes from the key, so there is no project ID in the path.
GET /findings returns findings with status candidate or open. Quiet and dismissed findings are left out, as are findings from sources that Kapso does not read evidence from yet. GET /findings/{id} is not filtered — it reads any finding in the project, including quiet and dismissed ones, and caps related_findings at 24 entries. limit must be between 1 and 25 and defaults to 20. Anything else returns 400. Grouped findings stay on the same page, so a page can hold slightly more than limit items. paging.next and paging.previous are opaque cursors, not URLs. Pass one back as after or before, never both.
Starting an investigation returns 202 and runs asynchronously — poll the finding to read the result.

​
API errors

Some errors carry a code alongside the message. It is how you tell apart the two reasons an endpoint returns 404:
Validation and pagination errors return error only, with no code.