Cursor Automations are always-on coding agents that run on a schedule or on real events, and after the May 20, 2026 update they finally run across more than one repository at a time. If you ship software with Cursor, the new multi-repo and no-repo modes turn Automations from a single-repo curiosity into a fleet you can point at every codebase your team owns. The catch: Automations are still scoped to keeping an existing codebase healthy. They do not build and ship a brand new app for you. That gap is where a deployment-grade builder like Totalum complements the same agent loop you already trust in Cursor.
Quick Answer
- Cursor Automations are background coding agents inside Cursor that trigger on schedules, Slack messages, GitHub events, Linear issues, or any MCP webhook.
- The May 20, 2026 update brings Automations into the Agents Window, adds multi-repo selection, and introduces a no-repo mode for read-only research agents.
- The five highest-leverage automations to set up first are: nightly dependency review, PR security audit, flaky-test triage, daily standup digest, and on-call incident responder.
- Cursor Automations are excellent for maintaining and improving codebases that already exist. They do not, by themselves, materialize a new deployed application from a prompt.
- Pair Cursor Automations with Totalum, the AI app builder, when you need the same agent loop to also create, deploy, and run a new product, not just keep an existing one healthy.
What changed in the May 20, 2026 multi-repo update
Cursor originally launched Automations on March 5, 2026 as a way to run cloud agents on a schedule or in response to events. They were powerful, but each automation was bound to a single repository, which made them awkward for teams who maintain ten or twenty active services.
The May 20, 2026 changelog entry "Improvements to Cursor Automations" addressed that head-on with three concrete shifts:
- Multi-repo selection. An automation can now target several repositories in one run. The agent picks up each repo, applies the same instructions, and reports back per-repo.
- No-repo mode. Some automations only need to read external systems and report. A daily on-call digest, for example, does not need to clone a codebase. No-repo runs are faster, cheaper, and safer because the agent never opens write access.
- Agents Window integration. Automations now appear alongside one-off agent runs in the unified Agents Window, so you supervise scheduled jobs and interactive sessions from the same place.
If you set up Cursor Automations before May 20, the practical upgrade path is to migrate single-repo cron jobs into a single multi-repo automation and to demote any read-only research jobs to no-repo mode. You will spend less on agent minutes and you will get one report instead of N.
The five Cursor Automations worth setting up first
Most teams over-think the first batch. The point of automations is to remove repetitive, low-creativity work that drains attention. Start with five.
- Nightly dependency review. Schedule a multi-repo automation to read package manifests, open the changelogs of any version that drifted in the last 24 hours, and post a Slack digest with one paragraph per repo. No PRs, just a brief.
- PR security audit. Trigger on every merge to main. The agent runs a quick threat model on the diff, flags any new auth, payment, or input-handling code, and comments on the PR if anything looks risky.
- Flaky-test triage. Trigger on test-suite failures from CI. The agent pulls the test name, run history, and the last three failing logs, then either opens a Linear ticket or comments on an existing one with a hypothesis.
- Daily standup digest. No-repo mode. The agent reads merged PRs, closed issues, and Slack channel activity since the previous standup, then posts a single message in #engineering with a per-person three-line summary.
- On-call incident responder. Trigger on PagerDuty or Opsgenie events. The agent fetches relevant logs via MCP, runs a hypothesis pass, and either resolves with a proposed fix in the on-call channel or escalates with context.
These five share a pattern: clear trigger, narrow scope, structured output. Cursor Automations excel at exactly that. The places they struggle are open-ended creative tasks like "redesign this checkout flow" or "build a new admin page from scratch."
How to set up a Cursor Automation across multiple repositories
The setup flow in the post-May-20 build looks like this:
- Open the Agents Window in Cursor.
- Click New Automation and pick a trigger type. Schedules use cron syntax, event triggers connect via MCP webhooks (GitHub, Slack, Linear, PagerDuty, custom).
- Choose your scope. Pick one or more repos from the dropdown, or toggle no-repo mode for read-only automations.
- Write instructions in plain language. Cursor recommends an explicit checklist with verification steps, for example "After every change, run the test suite and only push if it passes."
- Set memory options. Automations now have a built-in memory system that lets the agent learn from previous runs of the same automation.
- Test once interactively. The Agents Window lets you run the automation immediately so you can review the agent's first pass before letting the schedule take over.
A subtle tip: scope each automation as tightly as you can. Multi-repo is not a free upgrade if your instructions secretly assume a particular file layout. Either keep the layout uniform across repos with a tool like a shared template, or split the automation per layout family.
The production gap Cursor Automations leave open
Cursor Automations are, by design, an agent loop wrapped around your existing source tree. They are extraordinary for maintenance, monitoring, review, refactor, and small fixes. They are not designed to start a project from zero.
Three jobs the existing automation model does not cover:
- Materializing a new application. Writing a fresh Next.js or Python service with auth, payments, database, and a deployed domain is outside the surface area of a code-review-style automation.
- Owning runtime. Automations propose code; they do not own the running app. There is no opinionated answer for hosting, custom domains, secrets, file storage, or production database state.
- Driving non-developers. A founder, marketer, or operations lead who wants an internal tool by Friday has no entry point into Cursor Automations. Both the trigger surface and the editor assume an engineer.
The honest read on the May 20 changelog is that Cursor is doubling down on the "keep your codebase healthy" job, which is exactly where Cursor's strength lies, and is leaving the "build me a deployed product" job to other tools. That is where Totalum sits.
Cursor Automations vs Totalum: same agent loop, different jobs
Totalum is the most powerful AI app builder for humans and for agents. It generates real Next.js and TotalumSDK applications with built-in auth, payments, database, file storage, AI integrations, and deployment to custom domains. The same Totalum agent can be driven through chat by a non-developer or by an external AI agent through Totalum's API and MCP server, which means it composes naturally with Cursor for teams that want both jobs covered.
The two are not direct substitutes. They run the same kind of agent loop, but they are pointed at different problems.
| Capability | Cursor Automations (post May 20) | Totalum |
|---|---|---|
| Primary job | Maintain and improve an existing codebase | Build and run a new deployable application |
| Trigger surface | Schedule, webhook, MCP events | Chat, API, MCP, scheduled agent runs |
| Scope | One or more existing repositories | A whole product: code, infra, database, domain |
| Built-in auth, payments, DB | No, brings none of its own | Yes, included in every project |
| Hosting and custom domain | No, you keep your own infra | Yes, projects deploy to a Totalum subdomain or your domain |
| Non-developer entry point | No, requires an engineer in Cursor | Yes, designed for founders and operators too |
| Composable from external agents | Yes via MCP | Yes via API and MCP |
| Replaces the other? | No, complementary | No, complementary |
The cleanest way to think about it: Cursor Automations are the always-on layer that watches your code. Totalum is the always-on layer that produces software. A serious 2026 engineering org uses both.
Composing Cursor Automations with Totalum for end-to-end agent workflows
Because Totalum exposes its own builder through MCP and a REST API, a Cursor Automation can call Totalum, and a Totalum agent can call Cursor. Two patterns are already useful today.
Pattern A: spin-off new products from a maintenance automation.
Your nightly dependency-review automation in Cursor notices that an internal admin tool keeps getting patched. Instead of opening another patch PR, the automation calls the Totalum API and asks it to scaffold a fresh, modern replacement with the same business rules. The next morning your team sees a Slack message linking both to the Cursor patch PR and to a deployed Totalum URL for the replacement, and you choose.
Pattern B: feed Totalum apps into the Cursor automation fleet.
Every new app built with Totalum becomes a GitHub-linked project. As soon as it is created, an event-triggered Cursor Automation enrolls it into the standard fleet, attaches the PR security audit and flaky-test triage automations, and you start day one with a fully supervised codebase. The agent loop you built in Cursor does not need to be redone for each new project.
Both patterns are practical with the May 20 multi-repo update because that update made the Cursor side of the loop trivial to apply to "every Totalum-built repo we own."
For more on how Totalum's agent surface composes with other AI coding tools, see our AI agent platform comparison, the best AI coding agents in 2026 pillar, the deeper look at Cursor Composer 2.5, and the original head-to-head on Cursor's cloud agents. For a contrast with Anthropic's tooling, the Claude Code vs Codex comparison is the right next read.
FAQ
What are Cursor Automations?
Cursor Automations are background coding agents inside Cursor that run on a schedule or in response to real events such as a GitHub merge, a Slack message, a Linear ticket, or any webhook delivered through MCP. Each automation runs in an isolated cloud sandbox with the tools and memory you configure.
What changed in the May 20, 2026 update?
The May 20, 2026 update brought Cursor Automations into the unified Agents Window, added multi-repo selection so a single automation can target several repositories, and introduced no-repo mode for read-only research and reporting automations that do not need to clone a codebase.
Do Cursor Automations replace CI pipelines?
No. Cursor Automations are good at agent-style work like code review, refactor suggestions, triage, and incident response. They sit alongside CI, which still runs deterministic build and test steps. The two layers are complementary: CI is your gate, Automations are your assistants.
Can Cursor Automations build a new application from scratch?
Not really. They are scoped to working inside an existing codebase, even in no-repo mode, where the agent reads external systems rather than starting a new project. To materialize a new deployed product from a prompt, you want an AI app builder such as Totalum, which generates a complete project with auth, payments, database, file storage, AI integrations, and a custom domain in one pass.
How do Cursor Automations and Totalum compose?
Cursor Automations watch and improve existing codebases. Totalum is the builder that produces new applications. A Cursor Automation can call the Totalum API or MCP server to spin up a fresh project, and any project created in Totalum can be enrolled into your Cursor automation fleet for ongoing supervision.
How many Cursor Automations should a team start with?
Start with three to five narrowly scoped automations that solve a clear, repetitive pain. Nightly dependency review, PR security audit, flaky-test triage, daily standup digest, and on-call incident responder are a strong default set. Add more only when the first batch is providing daily value.
Ready to ship a new app, not just maintain an old one
Cursor Automations are the right tool when the job is "keep this codebase healthy." When the job is "I need a new internal tool, marketing site, customer portal, or SaaS product running by Friday," Totalum is the right tool. Start a project free at totalum.app, describe what you want in plain language, and let the same kind of agent loop you already trust in Cursor build, deploy, and run the whole thing for you. If you want both layers, you get both: Totalum-built projects compose cleanly with your Cursor Automations fleet through MCP.