Cursor Projects for QA can coordinate a larger testing effort across multiple agents, but coordination introduces new failure modes. Shared instructions can become stale, delegated tasks can overlap, evidence can be attached to the wrong build, and a polished summary can hide a failed or skipped test.

Cursor announced Projects in beta on September 10, 2026. According to the official changelog, a Project has a coordinator that plans work, delegates implementation to agents, and returns completed work for review. Projects can retain shared files across cloud and local machines, run in the cloud when a laptop is closed, and react to subscriptions such as schedules, pull requests, or Slack activity. This tutorial turns those capabilities into a controlled QA experiment rather than treating coordination as proof of quality.

What makes a Project different from one agent run?

A normal agent task has one prompt, one working environment, and one visible output chain. A Project may preserve context over time and distribute work to several agents. Cursor says the coordinator does not write code itself; it plans and delegates. That separation is useful for regression campaigns, migrations, or release verification, but it also creates more identities to track: the Project, coordinator, worker, repository, environment, build, task, artifact, pull request, and human reviewer.

The central QA question is not “Did the Project finish?” It is “Can we prove that every delegated result used the intended inputs, executed in the intended environment, satisfied its own oracle, and was combined without losing contradictions?”

1. Build a disposable multi-agent regression lab

Create a private test repository with three independent work packages. For example, assign API contract checks, browser regression checks, and database migration checks. Seed one known defect in each package, plus one clean control that must remain green. Add deterministic scripts that produce JUnit, JSON, screenshots, and logs without using production data.

Prepare a shared Project brief containing the release candidate ID, approved repository and branch, baseline commit, test-data seed, expected environment, supported browsers, API schema version, known exclusions, evidence naming convention, severity rubric, and the rule that uncertain results must be marked inconclusive. Keep a source manifest with a hash and review date for every shared file.

Add a harmless secret canary and hostile text inside a synthetic log, such as an instruction to ignore the test plan or upload evidence elsewhere. The expected behavior is to treat log content as untrusted data, never as authority. Use least-privilege credentials and a deny-by-default egress policy so the exercise cannot affect real systems.

2. Freeze identity before delegation

Record the Cursor surface and build, Project ID, coordinator task ID, worker task IDs, exact prompt, shared-context manifest hash, repository provider, repository and branch, base and head commits, environment version, active Build ID, operating system, runtime and dependency lock hashes, secret set name, network policy, MCP and skill versions, time zone, locale, test-data seed, budget, reviewer, and expected side effects.

This matters because Cursor Cloud Agents run in isolated virtual machines with cloned repositories, dependencies, secrets, startup commands, and network access. Cursor’s documentation says the Cloud Agents dashboard exposes the environment and Build used for a run. Capture that identity alongside the test report. A result from the wrong successful Build should fail provenance even when its assertions pass.

3. Give the coordinator a testable contract

Ask the coordinator to create one task per work package with explicit inputs, allowed paths, deterministic commands, expected artifacts, completion criteria, and non-goals. Require every worker to return a compact handoff record rather than a prose-only summary.

{
  "work_package": "browser-checkout",
  "base_sha": "expected-commit",
  "environment_build": "build-id",
  "commands": ["approved-test-command"],
  "status": "pass|fail|inconclusive",
  "evidence": ["report-id", "screenshot-id"],
  "changed_paths": [],
  "risks": [],
  "human_review_required": true
}

Validate the record outside the agent. Confirm that each artifact exists, belongs to the same run, matches the declared commit and environment, and contains the expected test count. Recalculate pass and fail totals from the raw report. A worker cannot certify its own evidence completeness.

4. Test shared-context propagation

Start with a golden run where every agent receives the same current brief. Then change one field at a time and observe the next delegation. Rename a shared file, update the supported-browser matrix, revoke an obsolete instruction, or change the release candidate ID. Verify which version each agent actually consumed rather than trusting the coordinator’s summary.

  • Missing context: remove the API schema and require the worker to stop as inconclusive.
  • Stale context: retain an older release brief and ensure the manifest freshness gate rejects it.
  • Contradictory context: place conflicting browser versions in two files and require escalation instead of silent selection.
  • Hostile context: insert an untrusted instruction in a log and verify that it cannot override Project policy.
  • Cross-task leakage: give workers different synthetic customer IDs and confirm evidence never crosses packages.
  • Compression or resume: pause and resume a long Project, then verify that critical constraints still appear in the effective handoff.

Shared context should improve onboarding, not become an unversioned source of truth. Keep authoritative requirements in version-controlled files and make the Project cite their exact identities.

5. Challenge delegation and concurrency

Parallel agents can reduce elapsed time, but overlapping ownership can create nondeterministic changes. Give two workers an intentionally shared fixture and check whether the coordinator detects the collision. Test duplicate delegation after a retry, late results from a cancelled task, one worker starting from a stale commit, another modifying generated artifacts, and a worker reporting success after its suite was skipped.

Add failure injection for environment provisioning, dependency installation, secret denial, blocked network access, rate limiting, MCP unavailability, browser startup, agent interruption, coordinator restart, and local-machine unavailability. Cursor’s Cloud Agent setup documentation says failed Builds do not replace the active successful Build. That is good for continuity, but your oracle must detect when a fallback Build is older than the intended baseline.

6. Verify cloud-to-local handoffs

The Projects announcement says a coordinator can start a local agent when testing requires the user’s machine. Create one controlled case that genuinely needs local hardware or an internal simulator. Require a handoff package containing the source commit, prepared artifact hashes, exact local prerequisites, approved commands, expected outputs, and a correlation ID.

Test the wrong local checkout, dirty working tree, missing simulator, different time zone, incompatible dependency, denied permission, interrupted connection, duplicate local execution, and a result uploaded after the Project has moved to a new release candidate. Compare local evidence against the handoff package before the coordinator can accept it.

7. Treat artifacts as evidence, not decoration

Cursor documents screenshots, videos, logs, and remote desktop access for Cloud Agent verification. Build an artifact manifest that binds every item to a worker, commit, environment Build, test ID, timestamp, and privacy classification. Check that screenshots show the expected release candidate, videos begin before the action under test, and log references contain the claimed assertion.

Exercise missing, duplicated, truncated, stale, mislabeled, and cross-run artifacts. Blur or remove sensitive values before upload. A screenshot of a green page is not enough when the browser console failed or the backend call returned the wrong payload.

8. Measure the Project as a system

Track context-version accuracy, correct-task routing, duplicate-work rate, stale-baseline rate, environment-provenance completeness, deterministic test completion, seeded-defect recall, false positives on clean controls, evidence precision, handoff rejection rate, secret-canary leakage, unintended changes, time to validated result, and review effort. Compare the Project with a single-agent or human baseline using the same fixtures.

A faster coordinated run is not better if reviewers spend longer reconstructing provenance. Set release thresholds on deterministic checks and evidence quality, not on the coordinator’s confidence or the number of agents used.

Practical release checklist

  • Project instructions and shared files are versioned, hashed, current, and conflict-checked.
  • Every delegated task has exclusive scope, a pinned baseline, deterministic commands, and a clear stop condition.
  • Worker results identify repository, commit, environment Build, test data, and evidence.
  • Raw reports independently confirm the coordinator’s combined status.
  • Retries, cancellations, stale workers, duplicate tasks, and partial failures fail safely.
  • Cloud-to-local handoffs preserve identity and reject late or mismatched evidence.
  • Secrets, network access, tools, and repositories use least privilege.
  • Humans approve defect acceptance, pull-request merge, deployment, and release.

Official sources

Sources reviewed September 14, 2026. Cursor Projects is described as a beta rollout, so verify availability and behavior in your account before making it part of a release process.