How to Build a Sentry Triage Agent

Sentry captures every error in production and presents them as issues, grouped, tagged, and ranked. What it cannot do is make anyone look. Most engineering teams carry a backlog of untriaged issues, new errors get a glance during standup, and the regression that matters is buried under noise from a browser extension. A triage agent that reads each new issue properly, forms a hypothesis, and puts it in front of the right person changes that. This guide covers building one, drawing on FISTA Solutions' AI agents delivery in engineering operations. It complements how to build a github ai agent and ai code review.

How does integration work?

Through webhooks that fire on new issues and regressions, and the API for the detail: the issue, its events with full stack traces and breadcrumbs, tags, the release it first appeared in, and assignment and comment endpoints. An internal integration or scoped auth token grants read access plus the ability to assign and comment.

Permission	Granted	Reason
Read issues, events, releases	Yes	Grounding
Assign issues	Yes	Routing
Comment on issues	Yes	Hypothesis and context
Link issues	Yes	Deduplication
Resolve or ignore	No	Hides live errors
Modify alert rules	No	Affects everyone

What does the agent read?

Everything Sentry attached, in a specific order. The stack trace, distinguishing application frames from library frames. The breadcrumbs, which show the sequence of events leading to the error and often contain the actual cause. Tags such as environment, browser, device, and user segment, which distinguish a universal bug from a platform-specific one. The release in which the error first appeared. And, through the source control integration, the diff between that release and the previous one, because a new error in a new release is usually caused by something in the diff.

That last source is what separates a useful hypothesis from a restatement of the stack trace.

How is a hypothesis formed?

By reading the application frames, the breadcrumbs, and the release diff together, and stating what most likely caused the error with the evidence cited: this frame, this breadcrumb sequence, this changed function in the release. The hypothesis is labelled as one, attached as a comment, and the engineer confirms or corrects.

The agent should say when it cannot form one. An error with only library frames, no breadcrumbs, and no release correlation warrants a comment saying so and a routing decision, not a speculative narrative. Confident wrong hypotheses cost more time than honest uncertainty.

How is routing decided?

From code ownership. The application frames in the stack trace name files; the repository's ownership definitions map files to teams; the agent assigns to the team that owns the file where the error originated. That is more reliable than keyword matching on error messages and reflects who can actually fix it.

Where ownership is ambiguous or missing, the agent says so and routes to a default triage owner rather than guessing, and the gap in ownership definitions is worth reporting because it will recur.

How are related issues linked?

By comparing stack trace signatures, error messages, affected files, and timing. Sentry groups events into issues, but the same underlying cause frequently produces several issues with different signatures, and a regression often resembles an issue resolved months ago. The agent links candidates with its reasoning so the engineer sees the family rather than one member, and it surfaces the past issue's resolution when a resolved issue's pattern reappears.

When should the agent draft a fix?

For well-understood patterns with clear evidence: a null dereference where the fix is a guard, a missing error boundary, an obvious regression where the release diff shows the change and the reversal is clear. In those cases the agent drafts a fix as a pull request with the hypothesis, evidence, and the issue linked, and an engineer reviews, runs the tests, and merges or rejects.

The agent never merges, never deploys, and never drafts fixes for errors where the cause is unclear, because a plausible wrong fix that passes review is worse than no fix. See how to build a code review agent.

What should the agent never do?

Resolve issues, since resolving hides an error that may still be occurring. Ignore or mute issues, for the same reason. Change alert rules or thresholds, which affects everyone's notifications. Merge its own pull requests. Or comment on every event, which turns triage into noise. One comment per issue with the hypothesis, routing, and links is the right volume.

How is noise managed?

By respecting Sentry's own grouping and by prioritising. The agent should triage new and regressed issues, not every event, and should prioritise by user impact, environment, and whether the release is recent. Issues from browser extensions, bots, and known-noisy sources should be recognised and deprioritised rather than given the same attention as a production regression affecting many users.

How is it evaluated?

Hypotheses against the confirmed cause once the engineer investigates, tracking correct, wrong, and misleading separately. Routing against where the issue was actually fixed. Linking against engineer judgement on a sample. Fix pull requests by review outcome. And the outcome measure: time from issue creation to first engineer action, and the size of the untriaged backlog, before and after.

What does the build sequence look like?

One week on webhooks, scoped token, and reading issues with events and releases. One week on routing from code ownership. Two weeks on hypothesis formation with release diff correlation, reviewed by engineers. One week on issue linking. Fix drafting last, restricted to patterns with strong evidence.

What goes wrong?

Tokens that can resolve. Hypotheses from the stack trace alone, ignoring breadcrumbs and the diff. Keyword-based routing. Comments on every event. Fixes drafted for unclear causes. And an agent that triages everything with equal attention, so the regression affecting thousands of users gets the same treatment as a bot's malformed request.

How FISTA Solutions helps

FISTA Solutions builds Sentry triage agents that read traces, breadcrumbs, and release diffs together, form labelled hypotheses, route from code ownership, link related issues, and draft fixes as reviewed pull requests for well-evidenced patterns, without ever resolving or muting, through AI enablement, AI agents, and forward deployed engineers working with engineering teams. The record behind the approach is 150+ projects for 50+ companies with 99.9% uptime.

To clear the error backlog and catch regressions faster, message FISTA on WhatsApp, or read ai code review.