Until now, every AI coding tool shared the same basic premise: you sit at your keyboard, you invoke the AI, you review what it produces. Even the most autonomous agents — Claude Code in auto mode, Devin, GitHub Copilot coding agent — still require a human to start the job.
Cursor just broke that model.
With Cursor Automations, announced March 5, 2026, you no longer need to be at your keyboard for work to get done. Automations are always-on agents that wake up in response to external events — a Slack message, a new Linear issue, a merged pull request, a PagerDuty alert — and execute coding tasks end-to-end, autonomously, in cloud sandboxes.
This is a different category of tool. It’s not an assistant you invoke. It’s infrastructure.
What Cursor Automations Actually Does#
The mental model is simple: pick a trigger, write instructions, point the agent at your codebase.
Supported triggers include:
- Slack messages (channel-specific or DM-based)
- Linear issue creation
- GitHub PR opens/pushes
- PagerDuty incidents
- Custom webhooks
- Cron schedules
When a trigger fires, Cursor spins up a cloud sandbox, executes your instructions using whatever MCP connections and models you’ve configured, verifies its own output, and completes the task — all without you touching a keyboard. A built-in memory tool lets each agent learn from past runs, building up patterns over time.
The result is a system that behaves less like a coding assistant and more like a background engineering team.
Four Use Cases That Show the Potential#
Cursor’s announcement highlighted several templates that illustrate the range of what’s possible.
PR risk classification. Every time a pull request opens or receives a new push, an automation classifies it: blast radius, complexity, likely reviewers based on contribution history. Low-risk PRs can be auto-approved; higher-risk PRs get specific reviewers assigned. Decisions are logged to Notion and posted to Slack. A task that typically requires a senior engineer’s judgment, running automatically in seconds.
Incident response. A PagerDuty alert triggers the automation. It pulls in Datadog logs via MCP, cross-references recent commits in the codebase, summarizes its findings in Slack to the on-call engineer, and opens a draft PR with a proposed fix. Before anyone has acknowledged the page, the diagnostic work is already done.
Bug triage. A Slack message in your #bugs channel triggers an agent. It searches for duplicate issues, creates a Linear ticket, investigates root cause from the codebase, and replies in-thread with what it found. Your bug inbox starts processing itself.
Engineering dashboard. A cron job runs every two hours, reads your meeting notes, open GitHub PRs, Jira issues, and Slack mentions, deduplicates across sources, and posts a clean priority dashboard. No more context-switching to piece together your day.
These aren’t toy examples. They’re the kinds of coordination work that eat hours of senior engineering time every week.
The Architecture Behind It#
Each automation runs in an isolated cloud sandbox, so there’s no risk of one automation corrupting another or bleeding into your local environment. The agent uses the MCP connections you’ve configured — Datadog, Notion, Linear, GitHub — just like you would in an interactive session, but without you present.
The memory tool is notable. Automations can store observations from past runs: “this type of commit usually causes flaky tests in the auth module,” or “PRs touching the payments directory need the payments team pinged.” Over time, automations become more accurate as they accumulate context that a stateless agent would have to rediscover from scratch every time.
This is the difference between a tool that executes instructions and a system that learns from its environment.
The Honest Limitations#
Cursor Automations is powerful, but it’s early.
IDE lock-in. Automations only run through Cursor’s standalone IDE. If your team is split across VS Code, JetBrains, and Cursor, you can’t roll this out uniformly. Teams would need to fully migrate to Cursor — a non-trivial ask for organizations with established tooling.
Enterprise maturity. Audit logs, role-based access controls, and compliance documentation are still maturing. For teams in regulated industries or with strict security requirements, the current state may not be enterprise-ready.
No published pricing. Cursor hasn’t disclosed what Automations costs beyond base Cursor pricing. For teams that want to run dozens or hundreds of automations per day, the economics aren’t yet clear.
Templates, not turnkey. Cursor has published templates on cursor.com/marketplace, but building automations still requires understanding your own codebase structure, MCP connections, and what instructions the agent needs to succeed. There’s real configuration work involved.
The Elephant in the Room: Claude Code Already Does This#
Before you migrate your entire team to Cursor for Automations, it’s worth naming what’s missing from the narrative: Anthropic got here first.
Claude Code has operated as an autonomous, event-driven agent since its launch — available via API, scriptable, triggerable from CI pipelines, webhooks, and cron jobs without requiring anyone to have Cursor installed. The tool that Cursor is now building around IDE lock-in has been infrastructure-first from day one.
The deeper issue is philosophical. Cursor Automations require Cursor. Your team’s trigger-driven workflows are now tethered to a specific IDE with opaque pricing, a history of base-model transparency failures, and an enterprise maturity story that’s still being written. Claude Code, by contrast, runs anywhere a terminal runs — your laptop, CI, a Lambda function, a GitHub Action. No IDE required. No lock-in.
Cursor’s event-driven layer is genuinely useful. But it’s a feature bolted onto an IDE. Claude Code is an agent with IDE integration bolted on top, if you want it. That architectural difference matters enormously when you’re designing systems that need to outlast whatever tool is fashionable in 12 months.
Why This Matters for How We Think About AI Coding Tools#
The evolution of AI coding tools has followed a clear progression:
- Autocomplete (Copilot 2021): AI suggests the next line
- Chat (2023): AI answers questions about your code
- Agent (2024-2025): AI executes multi-step tasks you assign
- Autonomous (2026): AI reacts to events without being asked
Cursor Automations is the first major IDE to reach that fourth stage at scale. Devin 2.0 made similar claims about autonomous operation, but it’s a standalone tool rather than infrastructure woven into a development environment.
The frame shift matters. When AI acts only when invoked, engineers stay in control and AI is an accelerator. When AI reacts to events autonomously, engineers become the reviewers of work they didn’t initiate — a fundamentally different relationship that requires different trust, different oversight, and different processes.
The PR risk classification example is revealing: an automation that auto-approves low-risk PRs is making a judgment call that historically required a human. That’s not just automation; it’s delegation of authority.
Where This Is Heading#
Cursor Composer 2, also launched in March, already handles long-horizon tasks better than any prior model — it uses self-summarization to compress context mid-task, enabling multi-hour refactors across hundreds of sequential steps. Pair that capability with event-driven triggers and persistent memory, and you start to see the outline of something more interesting: a background engineering team that never sleeps, escalates to humans only when genuinely uncertain, and improves with every task it completes.
That future isn’t fully here yet. But Cursor Automations is the clearest signal yet that it’s coming — and faster than most teams are prepared for.
Sources:
- Cursor Automations — Official announcement
- Cursor Automations: The Always-On AI Agents Changing How Engineers Build Software
- Cursor Launches Automations for Always-On Coding Agents — Tessl
- Cursor Automations Turns Code Review and Ops into Background Tasks — Help Net Security
June 2026 Update: The Company Behind the Automations Has Changed Hands#
Three months after this article was published, the landscape around Cursor Automations has shifted substantially — not in the technology, but in who owns it and what the product has become.
Cursor is now a SpaceX subsidiary. Cursor IPO’d on Nasdaq in June 2026 at a $75B valuation — a record for a developer tools company. Four days later, SpaceX closed a definitive $60B all-stock acquisition. Public shareholders became SpaceX equity holders. The startup that shipped Cursor Automations in March is now an Elon Musk vehicle operating inside a $2.94T aerospace and infrastructure conglomerate.
Whether this accelerates Cursor’s roadmap or complicates it with enterprise trust questions is not yet clear. What is clear: teams building production event-driven workflows on Cursor Automations now have vendor concentration in an IDE that is an asset of SpaceX. That’s a different risk profile than “promising startup.”
Cursor 3.5 promoted Automations to first-class status. Cursor 3.5 (May 2026) moved Automations out of a separate experience and into the main Agents Window — the same panel where interactive and background sessions live. Automations are now a tab alongside manual tasks, not a separate product. The release also added multi-repo support and no-repo templates: pre-built blueprints for Slack digest automation, analytics summaries, FAQ maintenance, finance reports, and customer health monitoring. The setup overhead flagged in this article’s “Honest Limitations” section has been meaningfully reduced.
The Cursor SDK opened programmatic access. Cursor released a public TypeScript SDK in April 2026 enabling programmatic invocation of agents from CI/CD pipelines and other systems — somewhat narrowing the “IDE lock-in” structural gap. The SDK creates cloud sandboxes and manages agent lifecycle. It’s a meaningful step. Cursor agents can now be triggered from outside Cursor, just as Claude Code has operated from the start.
The comparison to Claude Code has sharpened in Claude’s favor. When this article ran, Claude Code Routines were in research preview. They went GA in April 2026. Scheduled runs, API triggers, and GitHub event triggers — everything Cursor Automations does — running on Anthropic’s infrastructure, accessible via any terminal, with no IDE required. Claude Code’s architecture always treated automation as infrastructure; Cursor’s architecture still wraps automation in an IDE layer, even after the Agents Window integration.
The bottom line on Cursor Automations in June 2026: it’s a better product than it was in March, with a more capable feature set and lower setup friction. The fundamental architectural critique remains: the workflows you build on Cursor Automations require Cursor — which is now also SpaceX. If that dependency chain is acceptable for your team, Cursor 3.5’s Automations are genuinely useful. If it isn’t, Claude Code Routines do the same job on infrastructure that hasn’t been acquired by anyone.
Updated June 28, 2026. Original article published March 26, 2026.