--- title: "Cursor 3.5: Automations Graduate to the Agents Window" date: 2026-05-26 tags: ["cursor","automations","multi-agent","agentic workflows","ai coding tools"] categories: ["AI Tools","Agentic Workflows"] summary: "Cursor 3.5 (May 20) brings Automations into the Agents Window and adds multi-repo support — finally letting a single automation agent reason across multiple codebases. Five no-repo templates also ship, signalling that Cursor is expanding from coding IDE to general business automation platform." --- Cursor 3.5 shipped quietly on May 20, 2026, but the update is worth paying attention to: **Automations are now a first-class feature in the Agents Window**, multi-repo context is supported, and five no-code templates open Cursor's automation marketplace to workflows that don't touch a codebase at all. The changes are incremental individually. Combined, they sketch out a clearer picture of where Cursor is heading: from an AI-powered IDE to a cloud automation platform that happens to be strongest at code. ## Automations Arrive in the Agents Window Until this release, Cursor Automations lived at `cursor.com/automations` — a separate web surface you had to navigate to outside the IDE. That split was a friction point: you'd build your agent in the IDE but manage scheduled runs in the browser. Version 3.5 unifies them. **Automations are now available directly inside the Agents Window**, the same panel where you launch interactive agents, review cloud sessions, and monitor running tasks. You can create, configure, and trigger automations without leaving your workspace. This matters because it reinforces Cursor's mental model: the Agents Window is becoming the control plane for all agent activity — interactive, scheduled, and event-driven. A developer who lives inside Cursor no longer has a reason to leave the IDE for automation management. ## Multi-Repo: Solving a Real Problem The most substantively useful change in 3.5 is **multi-repo automation support**. You can now attach multiple repositories to a single automation, letting the agent reason across all of them — investigate an issue, determine which repos it spans, and open PRs in the right places. This is a real-world necessity that single-repo automation systems quietly skip past. Production engineering work rarely stays inside one codebase. A bug reported in the front-end might trace to a contract change in a shared API client, which lives in a separate repo. A schema migration might require coordinated changes across a service and its consumers. Previously, you'd have to break this into multiple agents, pass context manually, and glue outputs together yourself. Multi-repo automations let you describe the task once and let Cursor's agent sort out where the work lives. The agent loads all attached repos into its cloud dev environment, executes with full cross-repo context, and surfaces results back in the Agents Window. There are limits — context windows still have practical ceilings, and large multi-repo setups will hit those limits faster than single-repo runs. But for the common case of two to four interdependent repos, this removes a genuine workflow bottleneck. ## No-Repo Automations: The Platform Play The quieter strategic signal in 3.5 is **no-repo automations** — automations that run without any attached codebase. Cursor added five Marketplace templates for this new category: - **Slack Digest Agent** — summarizes unread DMs and key Slack channels each morning, prioritized by importance - **Product Analytics Agent** — aggregates metrics and surfaces weekly trends - **Product FAQ Agent** — answers support questions from a product knowledge base - **Product Finance Agent** — pulls financial metrics from connected data sources - **Customer Health Agent** — monitors account signals and flags churn risk These are not coding tasks. They don't touch a repository. They're scheduled business automation agents that happen to be configured and managed from the Cursor Automations interface. This is a deliberate expansion of Cursor's surface area. By making Automations work without a repo, Cursor is positioning itself as a general-purpose automation platform for software teams — not just the IDE where engineers write code, but the place where the team's recurring operational workflows live too. Whether that makes sense architecturally is a separate question (see below). The commercial logic is clear: if you're already paying for Cursor and it can replace a Zapier or Make subscription for your team's workflow automations, that's a retention moat. ## How This Compares to Claude Code Routines Claude Code Routines take a different architectural approach. They run on **Anthropic's cloud infrastructure** — no Cursor workspace required, no persistent browser session needed. You schedule a Routine via the `/schedule` command or the API, and it fires on its own compute, reports results through the agent notification system, and terminates cleanly. Cursor Automations run inside **Cursor's cloud dev environments** — the same sandboxed Linux containers used by cloud agents. This means they have full IDE-equivalent context (codebase, terminal, file access), which is the right choice for complex coding tasks. But it also means they're coupled to Cursor's infrastructure, billing, and model choices. When you run a Claude Code Routine, it runs on Anthropic's stack with Opus 4.7. When you run a Cursor Automation, it runs on Cursor's stack with Composer 2.5 or whatever model they've configured. For coding tasks, both approaches work. Cursor has a usability advantage for teams already embedded in the Cursor workspace. Claude Code Routines have an infrastructure advantage for teams running headless, CI-adjacent, or multi-environment workflows where IDE coupling is a liability. The no-repo templates are where the comparison breaks down entirely. Claude Code doesn't have a Slack digest agent. Cursor is competing in a different quadrant there — and it's a bet that coding tool stickiness can extend into business automation. ## The Structural Picture Cursor 3.5 continues a pattern visible since Cursor 3.0: **the IDE is becoming the host application, not the core product**. The core product is increasingly the agent platform — cloud dev environments, the Automations scheduler, the Agents Window, the Marketplace. That's a coherent strategy. But it also means Cursor's competitive moat is now about platform breadth rather than any single capability. Multi-repo automations and no-repo templates are genuine features. They are not, however, a fundamentally new architecture. The agents still run inside Cursor's containers. The context is still loaded and managed by Cursor's toolchain. The automation runs when Cursor's scheduler fires it. Terminal-native, infrastructure-agnostic agentic execution — the model Claude Code represents — doesn't need a host application to schedule or manage it. Claude Code Routines can be triggered by GitHub webhooks, cron schedules, or API calls from your own systems, without passing through Cursor's surface at all. Multi-repo automations in the Agents Window are a meaningful improvement for Cursor users. For engineers evaluating which automation layer to build on, the architectural difference still applies: platform-hosted vs. infrastructure-agnostic. That gap hasn't closed in 3.5. --- **Sources:** - [Improvements to Cursor Automations](https://cursor.com/changelog/05-20-26) — Cursor Changelog, May 20, 2026 - [Automations | Cursor Docs](https://cursor.com/docs/cloud-agent/automations) — Cursor Documentation - [Cursor launches Automations for always-on coding agents](https://tessl.io/blog/cursor-launches-automations-for-always-on-coding-agents/) — Tessl Blog - [Cursor Release Notes - May 2026](https://releasebot.io/updates/cursor) — Releasebot - [Development environments for your cloud agents](https://cursor.com/blog/cloud-agent-development-environments) — Cursor Blog