Parallel AI agents can shorten a failure investigation, but only if their changes stay independent. Two agents editing the same test file can overwrite each other, a quick fix can contaminate the active checkout, and a shared database can make isolated branches produce misleading results. Antigravity worktrees for QA provide a practical way to separate file changes while testers compare competing fixes.
This tutorial builds a three-path investigation for an API assertion failure, a browser locator failure, and a fixture-data failure. Each path starts from the same Git baseline in its own Antigravity conversation and worktree. The QA engineer reviews every plan, diff, and deterministic test result before choosing anything to integrate.
What New Worktree Mode isolates
Google’s official Antigravity Projects documentation describes a Project as one or more folders that define an agent’s environment. Each project has its own settings and can add project permissions on top of inherited global permissions.
When a conversation starts, the worktree selector offers two relevant choices:
- Local Mode: the agent works directly in the active folder or Git checkout.
- New Worktree Mode: Antigravity creates a separate Git worktree for that conversation, keeping the active checkout untouched and reducing conflicts between concurrent agents.
A worktree separates repository files and branch state. It does not automatically isolate databases, test accounts, message queues, cloud resources, browser profiles, ports, or secrets. Those dependencies need their own test namespaces and cleanup rules.
Prepare a controlled failure lab
Create a disposable Git repository containing three reproducible failures:
qa-parallel-lab/
api/tests/test_orders.py
ui/tests/checkout.spec.ts
fixtures/orders.json
test-results/
README.md
Commit a known baseline. Record the commit hash, exact test commands, failure signatures, relevant environment variables, and checksums for the test and fixture files. Each failure should be deterministic and independent enough to investigate separately.
Use synthetic test accounts and a namespaced test-data prefix for every branch. If all three worktrees connect to the same mutable service, file isolation will not prevent one run from changing another run’s evidence.
Create the Antigravity Project safely
Add the Git checkout to a new Project. The current Antigravity settings documentation says project settings control folders, agent behavior, terminal execution, outside-folder access, sandbox mode, and project-level permissions.
For the lab, keep the default project boundary, deny outside-folder access, request review for terminal execution, and grant only the exact test commands needed. Antigravity’s permission engine evaluates conflicting rules as Deny, then Ask, then Allow. A broad Ask can still override a narrower Allow, so inspect the effective rule set rather than assuming specificity wins.
Example policy intent:
- Allow reads and writes only in the test repository and its generated results folder.
- Allow the exact unit, API, and browser test commands used by the lab.
- Ask before package installation, network access, or MCP tool use.
- Deny writes to Git configuration, credentials, deployment files, and production endpoints.
Launch three isolated conversations
Start three Antigravity conversations and choose New Worktree Mode for each one. Assign one evidence-driven hypothesis per conversation:
- API path: determine whether the assertion ignores an error payload or business rule.
- Browser path: determine whether the locator is unstable or the UI behavior actually regressed.
- Fixture path: determine whether stale or malformed test data causes both failures.
Give every agent the same baseline information and the same output contract:
Investigate only the assigned hypothesis. Do not modify production code, shared configuration, or unrelated tests. Produce a concise plan, the smallest proposed diff, the exact failing and passing commands, before-and-after evidence, and unresolved risks. Stop for review before applying or integrating changes.
This split reduces duplicate work and makes contradictory evidence easier to see. It also prevents an agent from changing several layers until a test happens to pass.
Use Planning Mode and review gates
The official Artifact Review documentation says Planning Mode produces implementation plans and supports a Request Review policy that pauses before proposed changes proceed. Use that policy for each worktree.
At the plan gate, check:
- Does the hypothesis match the assigned failure path?
- Are production files or unrelated tests outside scope?
- Will the command touch a shared service or persistent test account?
- Does the plan include a test that fails before the fix and passes afterward?
- Are rollback and cleanup steps explicit?
Reject plans that weaken assertions, add arbitrary retries, skip failing cases, or replace meaningful behavior checks with mocks.
Validate each worktree independently
After approving a narrow change, run the focused test twice in that worktree. Then run the nearest deterministic regression group. Capture the branch name, worktree path, baseline commit, changed files, command, exit code, test count, duration, logs, screenshots where relevant, and final diff.
Confirm that the active checkout remains unchanged. Compare file hashes outside the worktrees and check repository status before and after all three runs. A clean main checkout is part of the acceptance criteria, not merely a convenience.
Parallel-worktree QA matrix
| Scenario | Expected result | Evidence |
|---|---|---|
| Three conversations from one baseline | Each gets a separate Git worktree | Paths, branches, baseline hashes |
| Different test files edited | No file-level interference | Scoped diffs and clean main checkout |
| Same file edited in two worktrees | Changes remain separate until human integration | Side-by-side diffs |
| Shared API test account | Runs use unique namespaces or serialize access | Request IDs and cleanup logs |
| Attempted outside-folder write | Denied or explicitly gated | Permission prompt and unchanged marker |
| Non-Git folder in the Project | Team recognizes it remains local, not worktree-isolated | Folder path and mutation check |
| One worktree test fails | Other worktrees remain usable and unchanged | Independent results and status checks |
| Selected fix integrated | Human-reviewed diff passes clean-checkout CI | Review record and final pipeline |
Do not overlook the non-Git folder exception
Antigravity documents an important mixed-project behavior: New Worktree Mode creates worktrees for active Git checkouts, while non-Git local folders remain in their existing locations. If a Project includes an unversioned fixture directory, download cache, or test-results folder, concurrent agents may still share and overwrite it.
Move critical inputs into version control, provide a unique directory per run, or add explicit locking. Test this condition with harmless marker files before relying on parallel execution.
Compare findings before integrating
Place the three evidence packages side by side. Prefer the explanation that reproduces the failure, introduces the smallest behaviorally correct change, preserves assertion strength, and passes the focused plus nearby regression tests. Conflicting results should trigger another controlled experiment, not a vote among agents.
Integrate through your normal Git review process. Rerun tests from a clean checkout after integration because passing inside an individual worktree does not prove that combined changes, environment state, or CI configuration are compatible.
Definition of done
The exercise is complete when every conversation is traceable to the same baseline, each Git worktree contains only its assigned change, the main checkout stays clean, shared external state is isolated or controlled, non-Git folders are accounted for, and the chosen fix passes deterministic CI after human review. The QA engineer remains responsible for defect classification, integration, cleanup, merge, and release approval.