Cursor 3.4 cloud agents

Cloud agents in Cursor 3.4 run your work on a remote machine and hand it back as a pull request, so the PR is the only place you ever meet them. Cursor, Anysphere's AI code editor, calls these cloud agents: an agent run that executes off your laptop and lands as a branch and a PR instead of an editor session. That changes one thing in particular. You no longer watch the work happen, so the run has to leave a trail a reviewer can follow without you in the room.

When that trail is missing, you get a tidy-looking PR that reads confidently and explains nothing. The fix is not a smarter model. It is paperwork you set up before the run starts.

Why the review queue is the real bottleneck

More autonomy feels like the win, but it usually moves the bottleneck rather than removing it. Each remote run finishes faster while your review queue gets slower, because the scarce resource was never agent speed. It was reviewer attention.

So the goal flips. Instead of optimizing the agent, optimize the queue: make every remote run pay for its own review before it kicks off. A run that arrives with its intent, scope, and proof already written is cheap to merge. A run that arrives as a confident mystery is expensive every single time.

Set up four receipts before the run starts

Four small habits cover most of what goes wrong remotely. Each one is a thing you write down once and reuse.

Name a connector steward. Where Cursor MCP is on, connectors multiply faster than anyone owns them, and a remote run makes that worse because nobody watched it fire. Put a human owner and a rotation date next to each MCP entry, with the Model Context Protocol specification as the shared boundary language. Now changes stop landing as anonymous convenience.

Put broad globs on a diet. Wide .mdc globs hand an agent contradictory guidance, and a cloud agent inherits it with no human nearby to flinch. Split your Cursor Rules by folder concern and ban the mega-glob unless it ships with explicit exceptions. A reviewer can then cite the governing file without a scavenger hunt.

Give demo prompts an expiry date. Temporary prompts written for a demo tend to harden into defaults, and remote automation replays those defaults at scale. Add an owner and a retire-by date inside the rule comment so cleanup is scheduled, not heroic.

Open every skill with a precedence preamble. When a skill contradicts an always-on rule, that fight is mildly annoying on your laptop and invisible in a datacenter. Have every SKILL.md open by naming which .mdc files override it, so activation order stops being tribal knowledge.

Here is a starter rule file you can paste and adapt to your repo:

---
description: Delegation boundary snapshot (adapt globs to your repo)
globs:
  - "**/*"
alwaysApply: false
---

- Cursor: keep scopes explicit in `.mdc`; forbid undeclared MCP domains.
- Claude Code: cite `CLAUDE.md` precedence before expanding bash scope.
- Codex: ensure `AGENTS.md` carries replay-friendly verification notes for CLI runs.

The environment half of this, what a remote run inherits before it edits anything, is covered in Cursor cloud agent setup: the environment contract. The broader patterns live in the subagents and skills topic hub.

Review a cloud agent with the same four gates

Distance does not change the questions you ask at merge time. The runtime surface is documented under Cursor Agent, org defaults under Cursor Enterprise, and what shipped this week in the changelog. The gates stay the same whether the work ran on your laptop or a server.

Run this checklist against the PR before you approve:

• MCP connectors mentioned (if any) list owners.
• Verification command output is pasted or linked.
• Forked agent work lists parent and child responsibilities.
• Red-folder paths received explicit human acknowledgement.

Some calls never move to the agent: threat models, customer promises, and blast-radius decisions stay with a person. A clean way to think about reliability here is a three-layer receipt: intent, scope, and verification. Pull one layer out and the rest does not hold.

Common questions

• What are Cursor 3.4 cloud agents?

  Cursor 3.4 cloud agents are agent runs that execute remotely and arrive as pull requests instead of editor sessions. Because nobody watches the run, the PR is the only evidence you get. So the operating contract, connector stewards, scoped rules, expiry tags, and skill preambles, has to live in the repo before the run starts.

• Who reviews a cloud agent's pull request?

  A named human reviews it, using the same four gates as local work: which connectors fired, whether a stranger can trace intent without chat replay, whether red folders were touched and approved, and which commands prove the regression guards. Distance raises the evidence you need in the PR body, not the ownership of the merge.

• Do cloud agents need their own rules?

  They need sharper versions of the rules you already have. Broad .mdc globs hand a remote agent contradictory guidance with no human nearby to catch it, so the glob diet matters more here. And every SKILL.md needs a preamble naming which rules override it, before the run resolves those conflicts alone.

• How do you keep remote runs explainable?

  Make every run pay for its review before it starts. That means a steward beside each connector, scoped rules per folder, expiry tags on temporary prompts, and a receipt in the PR body listing intent, scope, and verification. When those receipts are missing, your review queue absorbs the cost instead.

Start with one receipt

Name a connector steward and put the glob diet in place before the next batch of remote runs hits the queue. Our training installs all four receipts against your own repos in a single session.