How an investigation works
The five steps between a ticket arriving and a root cause appearing, and which configuration governs each one.
Understanding this sequence is what makes the configuration pages make sense — each step is governed by something an admin sets.
The pipeline
The ticket arrives
Via a HubSpot webhook or the two-minute poller. Contact and company associations are
fetched, then an LLM extracts the identity fields Triagic needs:
merchantName, storeName, userId, email.
Governed by: your HubSpot connection, and PII redaction which scrubs the subject, body and metadata before any of it reaches a model.
The user's funnel drop-off is computed
The last 72 hours of that user's events are compared against your configured product funnel, producing the step where they fell out.
Governed by: your PostHog connection and funnel definition.
Similar past tickets are retrieved
Vector search over previously triaged tickets pulls the top five most similar ones and injects them — with their confirmed root causes — into the prompt. This is why Triagic gets better at your product over time without anyone training anything.
Governed by: whether your AI provider supports embeddings. Without embeddings, vector search degrades gracefully rather than failing.
A playbook is chosen
An LLM classifier matches the ticket against every enabled playbook's description and routing hints and assigns one. An engineer can override the assignment from the ticket page, which pins it so the classifier will not touch it again.
Governed by: your playbooks.
The agent investigates
The agent loops — up to 25 tool iterations — calling read-only tools across the MCP
servers the playbook allows, citing evidence per system, and finally writing a root
cause report. The ticket moves to triaged and the report appears in the inbox, with
follow-up chat available on the ticket.
Governed by: the playbook's triage instructions and data sources, and your organization's spend cap.
Where classification actually happens
Only at ingest, or on an explicit Re-investigate. A ticket already sitting in the inbox will not retroactively pick up a playbook that was created afterwards — you have to re-investigate it. This trips people up right after they write their first playbook.
A ticket that matches no playbook is triaged generically: the standard prompt, all tools available. That is a working default, not a failure.
Why scoping data sources is not just a permissions knob
A playbook's data-source allowlist is what the agent can see. Narrowing it makes investigations faster and cheaper and stops the agent wandering into irrelevant systems — but it also means a root cause living outside the allowlist is unreachable, and the agent will correctly report that it could not determine one.
The honest test for a new playbook is to run the same ticket twice, once scoped and once unscoped, and see whether the scoped run still finds the answer.
Cost
Every LLM call — agent iterations, the classifier, metadata extraction, embeddings — is logged individually with its model, token counts, latency and USD cost. A single investigation makes several calls and is presented as one folded total in the UI.
Cost is snapshotted at write time, so correcting a price later never rewrites history. Totals, per-model latency percentiles, a per-task split and a daily cost chart live on the desktop's Usage page; the organization-wide cap that stops runs lives in the portal.