End-to-End Agent Workflow From Sentry Alert to Merged PR

An automated pipeline that takes a Sentry alert and turns it into a merged fix sounds, on paper, like a straight line: an error fires, an agent writes a patch, a pull request opens, someone clicks merge. That framing hides the actual engineering problem. A Sentry alert carries enough signal to drive a fully automated fix workflow, but only if each stage of the pipeline does its job correctly: ingestion, enrichment, generation, validation, and review routing. A failure at any one of those stages produces a pull request that no one should merge, no matter how clean the diff looks. A stack trace points to where an error surfaced, not necessarily to where it originated, so a fix attempted without proper enrichment often patches the symptom and leaves the actual defect in place. Opening a pull request without validating it against the test suite doesn't save a reviewer time either; it hands them a guess to audit, which is slower than writing the fix themselves. Three coupled capabilities make this pipeline trustworthy: alert ingestion, context enrichment, and code generation with self-correction, and they run in sequence, each one feeding the next. What follows is a stage-by-stage account of how that sequence actually works, so that anyone building or auditing a pipeline like this knows what each link is supposed to deliver before the next one can do its job.

Stage 1: What the Sentry alert actually delivers to the agent

The alert reaches the agent through a webhook, and the agent's first action is to read the error message, the full stack trace, and the list of affected files. That much is standard. What makes this starting point more useful than a raw exception log is that Sentry's telemetry is already trace-connected at the moment of ingestion. When an error fires, Sentry already knows the trace it happened in, the spans inside that trace, the logs emitted during those spans, and which deploy was live at the time. That pre-built graph means the agent does not have to perform a manual "search for related logs" step before it can start reasoning about the problem; it can walk the graph directly from the alert itself.

Alert ingestion is also where classification happens, before any fix attempt begins. The agent has to decide, right at this stage, whether the issue is something it can resolve on its own or something that needs to go to a person. Null reference errors, type mismatches, missing imports, obvious logic bugs, and unhandled edge cases are the kind of problems an agent can reasonably fix without supervision. Architecture issues, unclear business logic, security-sensitive code, and database migrations are not. The Clawdbot and Codex workflow builds this distinction directly into its triage instructions, making the autonomous-versus-escalate decision explicit before a single line of code gets touched. That classification step is the hinge the rest of the pipeline turns on: an alert cleared for autonomous handling moves forward into enrichment, while one that fails the test gets routed to a human immediately, before any time is spent generating a fix nobody asked for.

Stage 2: Enriching the alert with codebase and deployment context

Once an alert clears triage, the agent's job becomes investigation, and that investigation follows a structured path: stack trace, then correlated logs, then recent commits, then code analysis, each step narrowing the search space before the agent touches a single file. The quality of this stage shapes whether the eventual fix addresses a root cause or just a symptom.

What separates this from a keyword search across a codebase is that the agent traverses Sentry's trace graph directly. Seer Agent pulls the exact trace that produced the error, the spans inside that trace, the logs those spans emitted, and the source lines the spans trace back to, all without running a single time-range query. It can also walk that graph in the other direction, checking which other services participated in the same trace and which of them were unhealthy at the same moment. That capability turned out to matter in a very concrete way. During a Saturday outage of Sentry's own AI debugger, Seer Agent identified that LLM calls were being rate-limited in specific regions for a specific model, a finding that would normally take four separate manual pivots to reach. Seer Agent reached it in a single pass, before the on-call engineer had even joined the incident channel. Trace-graph traversal buys minutes over a multi-step manual investigation.

Deployment history is part of this enrichment step, not an optional add-on. The agent checks which deploy was live when the error occurred and which commits that deploy contained, attributing a regression to the change that actually caused it. For dependency vulnerabilities, the same model extends outward: a Dependabot alert handed to an agent comes with the advisory details and the repository's dependency usage graph, so the agent has a map of what else in the codebase touches the vulnerable package before it proposes anything. Sentry formalizes the delivery side of this context through its agent plugin architecture: sentry-for-ai packages Sentry skills, such as issue triage, SDK setup, and alert configuration, into installable plugins for Claude Code, Cursor, Codex, and Grok, giving a coding assistant structured Sentry context to work with.

Stage 3: How the agent generates and self-corrects the fix

Writing a patch is not where the agent's work ends. It operates a plan-execute-test-adjust loop, running the test suite after every change it makes and revising the implementation until that suite passes clean. The loop runs in stages of its own: the agent plans which files and functions need to change based on what enrichment turned up, makes a targeted edit, immediately runs the test suite and linter, and reads the resulting failure logs closely enough to tell a test it just broke apart from a failure that already existed before it touched anything. It revises and re-runs until the result is green. The Clawdbot and Codex pattern makes this a hard requirement rather than a suggestion: Codex has to run tests and the linter before it commits anything, and the fix does not get committed until both pass.

Isolation is built into this process as a structural safety property, not a best practice someone decided to follow. The agent creates its own git worktree branched from staging, so the main repository is never touched during the work, and multiple worktrees can run in parallel on different fixes without any risk of interfering with one another. The Clawdbot and Codex workflow states this explicitly: the main repo stays untouched, and all work happens inside an isolated worktree from staging.

Inside the generation step itself, the model doing the work is not a single system handling every task. Sentry's Autofix runs a heterogeneous stack: Anthropic's Claude 3.7 Sonnet handles reasoning, while Google's Gemini Flash 2.0 serves as the research agent. One model reasons about the fix, another retrieves the information that reasoning depends on, and the orchestration connecting them matters as much as either model alone. The same loop structure applies when the trigger is a dependency alert rather than a runtime error: assigning a Dependabot alert to an agent sets off an analysis of the advisory, a draft pull request, and an attempt to resolve any test failures the dependency update itself introduces.

Stage 4: Opening the PR and routing it to the right reviewer

Opening a pull request is the easy part of this stage. Getting it in front of the right engineer quickly is what actually decides whether the automated fix speeds the team up or just adds a new kind of backlog to manage.

What the agent puts into that pull request matters for how fast a human can act on it. The branch is created from staging. The commit message and PR description explain the root cause the agent found and the reasoning behind the fix, not just the lines that changed. Test results confirming the suite passed are attached before the PR ever opens. For Dependabot-assigned alerts, the PR opens as a draft and stays that way until the agent itself is satisfied that tests pass.

Routing that finished PR to the right person is a second layer of automation, because Sentry runs one in production. Every new Seer PR surfaces in a dedicated Slack channel. A Claude routine checks that feed every four hours for PRs that haven't been acted on, and it identifies the right reviewer by querying commit history to find the engineer who worked most closely with the flagged code. It then tags that engineer directly in the PR thread and asks for one of three things: merge it, close it, or leave a single line of feedback. The routine runs on that schedule unattended, with no human kicking it off each time.

GitHub's Dependabot alert assignment gives teams weighing multiple approaches a comparison mechanism, allowing multiple agents, Copilot, Claude, and Codex among them, to be assigned to the same alert at once. Each works independently and opens its own draft PR, which lets a team compare approaches side by side before deciding which one to merge.

What the human reviewer's job actually looks like after automation

None of this automation removes the need for a human reviewer. It changes what that reviewer spends time on, shifting attention toward architecture, business logic, and the edge cases that genuinely require judgment.

A reviewer working downstream of this pipeline no longer has to reproduce the error, gather logs, and correlate them against deployment history, because enrichment already did that work. Writing the fix from scratch is off the list too, since the agent already produced one. Running the test suite to check whether the fix holds up is also done, handled by the self-correction loop before the PR ever opened. Even finding the right person to look at the PR is handled, by the routing routine described above. What's left for the reviewer is the judgment call the pipeline cannot make on its own: confirming that the fix is sound architecturally, not just correct in the narrow, local sense that passing tests can confirm.

Sentry's early results from running this internally offer a useful data point on what that judgment looks like in practice. A rise in PRs that get closed without being merged is not evidence that the pipeline is failing. It reflects engineers choosing a more complete fix over the automated one, or catching that the same issue was already being addressed elsewhere. Either outcome means the routing worked and the engineer engaged with the PR. A healthy close-without-merge rate is a sign the human gate is doing what it's there to do.

Where Human Approval Must Stay in the Loop

Every capability that lets an agent open a pull request could, in principle, also let it merge one. The industry has converged on a clear line instead: investigation can run fully autonomously, but any action that changes production requires a human to approve it first. That boundary is not a matter of taste.

Hallucinated agent actions, where a model invents a tool call or calls the right function with the wrong arguments, are the least common failure mode in these systems but the most dangerous one, because downstream systems go on to execute actions no one actually intended. An agent with a direct path to production and no human gate in front of it has no limit on how far a single bad decision can spread. That convergence on keeping investigation autonomous while gating remediation isn't a philosophical stance adopted out of caution for its own sake. It responds to confirmed incidents where autonomous systems caused real harm in production environments, and that history is why the boundary holds across the industry.

Mapped onto the pipeline described above, the line falls in a specific place. Ingestion, enrichment, generation, self-correction, branch creation, PR opening, and reviewer routing are all appropriate work for full automation, and the stages covered here show why each one can be trusted to run without a person watching every step. The merge itself, and any action that touches production, stays with a human.