Cursor’s new bot follows each pull request into production

Cursor’s new Rollouts bot gives every deployment it watches one of three verdicts: verified healthy, regression detected or inconclusive. Staging and production get separate verdicts. Rustam Lalkaka introduced the bot in a September 23 blog post. He joined Cursor when it bought Firetiger, and The New Stack describes Rollouts as Firetiger’s Change Monitors product rebuilt inside Cursor.

Cursor announced on August 13 that the Firetiger team was joining. That was the day before SpaceX closed its $60 billion acquisition of Cursor. Lalkaka co-founded Firetiger with Achille Roussel, and both had built and run large production systems at Cloudflare, Twitch, Segment and Twilio. When the deal was announced, Lalkaka set out the problem in a LinkedIn post: “The cost of creating changes has dropped to near zero. The cost and risk of deploying them has stayed largely the same.” His launch post puts it in more practical terms. What hasn’t sped up, he writes, is “watching the deploy, deciding whether a latency bump is real, figuring out which of eleven changes broke checkout.”

From pull request to verdict

Rollouts starts working when a pull request opens. It reads the proposed change, works out which systems it could affect, and writes a monitoring plan. The plan covers four things: what the change is supposed to do, the risks the bot sees, the signals it will watch, and any gaps in the instrumentation that would leave it blind. Developers can review and edit the plan before the code reaches production. So the expectations are written down while the author still remembers why the change was made.

After the deploy, the bot checks logs, metrics and traces against that plan. Because staging and production are judged independently, a change can pass in staging and still get flagged once the same code hits production traffic. Lalkaka says Rollouts can already catch problems confined to one endpoint or one region before they grow big enough to trip a broader alert. He also says it can tell an intended change in behaviour from a real regression.

Rollouts connects to Origin or GitHub for source control. It pulls deployment events from continuous delivery systems and reads signals from Datadog and other telemetry providers.

Cursor built the bot with a Bot Development Kit that also appears to be new. It is an early-stage framework for building and serving Cursor bots and agents, published on npm as @cursor/bdk. According to its documentation, you define agents in Markdown and TypeScript, with support for tools, skills, subagents, webhooks and scheduled runs.

What happens on a regression?

When Rollouts finds a regression, it names the change it suspects and alerts the developer responsible. What happens next depends on configuration: it either opens a revert pull request for review or hands the problem to a Cursor cloud agent to try a fix. A human still owns the consequential step. Rollouts doesn’t merge fixes or roll back deployments on its own. It can pause a progressive rollout, the kind of release that shifts traffic to a new version in stages.

Cursor lists a feature flag integration as “coming soon”. It would let Rollouts adjust how much traffic reaches a change directly. Support for release trains and deployment freezes is also in the works.

Security Reviewer, second version

A rebuilt Security Reviewer ships alongside Rollouts. It first appeared in beta in April. At launch it checked pull requests for vulnerabilities, authentication regressions, privacy and data-handling risks, auto-approved agent tools and prompt-injection attacks, and left its findings next to the relevant code. The new version reads each pull request in the context of the wider codebase. It focuses on exploitable issues such as injection flaws and broken authentication, and each finding comes with a severity rating, an attack path and a proposed fix.

“Security Review reads code the way a security engineer does,” Lalkaka writes. “Where does user input enter, where does it end up, what does it pass through on the way.”

He gives two figures. Average review time is down 21%, from 4.8 minutes to 3.8. Developer acceptance of the bot’s comments has risen from roughly 45–50% to 60–70%. Both figures are Cursor’s own. Like Rollouts, Security Reviewer can run automatically on every new pull request, so nobody has to remember to call it. Both bots are in the Automations tab for Teams and Enterprise customers.

Where Origin fits

Automated deployment checks are already on the market. Datadog’s Bits Release, in preview since June, also follows changes from pull request to production and checks telemetry for regressions. Harness has long offered deployment verification and rollback based on logs and metrics. LaunchDarkly’s Guarded Rollouts monitors feature releases and reverses them automatically when something regresses. The New Stack argues that Cursor’s edge is proximity: the coding agent, the repository, the pull request, the security checks and the production feedback all sit close together.

Origin is the piece that could tie this together. It is the Git-compatible forge Cursor opened in beta on August 17. Cursor’s cloud agents can already create branches, commit, push and open pull requests against Origin repositories, and Rollouts adds the record of what happened after the merge. Origin isn’t required, and GitHub stays supported. Maxime Prades of Cursor’s product team named Origin and Change Monitors as two parts of the same investment when the Firetiger deal was announced.

“Agents that write code should also be able to tell whether it works in production,” Prades wrote. “Today, those systems are mostly separate.”