Rolling out Cursor to a team: what to set up before cloud agents

Last checked: 21 Oct 2026. Product facts come from Cursor's own documentation, help centre, pricing page and terms, and the research findings come from the published studies linked where they appear.

Buying Cursor seats is quick. Getting consistent, well-reviewed work out of those seats takes setup that a licence does not include: shared project rules, team configuration kept in version control, a calibrated review process, spend limits and one named person who owns all of it. Put those in place first, check the team against a readiness test, and only then hand work to Cursor's cloud agents and automations.

One piece of context before the detail. Cursor announced on 14 Aug 2026 that it has been acquired by SpaceX, and it is now sold as part of The X Subscription from SpaceX Super Intelligence (SpaceXSI), the company behind Grok, which introduced that combined plan on 12 Oct 2026. Earlier plans continue for existing customers and some controls differ between them, so check which plan you are on. Our SpaceXSI guide for UK business explains how its products fit together.

Why licences on their own give broad, shallow use

A Carnegie Mellon study of open-source projects that adopted Cursor found a large but short-lived rise in development speed, concentrated in the first two months, alongside a lasting rise in static analysis warnings (up 30.3%) and code complexity (up 41.6%). The authors call for process changes that scale quality assurance with the faster pace. The study covers open-source repositories that mostly adopted Cursor between Aug 2024 and Mar 2025, before cloud agents.

A Microsoft study of command-line coding agents (Claude Code and GitHub Copilot CLI, written by Microsoft employees about tools Microsoft sells) found that first use spread mainly through engineers' social networks, and the authors say visible peer use should be central to rollout. The DORA 2025 report describes AI as an amplifier of an organisation's existing strengths and weaknesses.

Cursor's Grab case study says Grab treated its rollout as enablement rather than a mandate, and that power users among its software engineers sent 18 times as many messages as light users. Our inference is that the same seat produced very different depth of use inside one company. Grab's route shows that setup-first is not the only way to roll Cursor out, though it is the order we recommend when cloud agents will work on shared code. Cursor's own enterprise admin setup guide covers identity, source control, company devices and usage monitoring, and does not mention rules or spend limits, so treat it as the floor.

The order we recommend

This sequence is our recommendation, drawn from how we use Cursor in our own engineering. Cursor does not publish it, but each step rests on what Cursor's documentation says the product does.

1. Shared rules: small, owned and in the repository

Cursor has four kinds of rule. Project rules are stored in .cursor/rules and versioned with the code. Team rules are managed from the dashboard on Team and Enterprise plans, and an admin can make each one required so members cannot switch it off. Personal rules set in Cursor's settings are stored on the person's Cursor account and apply across all their projects. AGENTS.md is a plain markdown alternative. When guidance conflicts, team rules come first, then project rules, then personal rules.

Cursor advises starting small: add a rule only when the agent makes the same mistake repeatedly, keep rules under 500 lines, and use a linter instead of copying a style guide. So the first job is the shared place, the owner and the change process, seeded with a handful of rules. One silent failure catches teams early: Cursor ignores a plain .md file in .cursor/rules because it has no frontmatter.

Cursor's safety and controls page calls rules "suggestions, not guarantees" and says to combine them with hooks for anything that must be followed. Our guide to Cursor rules, skills, subagents and hooks covers how each mechanism works.

2. Versioned team configuration

Cloud agents work from what is in the repository and what has been synced or published, and a developer's laptop settings stay behind. Cursor does not copy personal or unsynced skills to cloud agents, and synced skills stay private to the person who synced them. To share one, publish it to the team marketplace, which Teams and Enterprise plans include and which also carries plugins and MCP servers.

Hooks committed at .cursor/hooks.json run in cloud agents, and on Enterprise plans team and enterprise-managed hooks run there too. User-level hooks are not available in cloud agents. Environment configuration belongs in .cursor/environment.json, and command-approval settings can be committed per project or set centrally, where a team configuration overrides the project and user files. Cursor states on that page that Auto-review is not a security boundary.

Two inferences of ours follow. A safety check that lives in someone's personal hooks file does not exist in a cloud run. And committed configuration is something an attacker can target: CVE-2025-54136, since fixed, described an attacker swapping an already-trusted MCP configuration in a shared repository for a malicious command. Review changes to .cursor files as you would code and keep Cursor up to date. Enterprise teams can also require approval before agents modify that directory.

3. Review calibration

Cloud agents open draft pull requests, and nothing merges until a person reviews the change. Cursor's own best-practice post spells out what that means: "The faster the agent works, the more important your review process becomes."

Bugbot reviews pull requests, but Cursor project rules do not apply to Bugbot runs. Its guidance goes in separate .cursor/BUGBOT.md files, so a team that writes conventions only in .cursor/rules will find the reviewer ignores them. Effort levels on usage-based Bugbot plans set the trade between review cost and how much it may find. Requiring the Bugbot status check alone does not block merges on findings, because findings default to neutral, so branch protection needs a deliberate decision before agents start opening pull requests. Cursor's PR Routing & Approval can approve low-risk changes, and on Team plans every member can create and edit it, so decide who may switch on automated approval before anyone does.

Calibration means tuning Bugbot against the comments your senior reviewers already make and adding guidance where it misses what they catch. Our post on calibrating Bugbot to your senior reviewers goes further.

4. Spend controls

Each paid seat on the new plans includes a weekly usage pool, and on Teams seats do not share pools, so a few heavy cloud agent users can hit their own limits while colleagues' pools sit unused. Cloud agents are charged at API pricing for the selected model, and Cursor asks for a spend limit the first time someone uses them. On Teams under The X Subscription, admins set one monthly additional usage limit for the whole team, and only admins can change it. Enterprise adds member and group limits. Two of Cursor's Teams pages also mention a default per-member limit, so check your own dashboard before relying on one. Enforcement is not instant, and spend alerts warn without stopping anything. On earlier Teams plans, turn on the "Only Admins Can Edit Usage Settings" toggle, because while it is off any member can change these settings. Cursor's pricing page publishes no sterling prices, and its prices exclude VAT. Our post on Cursor spend controls and model choice covers limits, pools and Auto routing in depth.

5. A named owner

Cursor's role for this is Admin. Admins control team management and security settings, an unpaid Admin can manage the team without using a paid seat, and a team must always have at least one Admin and one paid member. "Owner" is our word: one named person with the Admin role who decides which team rules are required, approves changes to committed configuration and marketplace content, holds the spend limit and alerts, and settles settings such as automated approval and team follow-ups. Give them a second reviewer for configuration changes. Our guide to setting up Claude Code for a business team takes the same approach to ownership for teams on that tool.

Is the team ready for cloud agents? A test you can run

Cloud agents run in isolated virtual machines with full development environments, and they run terminal commands automatically. Cursor calls environment setup the most important step, and its best-practice page gives a plain test: "If it is hard for a human developer to test locally, it will also be hard for an agent." The checklist below is ours, built on Cursor's documentation.

Signs a team is not ready yet

These signs come from our own experience rather than any vendor page, tied to the evidence above where it applies.

Use is uneven across teams. One team uses Cursor heavily and the team next to it barely opens it. The Microsoft study found that first use spread through peers, so a pilot group that others can watch working is a better lever than a mandate.

Senior engineers are sceptical. They usually carry the review load, and the Carnegie Mellon findings on warnings and complexity give their caution a basis. Their review comments are the material for Bugbot guidance and project rules, so bring them in early.

Every team is doing its own thing. Personal rules, unsynced skills and personal hooks do not reach cloud agents, so an agent working on shared code starts without the team's conventions. If nobody can say who administers the Cursor dashboard, that is the same sign.

Then automate

Cursor Automations run cloud agents on a schedule or in response to events from GitHub, GitLab, Slack, webhooks, Linear and other sources. Each automation runs as its own service account and does not use any member's personal usage, so the team spend limit is the control that matters. Cursor's master services agreement also says that where a feature executes code suggestions without manual review, the customer is solely responsible for any impact, including putting safeguards, testing and monitoring in place. That is a point for your lawyers, and a good reason to finish steps 1 to 5 first. Our post on what to automate first with Cursor picks up from here.

UK points to settle before cloud agents

Cursor says cloud agents are the only feature that requires it to store code, and that if your security policy prohibits code storage you should not enable them. Cloud agents run in Privacy Mode, repository snapshots are deleted after 30 days of inactivity, and conversation history is kept indefinitely by default. On residency, Cursor offers US-only data residency to Enterprise customers and EU and UK inference-only coverage on request, with no UK storage option. The data processing addendum Cursor publishes includes the UK International Data Transfer Addendum but was last updated on 5 Nov 2025, before the change of ownership, so ask your lawyers to read the current documents. Our post on UK data residency across AI vendors sets this alongside the other providers.

Common questions

Do we need shared rules before rolling out Cursor to the whole team?

You need the shared place for them, an owner and a way to approve changes. The rules themselves can start small. Cursor advises adding a rule only when the agent repeats a mistake and keeping rules short and in version control. Rules guide the model and enforce nothing, so anything that must always happen belongs in hooks.

Who should own Cursor's team configuration?

One named person with Cursor's Admin role, which can be an unpaid admin seat, plus a second reviewer for changes to rules, hooks and marketplace content. Cursor's concept is the Admin role. Naming a single accountable owner is our recommendation.

How do we control Cursor spend across an engineering team?

Admins on Teams can set a team-wide monthly limit. Cursor documents member-level limits for Enterprise, and two of its Teams pages also mention a default per-member limit, so check your own dashboard before relying on either. Alerts warn without stopping usage, and enforcement is not instant.

How do we know our team is ready for Cursor cloud agents?

Start with Cursor's own test: if the repository is hard for a person to build and test locally, it will be hard for an agent. Then check access, secrets, network policy, review, seat tier and spend limits, and confirm the security team accepts that cloud agents store code.

Should every developer get a Cursor seat on day one?

Our advice is to start with a pilot group that others can see working. The seat tier decides whether cloud agents are available at all, and on Teams each seat has its own usage pool.

If you want an outside view of where your team sits against the readiness test, start with our diagnostics. If you already know what you need, Request a Quote from our SpaceXSI and Cursor implementation page.

John Kelleher holds the SpaceX Super Intelligence Partner Network Accreditation: Forward Deployed Engineer.