Skip to main content
Analysis surfaces per-call observations; triage is how you turn the recurring ones into findings you actually fix. This guide covers the loop from a raw observation to a published solution.

​
1. Curate a finding

The per-call analysis_findings produced during analysis are observations on a single call. A finding sits one level up: a durable, shareable issue that draws its evidence from the calls you link to it. From Findings, create one when you see the same problem across calls, or promote a single telling example.

​
2. Set the metadata

From the finding detail page, set:
  • Status — open / acknowledged / resolved / ignored.
  • Priority — none / low / medium / high / urgent.
  • Assignee — the org member who owns it.
  • Category and tags — for grouping and filtering.

​
3. Anchor the evidence

Link the conversations that exhibit the problem (linking is idempotent), then annotate the exact moment: a comment can be anchored to a transcript slice with start/end timestamps — “the agent talked over the caller from 0:42 to 0:51” — instead of describing it in prose.

​
4. Hand it off

  • Copy a finding prompt — a packaged summary (title, category, status, description, agents, linked calls) you can hand to an LLM for a deeper look or a draft fix.
  • Push to Linear — turn the finding into a tracked issue, with a link back to the Zelto finding.

​
5. Propose a solution

When you know the fix, capture it as a solution: an agent-scoped change linked to one or more findings, with an owner and a status. Solutions start as drafts and move to backlog when you publish them. See Solutions.

​
Do it programmatically

Findings are fully scriptable over the REST API and MCP — create_finding, update_finding, add_conversation_to_finding, annotate_finding_conversation. Solutions are MCP-only (create_solution, publish_solution, link_finding_to_solution).