Can you use an AI agent to triage Sentry issues?

Sentry triage is the canonical "agent reads stack trace, opens file, narrows it down" loop, and it's the cleanest way to demonstrate why local-first parallel agents are useful. The stack trace points the agent at the file; the worktree gives it a scratch space to reproduce; the test runner verifies the diagnosis. No human has to copy-paste anything.

KanBots ships the integration end-to-end: webhook ingestion, automatic card creation, agent dispatch from the card, and a one-click Promote path to a draft PR if the agent's fix passes its own checks.

How Sentry gets onto the board

KanBots talks to Sentry through its standard Sentry App OAuth flow. On install, you pick which Sentry org and which project; KanBots stores the installation ID and mints short-lived API tokens against the App's private key. From that point Sentry delivers webhooks to KanBots: installation.created confirms the bind, then issue.created and event_alert.triggered drive the card flow.

The recommended setup is a Sentry alert rule that fires when event count exceeds some threshold per hour — "send to KanBots integration" as the action. That way you're not drowning in a card per single-occurrence error. The webhook payload includes event.title, event.culprit, event.stacktrace, event.environment, and a running event count. KanBots formats the stack trace into the card body inside a fenced code block and applies a sentry label so you can filter the column later.

Duplicate handling is idempotent: each Sentry issue ID maps to one card via the card_external_links table. If the same error recurs an hour later, KanBots updates the existing card with the new occurrence count instead of creating a clone.

What an agent does with a Sentry card

Click Dispatch. The dispatcher creates a worktree at .kanbots/worktrees/issue-N-runId/ off the default branch and spawns claude -p (or codex exec if you've picked that adapter) with the card body as the prompt. The body contains the stack trace, so the first thing the agent does is read the file mentioned in the top frame.

The engineer persona prompt directs it to: reproduce the error locally, identify the root cause, decide whether the fix is bounded or requires changes outside the immediate file, and report back. The live agent thread shows every tool_use as it happens — you watch the agent open files, run pnpm test path/to/file.test.ts, and surface its findings.

When the diagnosis is solid, the agent typically does one of three things:

• Posts a verdict in the card thread ("Null deref because user.org is undefined for SSO users; needs a guard at line 84") and stops, letting you decide the fix shape.
• Writes the fix, runs the test suite in the worktree, and posts the diff. You hit Promote to open a draft PR.
• Asks a decision question — "this looks like it needs a schema migration, do I proceed?" — and the run pauses on awaiting_decision until you answer.

Walkthrough — first Sentry triage run

1. In KanBots, open Settings → Integrations and click Connect Sentry. Pick your Sentry org. The Sentry installation page appears; pick which Sentry projects to expose.
2. In Sentry, create an alert rule on the project: "when event count > 10 in 1 hour, send notification to KanBots." Save.
3. The next time that error crosses the threshold, a card appears in your KanBots Inbox titled [Sentry] <error title> with the stack trace in the body.
4. Drag it to backlog if you want to triage it later, or click Dispatch directly. The run drawer slides open.
5. Watch the live thread. The agent reads the file in the top frame, then walks outward. Cost ticks up in the run header.
6. When the run finishes, you have a verdict or a diff. Click Promote → Open draft PR (GitHub mode) or Promote → Land commit (local mode). The pre-push hook prevents the agent from doing this itself.

Failure modes and fixes

The agent misdiagnoses errors that need prod data

Symptom: the error happens only for a specific user ID or only for a specific timezone. The agent can read the stack trace but it can't query your production database to see what shape the input actually had. It produces a plausible-looking fix that's wrong because it's based on a guess at the input. Fix: include a breadcrumbs field or a sample event JSON in the Sentry payload (Sentry sends these by default; KanBots includes them in the card body). If even that isn't enough, mark the card needs:prod-repro and skip the agent dispatch.

The stack trace points at a third-party module

Symptom: top frame is in node_modules/@sentry/... and the agent gets lost reading your dependencies. Fix: tighten the engineer persona prompt to require the first user-code frame as the starting point. Or, in the agent thread, post a follow-up: "ignore frames inside node_modules; focus on the first file under src/."

Sentry sends a flood of new error groups

Symptom: a bad deploy created 40 unique error groups in 10 minutes and KanBots creates 40 cards. Fix: don't dispatch all of them; pick the top 3 by event count and let the engineer agent root-cause the deploy regression. Most of the 40 cards usually share a root cause and will auto-resolve when the regression is fixed.

When agent triage is the wrong tool

Two cases. First, anything that needs production data the agent can't see — query replays, distributed tracing across services, user-specific account state. The agent will produce a confident-sounding answer that's based on the file it could read, not the data it couldn't.

Second, security-sensitive errors. If the stack trace mentions auth, session handling, or encrypted payloads, you want a human's name on the diagnosis. The agent's verdict is fine as a starting point — but the engineer reviewing it should be a person.

For the broader "agent on the board" pattern, see how a kanban board for AI agents differs from an issue tracker and the reviewer persona that handles the PR after the engineer finishes.