Your agent can't fix what it can't see

Sergiy Dybskiy — Thu, 28 May 2026 14:04:58 +0000

Agents are getting better and better at fixing bugs. They’re even getting better at testing their work, thanks to headless browsers, sandboxes, simulators, etc.

But what about the bugs that only show up once you bring in different browsers, languages, extensions, internet speeds, and all the other variables that get mixed in the second you ship to prod? Or all the bugs that only show up when you account for… well, humans being humans and doing weird stuff you didn’t expect them to do?

The bottleneck for self-healing software isn’t agent intelligence. It’s that agents have no idea what actually broke. They’re debugging from source code alone, which is roughly as effective as diagnosing a server outage by skimming the README. What they’re missing is production context: the stack trace, the request payload, the environment, the breadcrumbs leading up to the failure.

Your agents need someone/something telling them what’s breaking in the wild and giving them the context they need to understand why.

We built Sentry MCP and the Sentry CLI to make that context available to both humans, and increasingly as important, their agents. You can wire up a system today where a Sentry alert triggers an agent, the agent investigates the issue using the same evidence you would, and a draft PR with a fix lands in your repo before you open a browser.

Why draft PRs, not auto-merge

Let’s be honest about what’s realistic. A system that detects, fixes, tests, deploys, and monitors its own patches without human involvement is not something you should build today. That’s how you get a very exciting incident review.

The useful version is more modest: a production error fires, an agent investigates it with real Sentry context, writes a small fix with a regression test, and opens a draft PR. A human is very much in the loop.

That’s not fully autonomous, but it’s not trivial either. Most bugs sit in a queue, triaged, prioritized, assigned, waiting, and often lose out to new features. Seer diagnoses the root cause in under two minutes. A complete Autofix run, from root cause analysis to an opened PR, takes about six minutes.

An agent that opens a reviewable, mergeable fix six minutes after the error fires is a meaningful change to your mean time to resolution, even if a human still clicks merge.

Two ways to give your agent production context

Sentry MCP is the right choice for agents that support the Model Context Protocol (Claude Code, Cursor, Codex, Windsurf, VS Code with Copilot). Your agent connects to the hosted server, authenticates via OAuth, and gets structured access to issues, events, traces, and Seer analysis. No local install required.

# One-liner for any MCP-compatible client
npx add-mcp https://mcp.sentry.dev/mcp

# Or for Claude Code specifically
claude mcp add --transport http sentry https://mcp.sentry.dev/mcp

If your client doesn’t support the one-liner, add the config manually:

{
  "mcpServers": {
    "sentry": {
      "url": "https://mcp.sentry.dev/mcp"
    }
  }
}

The Sentry CLI is the right choice for scripted workflows, CI pipelines, or any automation where you need structured output you can pipe to jq or feed into another process.

curl https://cli.sentry.dev/install -fsS | bash
sentry auth login

Here’s what that looks like:

$ sentry issue list

Issues in acme/checkout:
╭──────────────┬──────────────────────────────────────────────────────┬──────┬─────┬────────┬───────┬──────────────╮
│ SHORT ID     │ ISSUE                                                │ SEEN │ AGE │ EVENTS │ USERS │ TRIAGE       │
├──────────────┼──────────────────────────────────────────────────────┼──────┼─────┼────────┼───────┼──────────────┤
│ CHECKOUT-P1  │ TimeoutError: Payment charge exceeded 30s            │   3h │  3h │  1.8k  │   340 │ High  86%    │
├──────────────┼──────────────────────────────────────────────────────┼──────┼─────┼────────┼───────┼──────────────┤
│ CHECKOUT-N7  │ TypeError: Cannot read property 'total'              │   1d │  5d │    215 │    82 │ High  71%    │
├──────────────┼──────────────────────────────────────────────────────┼──────┼─────┼────────┼───────┼──────────────┤
│ API-34       │ RateLimitError: Too many requests to /v1/charges     │   3d │ 21d │     67 │    24 │ Med   42%    │
╰──────────────┴──────────────────────────────────────────────────────┴──────┴─────┴────────┴───────┴──────────────╯
Tip: Use 'sentry issue view <ID>' to view details.

CHECKOUT-P1 is at the top, a timeout in the checkout service with 1.8k events and an 86% fixability score. Drill in:

$ sentry issue view CHECKOUT-P1

CHECKOUT-P1: TimeoutError: Payment charge exceeded 30s
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
╭────────────┬─────────────────────────────────────────────╮
│ Status     │ ● Unresolved (Ongoing)                      │
│ Fixability │ High (86%)                                  │
│ Level      │ error                                       │
│ Platform   │ node                                        │
│ Project    │ checkout-service                            │
│ Events     │ 1832                                        │
│ Users      │ 340                                         │
│ First seen │ 3 hours ago                                 │
│ Last seen  │ 12 minutes ago                              │
│ Culprit    │ chargeCustomer (src/payment.ts)             │
│ Link       │ https://acme.sentry.io/issues/CHECKOUT-P1/  │
╰────────────┴─────────────────────────────────────────────╯

Tip: Use 'sentry issue explain CHECKOUT-P1' for AI root cause analysis

Looks like a straightforward timeout. An agent with just this would add retry logic or bump the timeout. But run sentry issue explain:

$ sentry issue explain CHECKOUT-P1

ℹ Starting root cause analysis, it can take several minutes...

Root Cause Analysis Complete
━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Cause #0: The checkout service's /charge endpoint times out
waiting for the payment service, which blocks on an inventory
availability check. The inventory service's check_stock query
regressed from ~200ms to ~28s after migration
0047_drop_unused_indexes removed the compound index on
(product_id, warehouse_id).

Repository: acme/inventory-service
Affected: src/queries/check_stock.ts:18
First seen: release-3.1.0 (deployed 3h ago)

Reproduction steps:
1. User submits checkout → POST /charge
2. Payment service calls inventory.check_stock(items)
3. check_stock runs full table scan (missing index) → 28s
4. Payment call exceeds 30s timeout → TimeoutError bubbles up to checkout

To create a plan, run: sentry issue plan CHECKOUT-P1

The root cause isn’t in the checkout service at all. It’s a dropped database index in the inventory service, two hops away in the trace. No amount of retry logic in payment.ts fixes that.

From alert to draft PR

When a Sentry alert fires on a new or regressed issue, a webhook triggers a worker that checks out your repo and runs a coding agent with a prompt grounded in the specific issue:

A production error was captured by Sentry. The issue ID is CHECKOUT-P1.

Use Sentry MCP to retrieve the full issue details: stack trace,
breadcrumbs, tags, release, environment, distributed traces,
suspect commits, and Seer analysis.

Based on the evidence:

1. Identify the root cause. Follow traces across services.
2. Make the smallest safe fix in the right repository.
3. Add or update a regression test that covers this failure.
4. Run the test suite.
5. Open a draft PR with the Sentry issue link, root-cause
   summary, files changed, and test results.

The agent pulls the issue via MCP. The distributed trace shows the checkout call chaining through the payment service into an inventory check that’s taking 28 seconds. Metrics confirm the inventory service’s p99 spiked from 200ms to 28s three hours ago. Suspect commits point at a migration in acme/inventory-service that dropped a compound index. Session replay shows users rage-clicking “Pay” while nothing happens, generating duplicate charge attempts.

sentry issue plan CHECKOUT-P1 lays out the fix: restore the compound index on (product_id, warehouse_id). A draft PR lands in acme/inventory-service with the migration, a root-cause summary linking back to the Sentry trace, and a regression test.

Try it with Cursor Automations

We publish a cookbook recipe for this exact workflow using Cursor’s Automations feature. It walks through connecting your repo to Sentry, adding the MCP server to an automation, and configuring a webhook alert to trigger on regressed issues.

Because Sentry knows the release history and suspect commits, the agent doesn’t search the entire repo for the problem. It starts where the evidence points. For regressed issues specifically, it can identify which commit reintroduced the bug, read the original fix, and understand what went wrong the second time around.

What’s next

The more telemetry your app sends to Sentry (traces, metrics, logs, session replays), the harder the bugs an agent can tackle. Today it’s dropped indexes across service boundaries. Six months ago it was null checks. The merge rate on Autofix PRs has climbed from 41% to 46% in that time, and the diagnosis complexity is growing with it.

There are real limits. Bugs that need product judgment, issues in code the agent can’t reach, and problems where there isn’t enough telemetry to connect the dots: those still need you. But the surface area of what agents can fix is expanding every month.

Connect Sentry MCP to your editor or install the CLI. Hook up your repos for code mappings and tracing. Run sentry issue explain on something that’s been sitting in your backlog and see what it finds.

Check out the Seer Autofix docs for more on coding agent handoff to Claude Code and Cursor.