Cursor Automations in the Agents Window

Teams usually do not fail because they lack ideas. They fail because work gets split across repos, chats, tickets, and half-finished prompts, and nobody can tell what the agent was allowed to touch. Cursor 3.5 matters here because it moves Automations closer to the place teams already review work, which helps if you are trying to ship with Cursor AI instead of just demo it.

The situation

Counter-thesis: the win is not more automation; it is fewer places for automation to drift.

The wrong path: we thought the fastest route was to let each team invent its own agent setup. We tried loose prompts, one-off rules, and ad hoc handoffs between Cursor Composer, tickets, and repo notes. What happened was familiar: context split, reviews got vague, and nobody could answer the simple question, “what did this automation actually read?”

Diagnosis: this is the old local-vs-global trap. The same pattern shows up in code review, config, and docs: if the boundary is fuzzy, the work becomes fuzzy.

Thesis: Cursor Automations work best when the boundary is explicit, scoped, and reviewable.

That matters more after this release because Cursor now puts Automations in the Agents Window, supports multiple repos, and allows no-repo automations. The product is pointing at a real team workflow: the unit of work is not always one repo, and not every useful agent needs code access.

What changes when the boundary is visible

1) Agents Window placement fixes the “where do I look?” problem. If you have shipped AI code, you know the pain of hopping between a web page, a chat, and the IDE just to understand one run. Cursor now lets you create and manage Automations in the same workspace as your agents, which narrows the review gap.

Named fix: Workspace-First Review. Put the automation where the team already inspects agent work. Then make review part of the same place you use for agent runs, not a separate ritual.

The practical effect is small but real: less context switching, fewer lost runs, and a cleaner path from trigger to diff. The thesis stays the same: Cursor Automations work best when the boundary is explicit, scoped, and reviewable.

2) Multi-repo automations match how engineering work actually looks. A lot of teams ask, “is Cursor suitable for teams and large codebases?” The honest answer is yes, but only if you stop pretending the work lives in one neat tree. Cursor’s multi-repo automations let agents reason across the context they actually need.

Named fix: Boundary Map. Write down which repos belong to one automation, why they belong together, and what the agent must not infer from the wrong repo. This is where Cursor rules and team conventions matter more than clever prompts.

When the agent can see the right repos, it can test and verify across the actual system instead of guessing. That is the difference between a useful automation and a noisy one. Again, Cursor Automations work best when the boundary is explicit, scoped, and reviewable.

3) No-repo automations widen the lane beyond code. Cursor added templates for Slack digests, product analytics, product FAQ, finance, and customer health. That is not a side note. It means some of the highest-value automations live around engineering, not inside the repo.

Named fix: Signal-to-Action Loop. Define the signal, the allowed action, and the owner before you create the automation. If the agent watches Slack, data, or billing, the team should know what happens when it fires.

This is where MCP thinking helps. The protocol connects models to tools and data, but it also keeps consent, scope, and control in the design instead of pushing them to a later review step. The thesis still holds: Cursor Automations work best when the boundary is explicit, scoped, and reviewable.

4) Skills and rules still do the boring work. Cursor subagents and Cursor skills are useful only when the team has a shared way to describe what good looks like. A skill is a reusable instruction package. A rule is a boundary the agent should respect.

Named fix: Scoped Instruction Stack. Keep durable team rules in AGENTS.md or Cursor rules, then use skills for repeatable work and subagents for isolated work. If you need a custom agent, give it a narrow job and a narrow exit path.

That stack keeps Cursor for teams from turning into a pile of private habits. It also makes review easier, because reviewers can point to the file that set the behavior. The same thesis applies: Cursor Automations work best when the boundary is explicit, scoped, and reviewable.

A practical artifact you can copy

Use this as a starter checklist for one automation 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 boundary, pair that checklist with a short AGENTS.md note:

## 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.

Tradeoffs and limits

Cursor’s new flexibility is useful, but it also raises the cost of sloppy setup. Multi-repo access can widen blast radius, and no-repo automations can become opaque if you do not write down the signal and the owner.

Counter-thesis: flexibility only helps when the team can see the boundary.

One image: think of each automation like a fenced workbench, not a roaming robot. If the fence is clear, the team can trust the tool; if it is vague, every run becomes a review tax.

Further reading

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

Next step

Start with one repo boundary, one review checklist, and one owner. Then move the pilot into Cursor subagents and skills so the same rules can carry into the next workflow.