Coding agents already open the pull request. The part I still do by hand is the watching after the deploy: the dashboard, the alert, the issue someone has to own. Sentry’s answer, in a post by Peter McCarron dated September 29, 2026, is to let Seer Agent write those things inside the project, not only talk about them. Until this update, McCarron writes, “Seer Agent was primarily a tool for gathering information.”
The same page places the change five months after the launch. “Today marks exactly five months since we launched” Seer Agent, “our friendly AI agent for querying all things in your Sentry projects” (the aside is “five months and a day ago, but close enough”). The page’s datePublished attribute is 2026-09-29T07:00, with no timezone on it. The visible byline is September 29, 2026. Sentry’s changelog for that day is titled “Seer Agent now manages more of Sentry for you and connects to external telemetry”, and it opens with a plainer sentence: “Seer Agent can now write to Sentry through the Sentry API instead of just reading from it.”
What it can change inside Sentry
The announcement is specific about the mechanism. “Seer Agent has the ability to directly interact with the Sentry API to perform write actions on your behalf.” The examples on the post, and the same four lines on the changelog, are:
- Set up custom dashboards and widgets
- Create monitors and alerts
- Assign, resolve, and archive issues
- Save explore queries and issue views
That is the list they published, not a claim that it can change anything in Sentry. McCarron notes you could already “trigger a Seer Autofix from Seer Agent alerts”. I am not writing about Autofix. The new claim is the agent changing the project: dashboards, monitors, triage, and saved views.
The permission ends with the chat
A debugging agent with a write token is a different product from a chatbot. This is the paragraph I would put in a review:
Those permissions also don’t persist beyond a single chat, so you don’t have to worry about giving Seer Agent standing access to your Sentry organization.
The sentence before it, on the same page, sets the default. “We’ve made sure to default Seer Agent to the same level of permissions you have as a user, and Seer Agent will explicitly ask for permission before executing a task if it doesn’t detect the proper write scope.” The changelog says the same gate in shorter words. “Seer Agent uses the same permissions you already have, and it’ll ask before doing anything it doesn’t have the write scope for. None of that access carries over between chats.”
That is their design, not an audit I ran. The agent does not get a standing key. It borrows the permissions you already have, for that chat, and it is supposed to ask when the write scope is missing. If a later chat can still resolve issues without asking, the promise on this page is already wrong.
Data from outside the project
The second half is read, not write. “Starting with Datadog and Google Cloud Platform, you can now connect external monitoring platforms directly to Seer Agent via the new Seer Connectors screen.” The reason they give is that a diagnosis often sits outside the application. “Is there a network problem? Are you hitting a bottleneck with your database? Have you exhausted your hosting resources? Sentry doesn’t capture that type of data — it wasn’t built to.”
The announcement and the changelog both say these connections are not OAuth. McCarron: “OAuth isn’t currently supported, so you’ll need an API key instead.” The changelog: “these connections run on API keys, not OAuth, so set them up with a key that already has access to the environments you need.”
The docs do not tell one setup story, so I am not merging them. The Datadog for Seer page says the integration “gives Seer Agent access to Datadog data like metrics, spans, traces, logs, notebooks, monitors, dashboards, and more.” Install needs a line I am quoting as theirs: “Sentry Owner, Manager, or Admin permissions are required to install this integration.” The application key has to be scoped, or, in their words, “If you do not assign scope to the application key, Seer will not have permission to read your data.”
The Google Cloud page is a different instruction. “The Google Cloud Platform for Seer integration gives Seer Agent access to Cloud Logging, Cloud Monitoring, and Cloud Trace data.” Then: “Sentry authenticates by impersonating that account. You do not need to create or upload a service account key.” And “The connection is shared across your Sentry organization.” So the blog’s API-key sentence and the Google Cloud doc, which says you do not upload a service account key, are both on Sentry’s sites, and they are not the same step. I would follow the doc for the platform I am connecting. I would not quote the blog’s key line as if it covered Google Cloud’s impersonation flow.
Both connector docs call the feature a beta. The blog says “Seer Agent is currently in beta and free for all users.” The changelog repeats “Seer Agent is in beta and free for all users”. Free, here, is Sentry’s word for the beta. I am not turning that into a price.
The prompts they suggest
McCarron offers three ways to talk to it. The one I would not paste first is this. “Hey Seer, take a look at my Sentry project and help me organize the issues by severity. Update the priority and assign those issues to the most relevant engineers.” Assigning work to people is a write with a name on it. The other two are closer to what I would try. “Hey Seer, build me a dashboard that gives me a consolidated view across all my Sentry projects.” And “Hey Seer, look at all my API routes and create metric monitors for the ones that are most heavily trafficked.”
You can open Seer in the Sentry UI “or by enabling the Slack integration”. The post gives no customer list, no chat count, and no accuracy figure. They call the older Seer “a rubber duck for debugging” and the new one “your full-time debugging assistant”. I would keep the first description until the permission above holds on a project I already use.
What I would actually try
If a coding agent is already landing the change, the next question is who sets the watch on it. Seer’s answer is a debugging agent that can create the dashboard and the monitor, triage issues, and read Datadog or Google Cloud while it explains a finding. I trust the short permission on the page: same scope as me, a question when the scope is missing, and nothing that survives the chat. I would not paste the prompt that assigns issues to engineers.
I would point it at one project, ask for the dashboard, and read what it created before I let it resolve anything. If the next chat still has yesterday’s write scope, the page I am citing is wrong.
