Cursor cloud agents and automations: what to automate first

Last checked: 21 Oct 2026. The facts below come from Cursor's own documentation on cloud agents, automations, environment setup and security and network settings, its pricing pages, release notes and Marketplace templates, and one published benchmark from LinearB, each linked where it is used.

Start with a job that is narrow, happens often, already has a number attached to it and can be judged within a few weeks. Let the first version report its findings to a person instead of changing code, and add write access, approvals and broader triggers only once you have seen what it produces. Many of Cursor's own templates start the same way.

How cloud agents and automations relate

A cloud agent is Cursor's coding agent running somewhere other than the developer's laptop. Cursor's documentation says cloud agents "run in isolated VMs in the cloud with full development environments instead of on your local machine", and that they were formerly called Background Agents, which is the name older guides use. Each agent can build, test and run the software it has changed, and hands back screenshots, videos and logs showing how it checked its work.

When a cloud agent has finished, Cursor's security overview says it "pushes its branch and opens a draft pull request for a human to review before anything merges". Cursor says many can run in parallel without your machine staying online.

An automation is a cloud agent with a trigger. In Cursor's words, automations "run cloud agents in the background, either on a schedule or in response to events" from source control, Slack, webhooks, Linear and other services. Cursor launched them on 5 Mar 2026. Each has a trigger, a prompt, optional tools and a repository setting, and can be built in the Agents Window, at cursor.com/automations, with the /automate skill or from a Marketplace template.

Ways to start a cloud agent by hand

As at 21 Oct 2026, Cursor's overview lists Cursor Desktop, Cursor Web, Cursor for iOS, an @cursor mention in Slack or Linear, an @cursor comment on a GitHub pull request or issue or a Bitbucket pull request, and the API. The CLI can hand a conversation to a cloud agent if you prefix a message with &. The Cursor SDK and Cloud Agents API are in public beta. Microsoft Teams users can mention @Cursor with a prompt, and on Teams and Enterprise plans a Jira work item can be assigned to Cursor "when the ticket already describes the task clearly".

Before anyone can start a cloud agent from a repository, an admin has to connect source control (GitHub, GitLab, Bitbucket Cloud or Azure DevOps), and Cursor asks each person to set a spend limit the first time.

What can trigger an automation

The automations reference lists the following as at 21 Oct 2026. The list grew several times during 2026, so check it before you design around a gap.

An automation can have more than one trigger and runs when any of them fires. Cursor's release notes for the week of 5 Oct 2026 describe automations that listen to a Microsoft Teams channel, but the trigger reference does not list Teams, so check the automation editor if you need it. Jira hands individual tickets to agents and is not listed as a trigger.

Two settings decide how much an automation can do. The repository setting can be none, one or several. With none, the agent "does not clone code" and cannot edit code or open pull requests. That is the default for Slack and schedule triggers, while source control triggers need a repository. The tools list covers opening pull requests (on by default), commenting, requesting reviewers, Slack, MCP servers, memories and computer use. With approvals enabled, the agent can also approve, request changes and dismiss reviews.

Choosing your first automation

The Cursor pages we read for this post give advice on writing prompts and offer templates, but no method for choosing or measuring a first automation. What follows is our own approach. We use Cursor in our own engineering, and this is how we scope automation work generally. Our guide to where to start with AI agents applies the same thinking outside engineering. We score each candidate on five questions:

1. Scope. Does it touch one repository and produce one kind of output?
2. Volume. Will you have dozens of runs to judge within a few weeks?
3. Baseline. Do you already know today's number, such as how long failed builds sit before someone looks?
4. Speed to prove. Can a reviewer tell in minutes whether a run was useful?
5. Cost of a bad run. If the agent is wrong, does someone read a poor summary, or does bad code reach a branch people trust?

The fifth question is why we start with report-only runs. Cursor's own template prompts lean the same way. The failed GitHub Actions template says "Default to triage only". The critical bugs template says "When in doubt, report your findings in Slack without opening a PR". Cursor's prompt advice asks writers to "Set a quality bar for when the agent should open a pull request, comment, or do nothing". Write that bar before the first run.

The Cursor Marketplace listed 27 automation templates on 21 Oct 2026. These four make reasonable first candidates to test against the five questions:

Which one suits you depends on where your volume and existing numbers are. Bugbot, Cursor's managed review agent, sits beside these on the Automations page and has its own calibration questions, covered in our post on AI code review with Cursor Bugbot.

Set up the environment before the automation

Cursor's setup guide says "Environment setup is the most important step to improve the effectiveness of your cloud agents", because an agent that cannot run tests, query services or reach APIs "cannot close the loop on its work". Every automation inherits that environment.

Cloud agents run on isolated Ubuntu machines. You can configure the environment with agent-led setup, a saved snapshot or a Dockerfile in .cursor/environment.json. Cursor says agent-led setup takes less than ten minutes. The parts that matter:

• install runs when Cursor creates a Build, so dependencies are ready before an agent starts. It must be idempotent, and long-running processes do not belong in it.
• start runs after an agent boots from a Build, followed by any terminals, which run app processes in a tmux session shared by you and the agent. Builds preserve disk state only, so services have to start here.
• Builds mean agents start from a ready environment. A failed Build does not replace the working one, and Cursor's Builds page says they cost nothing extra.
• Which configuration wins. Cursor takes the first match of a personal saved environment, a team saved environment, then .cursor/environment.json (single-repository runs only). A dashboard-created environment ignores the file unless pointed at it.
• Secrets are injected as environment variables when an agent starts, so running agents do not pick up new ones. Runtime secrets are hidden from the agent but still visible to anyone using the agent's terminal, and Cursor recommends short-lived OIDC tokens over long-lived keys.
• Machine size. The default VM has limited memory and CPU. As at 21 Oct 2026, only Enterprise customers can ask support for more.

Cursor recommends a section in AGENTS.md headed something like "Cursor Cloud specific instructions", and its best practices page makes a point we agree with: "If it is hard for a human developer to test locally, it will also be hard for an agent." Cursor also offers hourly read-only templates for investigating setup failures, so expect environments to need upkeep. If your repositories are not ready for this, the groundwork is in our guide to rolling out Cursor to an engineering team.

How to tell whether it is working

Take the baseline before you switch the automation on. Afterwards, measure the thing the automation was meant to change: time to first triage, the share of its comments engineers accept, or the share of its pull requests that merge. Run counts tell you it is busy, and say nothing about whether it helps. Our post on measuring whether AI is actually working covers the general method.

Cursor gives you some raw material. The built-in Cursor Cloud MCP can list runs filtered by source, status, date, code changes and pull request creation, along with transcripts and setup logs. Bugbot reports an acceptance rate for its findings. None of that tells you whether the work saved anyone time, which is your baseline's job.

Merge rate by origin is worth tracking once an automation opens pull requests. LinearB's 2026 benchmark of 2.7 million pull requests (February to May 2026) reports that among its top 10% of organisations, 79% of agent-opened pull requests merged within 30 days against 92% for human-only ones. LinearB sells engineering metrics software, calls the figures correlational, does not say how agent-opened pull requests were identified and is not measuring Cursor specifically. Its explanation is that pull requests nobody owns tend to sit unmerged. We take one practical point from it: give every automation's output a named owner.

What to hold back at first

Each of these can be switched on later, once the report-only version has earned it. For the full security picture, see our post on Cursor cloud agent security.

• Approvals. With approvals enabled an automation can approve pull requests. Cursor's managed PR Routing & Approval agent says plainly that "It does not replace a full code review", and Cursor's release notes for the week of 5 Oct 2026 record a fix so that an incomplete security review no longer auto-approves. Cursor's reviewer-assignment template, which can approve, tells the agent to treat pull request content as adversarial and never approve high-risk changes. Let branch protection in your source control decide what can merge.
• Pull request creation. It is on by default. Turn it off for a report-only first version.
• Memories on untrusted input. Memories are on by default and persist across runs. Cursor warns that inputs "may lead to misleading or malicious memories" that affect later runs, so switch them off where an automation reads input from outside the team.
• Broad MCP servers. Connecting one gives the agent every tool that server exposes, though the environment configuration can allowlist servers and tools.
• Wide Slack triggers on code-changing automations. Slack triggers see public channels, so anyone who can post there can start a run.
• Open network access. Cloud agents have internet access by default and auto-run terminal commands, and Cursor names the resulting prompt injection and data exfiltration risk. Allowlists are available, and locking them is Enterprise only.

Decide early who owns the automation's identity. An automation runs as its creator or, if a team admin chooses, as a service account, which stops working if the account is archived or deleted. GitHub comments, approvals and reviewer requests appear as cursor and Slack messages come from the Cursor bot, so keep your own record of which automation did what. Team admins can view and disable even private automations.

Who pays, and which plans include it

The identity choice also decides the bill. Running as yourself bills you, and running as a service account bills the team's usage pool. Cursor's cloud agent page says cloud agents are charged at API pricing for the selected model, and its models and pricing page says each paid plan has a weekly usage pool for Cursor models shared across the editor, CLI and Cloud Agents. The pages do not reconcile the two or publish a per-run cost, so watch real usage in the first weeks. When a team limit is reached, paid additional usage pauses until next month or until an admin raises it. Our post on Cursor spend controls and model choice covers capping it.

As at 21 Oct 2026, Plus excludes cloud agents and automations, Premium adds them, and Teams and Enterprise include them. Legacy Pro, Pro+ and Ultra plans include them too. Cursor is now sold directly by the vendor as part of The X Subscription, and its pricing page shows prices excluding VAT. Our guide to SpaceX Super Intelligence (SpaceXSI) for UK business explains how Cursor, Grok and Grok Bot fit together, including Cursor's acquisition by SpaceX on 14 Aug 2026 and the contract changes that followed.

Common questions

What is the difference between a Cursor cloud agent and a Cursor automation?

A cloud agent is Cursor's coding agent running in its own isolated virtual machine instead of on a developer's laptop, started by a person from the app, Slack, a pull request comment, the API or another route. An automation starts cloud agents for you, on a schedule or when an event happens in source control, Slack, a webhook, Linear, Sentry or PagerDuty.

What should a team automate first with Cursor?

Cursor's documentation offers templates and prompt advice but no method for choosing. Our view is to pick a job that touches one repository, fires often, already has a measured baseline and can be judged quickly, and to start it as report-only. A daily change digest, triage of failed GitHub Actions runs, or investigation of Sentry issues are reasonable candidates, and Cursor's own templates for these default to reporting before changing code.

Who can trigger a Cursor automation, and who pays for it?

Anyone who can cause the trigger event can start a run, so with a Slack trigger that means anyone who can post in the connected public channel. An automation runs either as its creator, who is billed, or as a service account chosen by a team admin, which bills the team's usage pool. Automations are billed based on cloud agent usage, and Cursor's pricing pages describe the current model.

Do Cursor cloud agents store our code?

Yes, while they run. Cursor says code runs in isolated VMs in its AWS infrastructure and is stored on VM disks while the agent is accessible. Cloud agents need Privacy Mode, and with it enabled Cursor says customer data will not be used for training by Cursor. Conversation history is kept indefinitely by default. As at 21 Oct 2026, Cursor offers US-only data residency to Enterprise customers and EU and UK inference-only coverage on request, with no UK storage region stated.

If you want help choosing and setting up your first automation, including the environment it depends on, see our SpaceXSI and Cursor implementation service and Request a Quote.

John Kelleher holds the SpaceX Super Intelligence Partner Network Accreditation: Forward Deployed Engineer.