Cursor Automations in the Agents Window

A Cursor Automation is an agent workflow that runs from a trigger, bound to one or more repos or to no repo at all. Since Cursor 3.5 they live in the Agents Window, which is the same place your team already reviews agent work. That single move is the point: instead of an automation hiding in a web page or a side panel, it sits next to the runs you inspect every day. Cursor, Anysphere's AI code editor, made the change so the trigger and the diff finally share an address.

Most teams do not stall because they run out of ideas. They stall because work gets scattered across repos, chats, tickets, and half-written prompts, and nobody can answer one plain question: what was this automation actually allowed to touch? When the boundary is visible, that question has an answer.

Find your automations where you already review agents

Before 3.5, understanding one automation run often meant hopping between a web page, a chat, and the editor. The Agents Window collapses that. You create and manage Automations in the same workspace where you watch agent runs, so review stops being a separate ritual.

The practical effect is modest but real. Less context switching, fewer lost runs, and a short path from trigger to diff. Put review where the work already lives, and people will actually do it.

Map which repos an automation can see

A lot of teams ask whether Cursor fits large codebases. The honest answer is yes, as long as you stop pretending the work lives in one tidy tree. Multi-repo automations let an agent reason across the repos it genuinely needs, which is closer to how engineering actually looks.

The trade is blast radius. More repos means more places a run can change, so write down the boundary on purpose. For each automation, record which repos belong together, why, and what the agent must not infer from the wrong one. This is where Cursor rules and shared team conventions earn their keep, more than any clever prompt does.

Use no-repo automations for the work around the code

Cursor also added no-repo automations with templates for Slack digests, product analytics, a product FAQ, finance, and customer health. That is not a footnote. Some of the highest-value automations live around engineering rather than inside the repo.

The risk here is opacity. An agent watching Slack, data, or billing can become a black box if you skip the setup. So define three things before you create it: the signal it reacts to, the action it is allowed to take, and the person who owns it. This is also where MCP thinking helps, because the Model Context Protocol keeps consent and scope in the design instead of shoving them into a later review.

Let skills and rules carry the boring parts

Cursor subagents and Cursor skills only pay off when your team shares a way to describe what good looks like. A skill is a reusable instruction package. A rule is a boundary the agent should respect. A subagent is a way to run isolated work without polluting the main thread.

Keep durable team rules in AGENTS.md or Cursor rules. Use skills for repeatable work, and reach for a subagent when a task deserves its own narrow lane and a clean exit. The win is that a reviewer can point at the exact file that set the behavior, which beats arguing about a vanished prompt.

Here is a starter checklist you can paste into your first pilot:

# Cursor Automation Pilot Checklist

- [ ] Name the automation and its owner.
- [ ] List the exact repos it may read.
- [ ] State whether it is repo-bound or no-repo.
- [ ] Add one Cursor rule for scope and one skill for repeatable work.
- [ ] Decide whether a subagent should handle the task in isolation.
- [ ] Write the trigger, allowed tools, and stop condition.
- [ ] Define the review step: who checks the output and where.
- [ ] Record the rollback path if the automation misfires.
- [ ] Test one dry run before enabling production triggers.

If you want a tighter fence, pair it with a short note in AGENTS.md:

## Automation boundary

This repo allows Cursor agents to propose changes only in `src/` and `tests/`.
Do not let automations modify release scripts, infra, or secrets files.
All automation output must include a review note that names the trigger and the repos used.

Common questions

• What are Cursor Automations?

  Cursor Automations are agent workflows that run from a trigger, bound to one or more repos or to no repo at all. Since Cursor 3.5 you create and manage them in the Agents Window, the same workspace as your agents. That placement shrinks the gap between a trigger firing and a human reviewing what it produced, because both now live in one view.

• Can Cursor Automations span multiple repos?

  Yes. Multi-repo automations let an agent reason across the repos it actually needs, which matches how real engineering work is spread out. Before you turn one on, write down which repos belong together, why they belong together, and what the agent must not infer from the wrong repo. That short map keeps the wider access from quietly widening your blast radius.

• What are no-repo automations for?

  No-repo automations cover work that lives around engineering rather than inside the repo. Cursor ships templates for Slack digests, product analytics, a product FAQ, finance, and customer health. Define the signal, the allowed action, and the owner before you create one, so an agent watching Slack or billing never becomes a box nobody can explain.

• Is Cursor suitable for teams and large codebases?

  Yes, as long as you stop pretending all the work sits in one neat tree. Multi-repo automations let agents test and verify against the actual system instead of guessing from a single repo. The catch is discipline: keep each boundary explicit, scoped, and reviewable, or the extra flexibility just turns into a bigger surface for mistakes.

• How do you pilot a Cursor automation safely?

  Run the pilot checklist top to bottom. Name the automation and its owner, list the exact repos it may read, set the trigger and stop condition, define who reviews the output and where, record the rollback path, then test one dry run before any production trigger fires. The dry run is the cheapest insurance you will buy all week.

Start with one boundary

Pick one automation, one owner, and one review checklist, then expand only once that loop is boring. When you are ready to make the rules portable, carry them into Cursor subagents and skills so the next workflow inherits the same fence.

Further reading

• Cursor: Agent
• Cursor: Rules
• Cursor: Skills
• Cursor: MCP
• Cursor: Enterprise
• Cursor: Changelog
• Model Context Protocol: specification
• Cursor subagents and skills
• Our methodology