Sentry Alerts as Agent Work Orders
maps Sentry alert events into joelclaw-style agent loops with triage, isolated worktrees, verification, and human wake-up
A Sentry crash alert is usually the start of a tiny human interruption. This Gremlin issue turns it into a work order: Sentry posts to Slack, Moltbot triages it, Codex CLI gets an isolated git worktree, and GitHub gets a pull request against staging.
The clever part is the boundary. Null refs, type mismatches, missing imports, and obvious UI edge cases can go through the machine. Architecture, auth, payments, Stripe, PII, database migrations, and unclear business logic get kicked to a human. That’s the right kind of autonomy: useful, scoped, and not pretending the agent should touch the scary shit.
The multi-app piece matters. Gremlin is a foundation for multiple course apps, so the pipeline has to identify the app, pick the right repo, choose the staging branch, run the correct tests, and include the app name in the wake notification through Telegram or Signal. That’s not just “fix my bug, robot.” It’s incident routing with receipts.
For joelclaw, this maps cleanly to agent loops: event comes in, triage decides the lane, a worker runs in isolation, verification gates the handoff, and a human only gets pinged when there’s something reviewable.
Key Ideas
- A Sentry alert can become structured agent input instead of another notification humans have to babysit.
- Slack works as the event router, either through one shared
#sentry-alertschannel or app-specific channels. - Explicit triage rules separate safe auto-fixes from security, payments, database, and business-logic changes that need human review.
- Isolated git worktrees keep Codex CLI changes contained and easy to inspect.
- An app registry makes multi-app routing explicit: repo, Sentry project, staging branch, and owner all live in one table.
- The wake notification closes the loop by telling the human which app was fixed and where the GitHub PR is.