Cursor Automations Land in the Agents Window with a 7-Day 50% Off Promo — The March 2026 Feature Moves Into Production Phase With 3.5

The in-app notification you're seeing in Cursor — "Automations are now available in the Agents Window" + "7-day 50% off agent runs for newly created automations" — corresponds to Cursor's 3.5 release on May 20, 2026. Automations themselves were officially announced March 5, 2026; this update folds them into the [Agents Window](../columns/claude-code-agent-view-parallel-orchestration-2026), adds multi-repo and no-repo modes, five new templates, and a 7-day promo.

From the official changelog on May 20:

1. Agents Window integration — manage Automations alongside interactive agents in the same workspace 2. Multi-repo support — a single Automation can span repos 3. No-repo automations — pure tool-connector / monitoring automations without a repo 4. Five new Marketplace templates — Slack digest, product analytics, FAQ, finance, customer health 5. Promo — 7-day 50% off agent runs on newly created automations

Cursor Automations are "always-on cloud agents triggered on schedule or events" (official docs). Each run executes inside a Cursor-managed cloud sandbox using your configured MCPs, model, and tools.

Original launch: March 5, 2026 (Cursor Blog, TechCrunch). The original management surface was the web dashboard at cursor.com/automate; the May 3.5 update moved the same primitives into the Agents Window so interactive and automation agents live in one place.

A common confusion to clear up explicitly:

Automations sit *above* Background Agents as the trigger layer; they aren't a separate execution path. Cursor's docs describe Automations as "cloud agents running in the background." That said, no public statement explicitly merges or renames Background Agents into Automations — the boundary is still slightly fuzzy in the official sources.

Outbound: PR creation, comments, reviewer assignment, Slack messages, MCP tool calls, persistent memory writes. Source: docs/cloud-agent/automations.

Automation runs are usage-based, drawing from your Cursor pricing tier (Pro / Pro+ / Ultra / Teams / Enterprise).

The Cursor-specific gotcha is whose pool gets charged depending on Automation scope:

Team Owned executes as a shared service account, so you need an ownership review process for departures and reorgs. Conversely, Private / Team Visible consume the creator's personal quota — letting too many unattended automations run as one person hits individual caps fast.

Changelog wording: "For the next 7 days, all agent runs for newly created automations are 50% off."

- Window: 7 days from the announcement (≈ May 20–27, 2026; exact end-of-day not stated) - Eligibility: agent runs of newly created automations. Existing automation runs and manual interactive agent runs read as out of scope - Plan differences (Pro / Pro+ / Ultra / Teams / Enterprise) aren't documented — verify on your invoice

- Security review on main-branch push — second layer on top of Snyk / `npm audit` - Agentic codeowners — automatic evaluation and approval for specific file patterns - Incident first-response — Sentry / PagerDuty triggers that summarize related diffs and stack traces, posted to Slack - Weekly merge digests — Friday auto-summary of repo activity → Slack - Test-coverage backfill — periodic runs that open PRs adding tests for low-coverage files - Linear bug triage — auto-classify and label new issues - No-repo templates added in May — Slack digest, product analytics, FAQ, finance, customer health (no repo required)

We often pair these patterns with Forward Deployed Engineer-style enablement inside AI consulting engagements.

Selection comes down to whether your team already lives in Cursor and which SaaS triggers you depend on. Teams centered on Slack / Linear / Sentry / PagerDuty will likely find Cursor Automations the easiest path; teams that live in GitHub alone can stay with Actions and consider Claude Code Routines too.

1. Cost control — usage-based billing means high-frequency cron or a runaway easily produces unexpected charges. Team Owned scope is especially exposed 2. Runaway prevention — automatic-stop and cap settings are not extensively documented in the public changelog/docs; rely on dashboard controls 3. Scope hygiene — Private / Team Visible / Team Owned need an explicit ownership process, especially Team Owned (shared service account) 4. Personal-account attribution — Private and Team Visible PRs/comments are filed as the creator. Heavy-audit industries (finance, healthcare) need extra design 5. MCP authorization — Slack / Linear / PagerDuty MCP tokens should be governed centrally; letting personal connectors run unattended is a common foot-gun

Good fit:

- An always-on AI reviewer / first-responder without building infrastructure. The Slack / Linear / PagerDuty integrations are immediately usable, which cuts initial cost vs GitHub Actions + custom LLM scripts - After-hours work — dependency updates, test additions, vulnerability scans — that progresses while your office sleeps but US-hour agents run - Teams already running on Slack and Linear get the strongest fit

Bad fit:

- Strict on-prem requirements or extensive audit-log mandates - Approval flows that need finer-grained scopes than Cursor exposes - Non-engineering departments — design still requires engineering literacy

Enterprise plans add pooled usage, SCIM, and audit logs; build serious rollouts on that tier.

Q1. Are Automations a separate thing from Background Agents? A. Not really. Automations are the trigger / orchestration layer above Background Agents (a.k.a. cloud agents). Creating one in the dashboard or Agents Window ends up running a Background Agent under the hood. Q2. Does the 50% off apply to my existing Automations? A. The wording says runs of newly created automations. Best reading: only Automations created on or after May 20, 2026, for 7 days. Existing automation runs and interactive agent runs are out of scope. Q3. Should I replace GitHub Actions with Automations? A. Depends on workload. Deterministic build/test/deploy is still safer in Actions. Context-driven LLM judgment (PR evaluation, code review, doc generation) is much cleaner in Automations. Most teams will run both. Q4. Cursor Automations vs Claude Code Routines — which? A. If your team is in Cursor already, Automations is the lowest-friction option. If you're CLI-centric and built on the Anthropic stack, Routines wins. Cursor currently has the broader SaaS-trigger coverage. Q5. Can I run the UI in Japanese? A. Cursor's UI is English-only as far as we can verify (not officially documented otherwise). Most teams operate in English UI. Q6. Can I run this on-prem? A. No. Automations run on Cursor's managed cloud sandboxes, even on Enterprise. Q7. Who is the commit author when Team Owned scope runs? A. A shared team service account. There is no personal attribution. Private / Team Visible attribute to the creator.

Cursor's 3.5 update signals that Automations have moved from a March announcement into a proper operational phase, integrated where developers actually work. The Agents Window now hosts interactive and automation agents side by side; multi-repo and no-repo broaden the surface; and the 7-day promo lowers the price of running a real PoC.

Practically: if you have a templatable after-hours workflow — SRE, QA, docs — this is a good week to run one PoC. Before scaling, codify three things: Team Owned ownership review, personal-account attribution risk, and a usage cap per Automation.

Primary: - Cursor Blog — Build agents that run automatically (Mar 5, 2026) - Cursor Docs — Cloud Agent Automations - Cursor Changelog - Cursor — Automate landing - Cursor Pricing Third-party: - TechCrunch — Cursor is rolling out a new agentic coding tool (Mar 5, 2026) - Dataconomy — Cursor's new Automations launch (Mar 6, 2026) - InfoQ — Cursor 3 Agent-First Interface - Digital Applied — Cursor 3 Agents Window guide - Tessl — Cursor launches Automations - Releasebot — Cursor Release Notes May 2026 Related: - Claude Code Agent View deep dive - OpenAI Symphony — ticket-driven Codex orchestration - Forward Deployed Engineer (FDE) Note: No public source explicitly states that Background Agents have been renamed and merged into Automations; the boundary remains slightly fuzzy in Cursor's own materials. Re-verify against the current docs and changelog before rollout.