Running Agentic Workspaces in the Cloud at Scale

Running one workspace agent in the cloud is a productivity trick. Running ten of them reliably is an engineering discipline. The gap between the two is not compute — it is environment reproducibility, secrets hygiene, private-repo authentication, rate-limit budgeting, and a review pipeline that does not collapse under agent throughput.

This is Part 3 of the Agentic Workspaces series. The flagship article said the daily loop is “the same loop, different harness” and that is true. But configuring the harness for one agent versus a fleet is not the same problem. This article is about provisioning, parallelizing, hardening, and observing that loop at fleet scale.

On July 8, 2026 I reviewed official Cursor Cloud Agent docs and changelogs, and Claude Code on the web / Routines / Ultrareview docs. Product capabilities are source-backed and dated; several features are in research preview and flagged as such. Architectural recommendations are labeled editorial inference — verify current behavior before you rely on it, because both platforms move quickly.

Audience: engineers and architects standing up cloud agent fleets, with a delivery-throughput lens for PMs and scrum masters.

TL;DR

• The binding constraint at scale is human review capacity, not tokens or compute (editorial judgment). Design your WIP limit around reviewer-hours, not how many sessions you can afford.
• Environment-as-code is the foundational requirement. Cursor uses .cursor/environment.json (+ optional Dockerfile); Claude Code on the web uses setup scripts and SessionStart hooks with cached snapshots.
• Secrets are the top fleet failure mode (inference). Scope them tightly, inject via the platform’s secrets store, and never bake tokens into containers or commit them.
• Private submodules need explicit auth. Cursor now offers native multi-repo environments (GA May 2026); submodule-based setups still need a scoped token + git insteadOf in a setup step.
• Fan out one agent per branch/repo/task, trigger via chat/PR/schedule/API, and always put the session URL in the PR body for traceability.
• Bounded-scope runs (sync + audit, no code writes) are safe to automate without the review gate; full-implement runs are not.

What You Will Learn Here

• How a cloud agent actually clones and provisions your workspace, on Cursor and Claude Code
• How to make environments reproducible with config-as-code and cached snapshots
• A secrets-scoping taxonomy and the private-submodule auth pattern for cloud VMs
• Three fan-out topologies and how to choose between them
• How to run scheduled/triggered, bounded-scope automation safely
• Observability, cost guardrails, and the review-capacity model PMs need

1. The Fleet Problem: One Clone vs Many

A local session inherits your machine: installed tools, cached dependencies, your dotfiles, your credentials. A cloud agent inherits nothing but the repo. Every assumption your loop makes about the environment must be encoded somewhere the VM can read.

At one agent that is a mild convenience. At ten agents running in parallel it becomes a hard requirement, because:

• each clone must provision identically or results diverge
• each needs credentials without leaking them
• they share rate limits and a spend budget
• their output lands in one human review queue

The parallelism dividend is real, but it comes with an environment reproducibility tax. The rest of this article is how to pay that tax once, in code.

2. Cloning the Workspace: What Happens in the VM

Cursor Cloud Agents check out a branch, isolate work to it, and push back to your remote; the environment resolves in order of environment.json → personal saved → team saved (Cursor Cloud Agent setup).

Claude Code on the web provisions a fresh VM per session (documented at 4 vCPU / 16 GB / 30 GB), authenticates the repo via a GitHub App or a /web-setup flow, and does not carry over your user-level ~/.claude config (Claude Code on the web). Anything project-specific must live in the repo.

The submodule gotcha: cloud agents historically clone without recursing submodules by default. On Cursor, the preferred fix today is native multi-repo environments (GA May 13, 2026). For submodule-based workspaces — and on platforms without a multi-repo primitive — you still authenticate and recurse explicitly (see §4).

3. Environment Reproducibility

Cursor: environment.json (+ Dockerfile)

{
  "build": { "dockerfile": "Dockerfile", "context": ".." },
  "install": "npm install && pip install -r requirements.txt"
}

Cursor rebuilds only changed Docker layers (the May 2026 blog cites materially faster rebuilds from layer caching), snapshots the environment after install, and — on snapshot failure or expiry — falls back to the base image with a visible warning rather than hard-failing (Cursor blog: cloud agent development environments).

Claude Code: setup script + SessionStart hook

{
  "hooks": {
    "SessionStart": [
      { "matcher": "startup|resume",
        "hooks": [ { "type": "command", "command": "\"$CLAUDE_PROJECT_DIR\"/scripts/install.sh" } ] }
    ]
  }
}

#!/bin/bash
# scripts/install.sh — only do heavy setup in the cloud
[ "$CLAUDE_CODE_REMOTE" != "true" ] && exit 0
npm install
pip install -r requirements.txt

CLAUDE_CODE_REMOTE=true is set automatically in cloud sessions (per the Claude Code on the web docs — verify the exact variable against current docs). Prefer setup scripts (which Claude Code caches between runs; check current docs for the TTL) for large installs; use SessionStart hooks for lightweight, per-session setup that should also run locally.

The snapshot lifecycle

First run                          Subsequent runs
─────────                          ───────────────
clone repo                         clone repo
run setup / Dockerfile             restore cached snapshot
take snapshot ───────────────────► load deps from disk (fast)
agent starts                       agent starts

on failure/expiry: base-image fallback + warning + install re-runs

Cloud-specific AGENTS.md

Because a cloud VM inherits only the repo (§1), every environment assumption the agent needs must be written down where it can read it. A cloud-specific AGENTS.md section is where those assumptions live:

## Cloud environment notes
- Node 20 (nvm), Python 3.12, pnpm preferred
- Run `pnpm install` before any test command
- Integration tests need DATABASE_URL (injected as a secret)
- apps/api and apps/web are both present; open one PR per repo; push api before web

4. Secrets and Private Submodule Auth

Scope everything to the minimum. Cursor exposes workspace/team secrets, environment-scoped secrets, Dockerfile-scoped build secrets, and AWS IAM role assumption (setup docs). Claude Code on the web stores environment variables in the environment config and, as of July 2026, has no dedicated secrets store — so keep those values minimal and rotate them, and prefer the GitHub proxy for repo auth over embedding tokens.

Private submodules in a cloud VM, when not using a native multi-repo environment — this is the runtime companion to the CI checkout snippets in Part 2:

#!/bin/bash
# setup step — token comes from the platform secrets store, never committed
git config --global url."https://${GH_ORG_PAT}@github.com/".insteadOf "https://github.com/"
git submodule update --init --recursive

Two operational facts that bite teams:

• Secret values are often redacted in tool output for security. Do not debug by printing a secret; print only a safe fingerprint (e.g., last 4 chars) to confirm injection.
• The default CI token is single-repo scoped. For multiple private submodules, use a fine-grained PAT or a GitHub App token scoped to exactly those repos (see Part 2 for the checkout snippets).

5. Fan-Out Topology

                ┌─────────────────────────────────────────┐
                │  Trigger: sprint start / API / PR comment │
                └───────────────┬───────────────────────────┘
                                │
                ┌───────────────▼───────────────────────────┐
                │  Workspace clone + environment snapshot    │
                │  (skills, knowledge, AGENTS.md baked in)   │
                └──────────┬───────────┬───────────┬─────────┘
                           │           │           │
                 ┌─────────▼──┐ ┌──────▼──────┐ ┌─▼──────────┐
                 │ Agent A    │ │ Agent B     │ │ Agent C    │
                 │ feat/1 api │ │ fix/2 api   │ │ docs/ web  │
                 └──────┬─────┘ └──────┬──────┘ └────┬───────┘
                        └──────────┬───┘             │
                                   ▼                 ▼
                    ┌──────────────────────────────────────┐
                    │  PRs → human review queue             │
                    │  session URL in each PR body (audit)  │
                    └──────────────────────────────────────┘

 rate-limit ceiling ───────── review-capacity ceiling (the real WIP limit) ──►

Three patterns:

• One agent per branch — parallel features/fixes in the same repo. Watch for base-branch drift while sessions run.
• One agent per repo — cross-repo feature; one PR per submodule; enforce merge order (API before UI).
• One agent per task — fine-grained fan-out for independent chores; highest throughput, highest review load.

Triggers: Cursor fires from Slack, GitHub @cursor comments, Linear, an API, iOS, and the web dashboard. Claude Code hands off from the CLI with --cloud and runs unattended via Routines (schedule, API, GitHub event) — a research-preview capability as of July 2026 (Routines).

6. Scheduled and Triggered, Bounded-Scope Runs

The safest automation is read-only: sync submodules and audit knowledge, output a report, write no code. A nightly knowledge-audit routine fired from CI after a big merge:

curl -X POST https://api.anthropic.com/v1/claude_code/routines/<routine_id>/fire \
  -H "Authorization: Bearer <token>" \
  -H "anthropic-beta: experimental-cc-routine-2026-04-01" \
  -H "anthropic-version: 2023-06-01" \
  -H "Content-Type: application/json" \
  -d '{"text": "Recent merges: PR #142 (api), PR #89 (web). Check .knowledge/ for drift."}'

Design the prompt to the scope: an audit routine reports drift and files a knowledge PR at most; it does not implement features. Cursor’s equivalent is chat/PR-triggered automations (@cursor in Slack/GitHub/Linear). Keep exact beta headers and endpoints verified against current docs — these preview APIs change.

7. Observability and Cost Guardrails

• Attribution. Claude Code adds a Claude-Session trailer to commits and PR bodies (v2.1.179+), giving you a session URL as an audit artifact. Cursor shows the environment version per run and keeps an audit log of environment changes.
• Cost. Cursor bills API pricing and requires a spend limit; set it before a fleet run. Claude Code draws on subscription usage with credits for overages and preview features like Ultrareview.
• Quality gate. Ultrareview (research preview — confirm current version and status in the Claude Code changelog) runs a multi-agent review fleet and exposes a non-interactive claude ultrareview for CI. Used as a pre-merge gate, it reduces trivial human review load; price is credit-based per the docs.
• Kill switches. Pause routines; set Cursor admin disables and spend caps. Have an off switch before you fan out.

8. Failure Modes at Fleet Scale

9. What PMs and Scrum Masters Need

Cloud agents can produce PRs faster than any sprint has burned tickets. That is not the bottleneck — review capacity is. A team that reviews 2 PRs/day and runs 20 sessions accumulates 18 unreviewed diffs, which is worse than not running agents because review debt compounds.

A practical model:

• Set the agent WIP limit to reviewer-hours-per-day ÷ avg-review-time-per-PR, not “how many sessions can we afford.”
• Bounded-scope routines (audit-only, no writes) are safe to run without the review gate — the output is a report, not a diff.
• Definition of done still applies: an agent PR is not done until a human approves and CI is green. The session trailer is your compliance/traceability artifact.
• Track agent throughput vs review throughput as separate metrics. When agent throughput exceeds review throughput by ~2x for two sprints, pause new triggers until review catches up.

Graduating Checklist

Before your first fleet run

1. Environment-as-code committed (environment.json or setup script) and tested from a clean clone.
2. Private submodule auth working via scoped token or native multi-repo environment.
3. A spend limit / usage budget set.

Before your tenth 4. Snapshot/caching validated; base-image fallback observed at least once. 5. Session URL in every PR body; attribution trailer enabled. 6. WIP limit tied to review capacity, enforced at the trigger layer.

Before you automate triggers 7. Bounded-scope prompts for scheduled runs (audit/sync only). 8. Kill switch tested (pause routines, admin disable). 9. A merge-conflict / base-drift check in the review routine.

Conclusion

The workspace pattern is harness-agnostic, but scale exposes everything the harness was hiding: environment assumptions, credential scope, and the finite capacity of human review. Encode the environment once, scope secrets tightly, fan out deliberately, and treat review capacity — not compute — as the real WIP limit. Do that and a fleet of workspace agents becomes an asset instead of a backlog of unreviewed diffs.

Next in the series: the MCP tooling that lets these agents trace, triage, and debug real systems.

Sources

Primary sources consulted July 8, 2026:

• Cursor Cloud Agents overview — cursor.com/docs/cloud-agent
• Cursor Cloud Agent setup (environments, secrets, multi-repo) — cursor.com/docs/cloud-agent/setup
• Cursor Cloud Agent best practices — cursor.com/docs/cloud-agent/best-practices
• Cursor blog: development environments for cloud agents (May 13, 2026) — cursor.com/blog/cloud-agent-development-environments
• Claude Code on the web — code.claude.com/docs/en/claude-code-on-the-web
• Claude Code Routines (research preview) — code.claude.com/docs/en/routines
• Claude Code Ultrareview (research preview) — code.claude.com/docs/en/ultrareview

Editorial inference (not vendor claims): review capacity as the binding WIP constraint; secrets misconfiguration as a top fleet failure mode; the split of native multi-repo (Cursor) vs submodule + token (elsewhere); bounded-scope routines as a maintenance primitive. Preview features (Routines, Ultrareview) and the “no secrets store yet” status are time-sensitive — reverify.

Related in this series:

• Part 1: Agentic Workspaces: Submodules, Skills, Knowledge, and Spec-Driven Delivery
• Part 2: Submodules as a Dependency Contract
• Part 4: Trace, Triage, Debug: MCP Tooling for Agentic Workspaces
• Related: Designing Subagents in the Cloud
• Related: How to Create PRs From Your Phone With Claude Code