Last Tuesday, one of my engineers pushed a migration that would have silently dropped a column in staging. The PR had 14 files changed and a vague description. Normally, that’s the kind of thing I catch during my afternoon review block — if I’m not in back-to-back meetings.

This time, an agent caught it within 90 seconds of the push. Not because I asked it to. Because Cursor’s new Automations system triggered a review agent automatically when the PR was created.

That’s the pitch: agents that run without you prompting them. After a week of living with it, the reality is more nuanced than the pitch — but the nuance is interesting.

What Cursor Automations Actually Is

Launched March 5, Automations is Cursor’s answer to a problem every team using agentic coding now faces: you’re managing more agents than you can track.

The system lets you define triggers that automatically launch agents:

  • Code changes — a PR is opened, a branch is pushed, files in a specific directory change
  • Slack messages — someone posts in an incident channel, a deploy notification fires
  • Timers — weekly codebase summaries, daily dependency checks
  • Incident tools — PagerDuty alerts kick off agents that query server logs via MCP

The key shift: instead of the human always initiating (“hey agent, review this PR”), the agent initiates and the human reviews the agent’s output. As Cursor’s engineering lead put it: “Humans aren’t always initiating. They’re called in at the right points in this conveyor belt.”

Cursor says they’re running hundreds of automations per hour internally. Their revenue just hit $2 billion ARR — double from three months ago — so clearly something is working.

What Worked Surprisingly Well

Automated PR Reviews (The Obvious Win)

This is the evolution of Cursor’s existing Bugbot feature, and it’s the most immediately useful automation. Every PR now gets a first-pass review before any human looks at it.

The quality gap between this and standalone PR review bots I’ve tested is noticeable. Because the agent has full access to your codebase context within Cursor, it catches things that context-free tools miss — like “this function signature changed, but the three call sites in other modules weren’t updated.”

In one week, it caught:

  • The staging migration issue I mentioned (genuinely saved us hours of debugging)
  • A race condition in a queue consumer that I’m not sure I would have caught in a normal review
  • Two instances of hardcoded API keys that should have been env vars

It also flagged roughly 15-20 things per day that were style nitpicks or false positives. That’s the tradeoff — you save time on real bugs but spend some time dismissing noise.

Incident Response Triage

We connected a PagerDuty automation that triggers when alerts fire. The agent immediately queries relevant logs through MCP, checks recent deployments, and posts a preliminary analysis to the incident Slack channel.

It doesn’t fix things automatically — and I wouldn’t want it to. But having a “here’s what probably happened” summary waiting in the channel when an engineer picks up the page at 3am? That’s worth the setup time alone.

Weekly Codebase Summaries

A timer-based automation generates a weekly summary of all changes across the repo and posts it to our team Slack. It highlights new dependencies added, API surface changes, and test coverage deltas. My engineers actually read this, which is more than I can say for most status reports.

What Didn’t Work (Yet)

The Noise Problem Is Real

The biggest issue with always-on agents: they’re always on. Every PR gets reviewed, even the one-line README typo fix. Every Slack message in the trigger channel gets processed, even the “👍” emoji reactions.

After three days, I had to add exclusion rules: skip PRs with fewer than 5 lines changed, ignore Slack threads (only top-level messages), skip draft PRs. That got the noise down to manageable levels, but the out-of-box experience is overwhelming for active repos.

Cost Scales Linearly (And It Adds Up)

Each automation run burns tokens. For a team with 6 engineers pushing an average of 4-5 PRs per day, plus incident triggers, plus the weekly summary — we were burning through roughly $180-220/week in additional Cursor usage beyond normal subscriptions.

That’s not outrageous for the value, but it’s not free either. And unlike a self-hosted solution, you can’t optimize the underlying model costs. You’re paying Cursor’s margins on top of the model costs.

Configuration Is Still Too Manual

Setting up automations requires editing YAML-like configuration files within Cursor. There’s no visual editor, no template library, no “here are the 5 automations every team should start with.” If you’re comfortable writing CI/CD pipelines, you’ll be fine. If not, the learning curve is steeper than it needs to be.

For a product making $2B/year, I’d expect better onboarding here. A setup wizard that asks “Do you want automatic PR reviews? Incident response? Codebase summaries?” and generates the configs would cut adoption time in half.

Cursor Automations vs DIY Agent Orchestration

The question every engineer will ask: why not just set up GitHub Actions + Claude API + some glue code?

You absolutely can. I’ve built similar workflows with Claude Code and cron jobs. The difference:

Cursor Automations wins on:

  • Full IDE context (the agent sees your project the way you see it in the editor)
  • Built-in integrations (Slack, PagerDuty, GitHub — no custom webhook code)
  • Agent management UI (you can see all running agents, their output, their status)

DIY wins on:

  • Cost transparency (you pick the model, you see the token usage directly)
  • Flexibility (you can chain any tool, any model, any trigger)
  • No vendor lock-in (your automation survives if Cursor changes pricing or features)

For teams already embedded in Cursor, Automations is the obvious choice. For teams using mixed tooling (Cursor + Claude Code + Copilot), DIY orchestration gives you more control.

What This Means for Engineering Managers

The shift from “human initiates agent” to “agent initiates, human reviews” is bigger than it sounds. It changes the daily rhythm of managing a team.

Before Automations, my morning started with: check PRs, check Slack, triage what needs attention. Now it starts with: check what the agents already flagged, verify their findings, handle the exceptions.

The engineers who resisted AI code review (“it just produces noise”) are warming up to it because they’re not the ones managing the agent. It runs in the background, and they only see the output if it found something worth flagging. That’s a meaningful UX improvement over the old model of “paste your code into a chat window.”

The risk? Over-reliance. If your team starts assuming the agent catches everything, human review quality drops. I’ve already seen one engineer approve a PR with “agent said it’s fine” as the only review comment. We had a conversation about that.

The Bottom Line

Cursor Automations is the best implementation of always-on coding agents I’ve used. The codebase-aware PR reviews alone justify the setup time for most teams. Incident triage is a genuine 3am quality-of-life improvement.

But it’s v1 of a new paradigm. The noise problem needs better defaults. The pricing needs transparency. The configuration needs a friendlier interface. And the organizational question of “how do we prevent agents from replacing human judgment instead of augmenting it” doesn’t have a technical answer.

If you’re running a team on Cursor, try Automations for PR reviews this week. Start with one trigger, tune the exclusion rules, and expand from there. Don’t try to automate everything on day one — that’s how you end up with 200 agent notifications and zero signal.

For more on how AI is reshaping the code review workflow specifically, see my detailed breakdown of AI-assisted code review.