Built for investigating, not just labeling

Every part of Triagic exists to answer one question faster: what actually happened, and why. Here is the whole product, from a ticket landing to the reply going out, and the guarantees underneath it. One seat plan, with optional add-ons for Checkups and Forms + email.

Start 14-day free trial Read the docs

What happens when a ticket arrives

Five steps, each governed by something an admin configures. Understanding this sequence is what makes the rest of the page make sense.

1
The ticket arrives
By webhook, or by a poller that runs every two minutes. Emails, phone numbers, IDs, IP addresses and card numbers are redacted before any of it reaches a model, and then the identity fields are extracted: who this is about, and which account.
2
Context is assembled
Vector search pulls the five most similar past tickets with their confirmed root causes. If a PostHog funnel is configured, the step this user fell out of in the last 72 hours comes with it.
3
A playbook is chosen
A classifier matches the ticket against every enabled playbook's description and routing hints. Assigning one by hand pins it, and the classifier leaves that ticket alone from then on.
4
The agent investigates
Up to 25 tool iterations across the data sources that playbook allows. Every call is read-only, and every call is shown in the UI as it happens. The result is a root cause with evidence cited per system.
5
A person answers
The report drafts a reply to the customer. Someone reads it, edits it, and presses Send. The agent has no email tool, by construction.
The pipeline in detail
Every call in that sequence is logged with its model, tokens, latency and cost. An investigation is several calls and shows up as one folded total.

The inbox

Tickets that arrive already investigated

The desktop app is where the work happens. A triaged ticket opens with a conclusion, the evidence behind it, and the trail of everything the agent touched to get there.

Root cause with cited evidence: The report names what broke and cites each system it came from. A root cause with three corroborating sources is worth more than a confident one with none, so the evidence is the part you read.
Every tool call, in order: Tool chips list what the agent called and when. Where it looked is as informative as what it found, and it's how you tell a good playbook from a wandering one.
Follow-up chat on the ticket: Ask a question under the investigation. It runs with the same playbook and the same allowlist, replays the last 20 turns, and is shared per ticket so a colleague can pick up where you stopped.
Re-investigate, or pin a different playbook: If the agent searched the wrong systems, assign a better playbook and run it again. Manual assignment pins the ticket so auto-classification will not overwrite your call.
A suggested reply a human sends: The draft opens in a dialog with the recipient prefilled from the ticket. What you see is exactly what goes out, with no server-side rewriting, and the send is recorded on the ticket and in the audit log.
Activity timeline: Notes, logged emails and attachments pulled from the source system, interleaved with what your team sent from Triagic. Opening a ticket re-syncs it and re-signs the attachment links.
File it to GitHub or GitLab: Turn a finished triage into an issue with the investigation attached, or comment on the issue that already covers it. Duplicate filings are guarded against.
Nothing is trapped in the app: Every prompt, every answer, every chat message and the whole investigation as markdown each have a copy button. Filter the inbox by playbook, including an explicit no-playbook view.

Console

Ask across every system at once

Not every question has a ticket behind it. A customer is on the phone, an alert fired, or you want to check something before anyone files anything. The Console is the same agent with no ticket attached.

Plain language, live tool calls: Ask what happened. The agent queries your databases, reads logs and checks metrics while you watch each call land. No pre-built dashboard to maintain.
Developer and support answers: One toggle sets who the answer is written for. Developer mode gives table names, error codes and log excerpts. Support mode rewrites the same finding in plain English with a suggested reply you can send as-is.
Pin a playbook to a thread: Applying a playbook's instructions and allowlist to a whole conversation makes it faster and stops it rummaging where the answer isn't. Leave it unpinned when you genuinely don't know where to look.
Threads that remember: Each investigation is its own thread, private to you, replaying the last 20 turns so a conversation builds. Tool traces stay in the UI and out of the model's context, so the audit trail costs no tokens.
Pick the model per thread: The picker offers your organization's configured deployments. Order of resolution is the thread's choice, then the install's runtime default, then the fallback.
Charts, and scheduled reports: Answers can render charts and diagrams inline. A playbook can run on a cadence and post its result as a shared thread under Reports, where anyone who can see the playbook can ask it follow-ups.

Intake

Wherever your tickets already live

Connect the queue you have, or publish a form and start receiving your own. Ingest is webhook-first with a two-minute poller behind it, so a source works with only its credential filled in.

HubSpot, Zendesk, Jira, Slack: Each source carries its own filters, which gate the webhook and the poller identically. Jira also takes raw JQL when the filter fields aren't enough.
Auto-triage is off by default: Connecting a source starts ingest, not LLM spend. Tickets arrive, get embedded and classified, and wait for someone to hit Investigate now until you switch triage on. Pausing later stops the spend without losing the queue.
Your own hosted forms: Build a public intake form in the portal: nine field types, up to 20 sections of 60 fields, and conditions that show a field only when another has a given value. Publishing versions the form, so an old submission still reads with the labels it was filled in against.
Hosted link or embedded: Share the link, or turn on embedding per form and drop it into your own site in an iframe. Embedding is off by default and a form with it off refuses to load inside a frame.
One email thread per request: A submission becomes a ticket with the customer's address on it. The acknowledgement, your replies and theirs all stay on that ticket in one thread. A reply can reopen a resolved ticket, and a resolve notice is available.
Attachments, bot check, theming: Up to five files per submission with a size limit you set between 1 and 10 MB, an optional Cloudflare Turnstile check, team notifications by email and Slack, and a logo, accent colour and font of your own.

Configuration

Teach it your systems once

A generic agent gives generic answers. Playbooks, a knowledge base and scoped data sources are what turn it into somebody who knows your product.

Playbooks, per class of ticket: Four fields: a description and routing hints the classifier reads at ingest, triage instructions the investigating agent reads during the run, and the data sources the tool layer will allow. Different tickets need different procedures and different access. Admins can have one drafted from a prompt and revise it by asking.
Scope the tools, not just the prompt: A playbook's data-source allowlist is what the agent can see. Narrowing it makes runs faster and cheaper. Leave it empty and the agent gets everything, which is a fine place to start.
Knowledge base: Upload runbooks, product notes, escalation rules and exported sheets as Markdown, text, CSV, JSON, DOCX, PDF or XLSX, or connect Notion and Confluence to read live pages. The agent searches it before answering a product question and names the document it used. Admins can also describe a doc and have it written from your tickets and data, then revise it by prompt, keeping or discarding each change.
Document text is untrusted: Knowledge content is treated exactly like ticket text. Instructions written inside a document can't change how the agent behaves.
Teams and visibility: Playbooks can be organization-wide or restricted to selected teams. Team scoping governs who can use a playbook by hand; auto-classification still considers every enabled one.
The portal is the source of truth: Admins configure the organization in the web portal: members, teams, playbooks, shared credentials, knowledge, spend cap. Each desktop pulls that down on a schedule and runs against it.

Dashboards

Numbers you can open without spending AI

An admin describes what the team should watch. AI writes the queries once, and from then on the dashboard is those saved queries, run straight against your own data sources.

Built from a prompt: Say what you want to see and pick the sources. Triagic reads their schemas and proposes KPIs and charts. Untick what you don't need, and each one you keep becomes one saved read-only query with its chart.
Priced before you pay: The proposal shows a build price per item, and every button that spends AI shows its price first. A per-run cap, $1.00 by default, stops a run that goes over and keeps what it already built.
Free to open and refresh: Opening a dashboard, switching between 7, 30 and 90 days and pressing Refresh replay the saved queries with no model. A broken query can be repaired by AI or edited by hand, and the hand edit is free too.
Your access, your machine: Queries run from each viewer's desktop over their own connections. A chart over a source someone can't open shows them a locked tile, and results are never sent to Triagic.

Checkups

The same agent, pointed at everything

A playbook answers why this broke for this customer. A checkup asks what is wrong across all of it: a standing read-only procedure you run on demand or on a schedule, against your systems and your own support history.

Fifteen curated procedures: Shipped with the app and there on first launch, across seven categories: cost and performance reviews, access and credential reviews, a PII exposure sweep, SLA and response quality, ticket trend analysis, incident readiness, GitHub and GitLab code review, and a SOC 2 readiness walkthrough.
Write your own, or generate one: Describe what you want reviewed and have the procedure drafted from the integrations you actually have connected, then edit it before it ever runs.
Watch it work, then keep asking: Follow a run live as it happens, get notified when the report lands, and keep questioning the report in its own thread. Anyone in the organization can ask follow-ups there.
A findings ledger, not a pile of reports: Findings keep their identity from one run to the next, so you can see what is new, what came back and what stayed fixed. Set a status, assign one, or promote it to a ticket that then gets triaged like any other.
Schedules, and scope per checkup: Run one now or on a cadence. Each checkup has its own data sources, and an empty setting means every server your organization has. App upgrades refresh the shipped content and never touch your scope, your schedule or your enabled flag.
Recommendations are proposals: A checkup that says drop this warehouse to size M has not dropped anything. Everything it produces is a suggestion for a person to apply, deliberately, in that system's own console.

Control

What it can't do is the feature

You are about to hand an AI agent credentials to production. The guarantees below are enforced in the tool layer and in the code path, not by asking a model to behave.

Read-only, filtered before the run: Write, mutate and delete tools are filtered out before any agent run sees them, when a server connects and again at every dispatch. Catalog integrations expose only the tool names verified as reads; any other server has to annotate a tool read-only or it isn't exposed at all.
Your credentials, least privilege: A handful of upstream servers have no read-only mode of their own, and those are named in the docs. Point every integration at a read-only user or a read-scoped token and the guarantee stops depending on any single layer being bug-free.
PII redaction on every path: Emails, phone numbers, national ID numbers, IPv4 addresses and Luhn-valid card numbers are stripped from the subject, body and metadata before a prompt is assembled. Background triage, the Console, ticket chat, classification and similar-ticket search all run it. None of them skip it.
Encrypted at rest, twice: Credentials are AES-256-GCM encrypted under the platform key, and re-encrypted on arrival under a key that never leaves that machine. No endpoint and no admin screen returns a plaintext secret; API responses carry masked values only.
Shared credentials without sharing them: A member can use a shared integration and cannot recover its secret or repoint it. The member-facing view has no credential fields at all, not even masked ones, and editing shared configuration takes an admin.
Append-only audit log: Every mutation to authentication, organizations, teams, playbooks, integrations, issue trackers, filed issues, emails sent and playbook assignment writes a row with actor, action, target, before and after, and a timestamp. Admins only, enforced by the service rather than hidden in the nav.
A spend cap that actually stops runs: One monthly USD number for the organization. Every LLM call is logged individually with its model, token counts, latency and cost, snapshotted at write time so correcting a price later never rewrites history.
Cost and latency you can read: The Usage page carries totals, per-model latency percentiles, a per-task split and a daily cost chart, with links back to what caused each call. An investigation folds its several calls into one number.

57 integrations, plus anything you already run

Each one asks for its own credential and nothing else. The package, arguments and transport behind it are derived for you, so upgrades reach existing configurations on their next restart. Add a catalog entry twice for production and replica, tag each with its environment, and scope a playbook to exactly one of them.

Anything else: Point Triagic at your own MCP server, as a command or a remote HTTP endpoint. It goes through the same read-only tool gate as everything in the catalog.
Bring your own model: Connect your own provider credentials and every call runs against your own contract and rate limits. Ollama is on that list, so the model can stay on your hardware too.Azure OpenAI, OpenAI, Anthropic, Google (Gemini), OpenRouter, Ollama
Nothing to install first: Most integrations spawn a local process, so the installer ships a portable Node LTS and a portable uv ahead of the app's own PATH. Every integration runs on the same runtime whatever the machine has on it. Five talk to hosted endpoints over HTTPS and need no runtime at all; three run in Docker, which is the one thing you install yourself.Per-integration setup steps

What Triagic deliberately doesn't do

These are design decisions, not gaps in the roadmap. Each one is the reason someone is willing to connect production in the first place.

It doesn't write to your systems: There is no write path to enable. The tool filter is global and applies to ticket investigations, Console questions and checkups alike.
It doesn't email anyone: The agent has no email tool. Not disabled, not gated behind a permission. A person opens the draft, edits it, and presses Send.
It doesn't copy your data anywhere: No pipeline, no warehouse sync, no third-party copy of your database. The app runs on your machine, against your systems, over your network. If you need a VPN to reach production, so does Triagic.
It doesn't resell you model capacity: Your provider key, your contract, your rate limits. Triagic never proxies model spend through a shared account.
It doesn't reclassify old tickets quietly: Classification runs at ingest or on an explicit re-investigation. A ticket already in the inbox will not silently pick up a playbook written afterwards.
It doesn't certify anything: The SOC 2 readiness review is an evidence-collection exercise, not an audit and not a certification. Only a licensed CPA firm can perform a SOC 2 examination.

See it work on a real ticket

Every feature on this page is unlocked from day one. Start a 14-day free trial, no credit card required.

Start free trial View pricing

What happens when a ticket arrives

The ticket arrives

Context is assembled

A playbook is chosen

The agent investigates

A person answers