Cloud Agent Strategy
X4 does not use Cursor Cloud Agents as the primary cloud execution layer for feature implementation today. The current direction is to build X4-owned cloud agents and workers around the X4 framework, while keeping Cursor supported as an editor and coding surface.
Cursor Cloud Agents remain useful for bounded coding work, but they are not the default X4 runtime because X4 is solving more than code generation.
Decision
X4 owns cloud execution for now:
- X4 devboxes, workers, and sandboxes run implementation and validation work.
- X4 environment profiles define which services, data, and secrets are available.
- X4 validation results and GitHub evidence are the merge signal.
- Cursor and VS Code interact with X4 through the extension, generated
multi-root workspace, and
x4CLI commands.
Cursor Cloud Agents are deferred as an optional future runner. They may be reintroduced for low-risk tasks after X4 has stable repo-set, secret, service, validation, and evidence contracts.
Why Cursor Cloud Agents Are Deferred
The blockers are operational rather than model quality:
- Setup overhead. Cursor supports cloud environment setup, startup commands, Docker workflows, and cloud configuration, but X4 would need to maintain that setup separately for each repo set and service profile.
- Secrets complexity. X4 needs one durable model for service credentials, environment variables, dev/test secrets, masking policy, and audit trails. Mirroring secrets into Cursor creates another distribution path.
- Stateful service complexity. X4 features often depend on databases, storage, search indexes, queues, model providers, and external APIs. Keeping those services current, isolated, and safe for third-party cloud agents would become a second environment platform.
- Test data management. Realistic testing needs masked snapshots, seed data, schema compatibility, and stable validation identities. X4 still needs to own this proof even if Cursor runs supporting tests.
- Multi-repo orchestration. X4 already owns repo sets, branch naming, attached worktrees, split commits, pull requests, sandboxes, and evidence. Delegating edits to Cursor does not remove those responsibilities.
Current Split
| Area | X4 owns | Cursor owns |
|---|---|---|
| Work item planning and approval | Yes | No |
| Repo-set selection and multi-repo workspace | Yes | Opens generated workspace |
| Branch lifecycle and PR workflow | Yes | Edits code in the workspace |
| Cloud execution/runtime | X4 workers/devboxes/sandboxes | Deferred optional runner |
| Secrets and environment contracts | Yes | User/editor credentials only |
| Stateful service access policy | Yes | No |
| Official validation and merge evidence | Yes | Supporting editor proof only |
| Developer UI | X4 CLI and extension | Cursor editor surface |
The durable rule is:
X4 owns orchestration, runtime contracts, validation, evidence, and merge gates.
Cursor is an editor/coding adapter unless a future Cursor Cloud runner is
explicitly enabled for a bounded work item.
What To Build First
Near-term engineering should focus on:
- X4-native cloud agents and workers in X4-controlled infrastructure.
- The
x4CLI as the stable interface for humans, IDEs, agents, and automation. - The Cursor/VS Code extension as a thin adapter over the CLI.
- Generated
.x4/context, workspace files, and agent instructions. - Centralized secret and environment handling outside repo files and generated workspace files.
- X4-owned validation evidence posted to GitHub.
Do not make Cursor Cloud Agents the default implementation path yet. Keep any Cursor API runner experimental and feature-gated.
Revisit Criteria
Revisit Cursor Cloud Agents when most of these are true:
- X4 repo-set, sandbox, validation, and evidence workflows are stable.
- X4 has a secret/environment contract that can be safely projected into third-party runners.
- Stateful service profiles are simple enough to recreate or safely share.
- Cursor Cloud Agents can consume the required repo set, services, and secrets without extensive X4-specific setup glue.
- Cursor's API/proof surface is stable enough for X4 to ingest run state, branches, pull requests, logs, screenshots, videos, or summaries predictably.
- The cost and reliability profile is better than running the same work on X4-controlled workers.
Good future candidates include documentation changes, isolated UI updates, small refactors, and low-risk feature slices that do not require privileged stateful services.