A few months ago, Dillon Streator and I were trying to get better visibility into production errors at Copia Cash. The first thing we reached for was Zapier, with the idea of piping Sentry alerts into Discord so we'd see when something broke without living in the Sentry UI all day.

It never really worked the way we wanted. The integration was flaky enough that we stopped relying on it instead of fighting it. What we actually wanted was proper webhooks out of Sentry, which would have been a cleaner path, but that meant paying for a Sentry plan we didn't have room for at the time. We were on a budget, so we shelved that and kept thinking about what would be worth building once we could justify the cost.

The idea we didn't ship

Even while Zapier was a dead end, we kept talking about what automation could look like if alerts were reliable. The sketch looked like this:

Sentry error -> notification -> Cursor cloud agent

We liked the idea that an error could show up and an agent would start on it without us doing anything. Once we sat with it for a bit, the downsides were hard to ignore. Production throws a lot of errors, and plenty of them are low priority or duplicates. If every alert kicked off an agent we'd burn through tokens constantly and wake up to a pile of PRs that still needed a human to sort through.

We didn't need more automation. We needed a gate.

Human in the loop

The version we actually wanted was one where we decided what got worked on. GitHub issues fit that model well. You write up the work, add a label when it's ready, and the agent runs.

Dillon and I landed on this flow:

GitHub issue -> add "triage" label -> workflow kicks off Cursor cloud agent

Adding the label is the decision point. Nothing runs until one of us says it should. That also made it easy to kick off work from a phone through the GitHub app, which mattered more than I expected when Copia had a long backlog of testing, docs, features, and bug fixes all competing for time.

I also set up Tailscale between my phone and my Linux machine so I could use Terminus to prompt agents directly when I didn't want to wait on the issue workflow. Different tool, same intent.

Packaging it as a GitHub Action

We had this working inside Copia first, especially for test coverage work where the agent could grind through repetitive tasks while we focused on product decisions. Once it was stable enough, we generalized it into a GitHub Action so we could drop it into other repos without copying YAML around.

We looked at the GitHub Marketplace before publishing and didn't find anything aimed at kicking off Cursor agents from issues, so I pulled the Copia setup apart, simplified it, and put it out there:

• repo
• action

How I use it day to day

Most of the time I capture work as a GitHub issue, often with voice-to-text on my phone when I'm away from a keyboard, then clean up the description later. When the issue is clear enough that an agent can run with it, I add the triage label and let the workflow open a PR. Nothing fancy about it, just a consistent way to queue work without being tied to a laptop.

What's next

The piece we still want on the Sentry side is having Copia create a GitHub issue from an error so it shows up in the same triage flow instead of living only in an alert channel. That probably means paying for Sentry webhooks for real, which we're more willing to do now that the rest of the pipeline is in place. We still decide what runs, but the errors would land where we already do that.