Cursor Automations: Always-On Agents

What Automations Are

Cursor Automations, launched on March 5, 2026, represent a fundamental shift in how AI assists with development. Until Automations, Cursor was a reactive tool — it responded when you asked. With Automations, Cursor agents can run without you present, triggered by events in your external systems.

An Automation is a combination of a trigger and a set of instructions. When the trigger fires, Cursor spins up an isolated cloud sandbox, clones your repository, runs the agent with access to your connected MCP tools, and posts the results. Your laptop can be closed. The automation runs in the cloud on Cursor's infrastructure.

Available Trigger Types

• GitHub events — PR opened, PR merged, commit pushed, issue created, workflow failed. The most immediately useful trigger for most teams.
• Slack messages — A message in a specific channel, or a message matching a pattern. Example: a message in #bugs triggers an Agent to investigate and draft a response.
• Linear tickets — A ticket assigned to you, or a ticket with a specific label. Agent reads the ticket and drafts an implementation plan or starts the work.
• PagerDuty incidents — An incident is created or escalated. Agent reads recent commits and error logs to draft a first investigation.
• Scheduled timers — Run every day at a specific time, every hour, or on a cron schedule. Useful for daily summaries and regular maintenance tasks.
• Webhooks — A custom HTTP POST from any external system. This makes Automations composable with essentially any tool in your stack: CI/CD pipelines, monitoring systems, customer support platforms, internal admin dashboards.

Setting Up an Automation

1. Open Cursor Settings and navigate to the Automations panel.
2. Click New Automation.
3. Select the trigger type and configure it (e.g., GitHub repository + event type).
4. Write the Agent instructions — describe the task the same way you would in a normal Agent prompt, but written for autonomous execution.
5. Select which MCP tools the automation can use.
6. Enable the automation.

Practical Use Cases

• PR review on every push — When a PR is opened or updated, run BugBot-style analysis, generate a plain-English summary of the changes, and post both to the PR.
• Failing test investigation — When a CI run fails, Agent reads the test output and recent commits, identifies the likely cause, and comments on the PR with a diagnosis and suggested fix.
• Ticket-to-plan — When a Linear or GitHub issue is assigned, Agent reads the ticket and drafts a step-by-step implementation plan as a comment on the issue.
• Daily standup summary — Every morning at 8am, Agent reads the last 24 hours of commits across your team's repos and posts a brief summary to your team Slack channel.
• Release notes generation — When a PR is merged to main, Agent reads all commits since the last tag and drafts release notes.

What Automations Cannot Do

Automations run in cloud sandboxes. They have access to your repository via git and to whatever MCP servers you connected — but not to your local filesystem, locally running services, or internal systems not accessible via MCP. An Automation that needs to query your local database won't work without a publicly accessible endpoint. Design your Automations around what's reachable from the cloud.