Sentry throws 200 errors at my team every day. Most of them are noise. The ones that matter arrive at 3am and nobody sees them until a customer complains. I built an agent that triages them instead. It reads new Sentry issues, groups them by fingerprint, applies filtering rules, and only sends me the ones that actually need attention. Here is how it works, the day it failed, and what I learned about building alerting systems that agents actually maintain. The Problem Our Sentry project tracks errors across the Nebula backend, web frontend, and CLI. In any given week we get 500+ issues. Maybe 20 of them are new bugs that need fixing. The rest are transient failures, known patterns, and false alarms. The old workflow: check Sentry when someone pings Slack about an error. Spend 15 minutes figuring out if it is new or already tracked. If new, create a GitHub issue. If old, close it as duplicate. Repeat. This is exactly the kind of mechanical work an agent should do.…