Cursor: Expert

Expert

At the top level you stop driving one Agent in one window and start orchestrating many: locally, in the cloud, and on triggers. The skill shifts from prompting to designing a system where each agent has a clean context window, a clear job, and a verifiable output.

Run agents in parallel

A single chat is one worker. Cursor lets you run several at once, each isolated:

• Local agents on git worktrees: multiple agents working different branches of the same repo on your machine, without stepping on each other.
• Cloud Agents: each runs in an isolated AWS VM, works on a remote branch, and opens a pull request when done. Launch them from the web, Slack, a GitHub/Bitbucket PR comment, Linear, or the API.

Because each agent gets a fresh context window, parallelism is also context hygiene: long or unrelated jobs don’t pollute each other.

Caution

Move to Cloud transfers conversation history and context but not your local uncommitted changes: the cloud agent starts from clean committed state. Commit or stash first, or the work you’re staring at won’t travel. And don’t put secrets in env files for cloud/background agents; use Cursor’s Secrets UI under Settings → Cloud/Background Agents → Secrets.

The Cursor CLI: agents in scripts and CI

The Cursor CLI (cursor-agent) runs the same Agent headless. Print mode (-p) makes it non-interactive, so it drops straight into scripts and CI:

cursor-agent -p "run the test suite and fix any failing tests" --output-format text

Flag	Purpose
-p	Print mode: non-interactive, for scripts and CI
--model	Pick the model
--output-format	Choose the output shape (e.g. text)
--sandbox	Enable or disable sandboxing
--continue / --resume	Continue or resume a session

The CLI carries the same three modes as the editor: Agent (default), Plan (--plan / /plan), and Ask (--mode=ask / /ask).

Package expertise: subagents and skills

Instead of bloating one giant rules file, factor reusable capability into scoped, near-free building blocks.

Subagents

Markdown files in .cursor/agents/. Frontmatter sets name, description, model (inherit or a specific ID), readonly, and is_background. They auto-delegate or run via /name, in parallel with isolated context. Nesting is limited to two levels.

Skills

SKILL.md folders using progressive disclosure, near-free in context until triggered. Manage them centrally via the Customize page and Team Marketplaces.

A background subagent looks like this:

---
name: test-runner
description: Runs the test suite and fixes failures
model: inherit
readonly: false
is_background: true
---

Run the project's test command. If tests fail, read the output, fix the cause, and re-run until green.

Automate the routine

Automations let agents run on triggers rather than on your keystrokes. Triggers cover source-control events (GitHub, GitLab, Bitbucket), Slack messages and reactions, Linear issues, Sentry and PagerDuty incidents, webhooks, and cron schedules. You create one from the Agents window, from cursor.com/automations, or by describing the workflow in plain language with the /automate skill.

A worked example, issue to PR:

1. Run /automate and describe the workflow:

   When a GitHub issue in acme/webshop gets the label "agent-fix":
   read the issue, reproduce the problem, implement a fix on a new
   branch, run the test suite, and open a pull request that
   references the issue. Comment the PR link back on the issue.

2. Cursor turns that into an automation: trigger (issue labeled agent-fix), agent instructions, tools (pull request creation, issue comment), and repository scope. Review each part, then save and activate.

3. From now on, labeling an issue agent-fix launches a cloud agent. It works on an isolated branch and opens a normal PR, so your existing review gates (CI, Bugbot, human review) apply unchanged.

The label is the control point: nothing runs until a human decides an issue is safe to hand off. Keep that deliberate.

Verification has to scale with you

The more agents you run, the more the verification layer carries the weight. Cursor gives the agents readable checks and gives you automated review:

• /review runs pre-push code analysis before changes leave your machine.
• Bugbot reviews every PR update automatically, flagging bugs, security issues, and quality problems; trigger it manually by commenting bugbot run on a PR.
• Cloud agents open normal PRs, so review happens in your usual Git flow.

Caution

Auto-run guardrails are best-effort, not a hard boundary. Prompt injection from fetched web or MCP content can exfiltrate code, and a broad allowlist means agent edits and commands can execute before you read them. Scale the human diff review and PR gates up as you scale agents out; don’t loosen them. Watch the API usage pool too; frontier and Max usage can run out mid-month.

The orchestration mindset

Cursor 2.0 made the product agent-first, and Cursor ships roughly monthly. The feature surface will keep moving, so re-check the changelog before you rely on the newest thing. What doesn’t change is the shape of the work: AI is an accelerator with no opinion about direction. Many parallel agents only help if each one has the right context, a scoped job, and a check it can’t fake. That’s the craft (context engineering) and it’s what separates the teams that use AI right from the ones that just use a lot of it.

You’re done when…

• ✅ You’ve run agents in parallel (local worktrees or cloud) and merged their PRs
• ✅ You’ve driven cursor-agent headless in a script or CI step
• ✅ You’ve packaged a subagent or skill instead of growing one rules file
• ✅ Your review gates (/review, Bugbot, PR review) scale with the number of agents you run

Next step

You’ve reached the top of the Cursor track. Solidify the thinking that makes all of this work, or pick another tool.

Context engineering The craft at the heart of using AI well. Context is the steering.

Start here How these guides are organized; pick another tool track.