Agent Worktrees Turn Parallel Coding Into Isolation Policy

GitHub's 30 July changelog for Copilot in Visual Studio Code added a quiet but important agent operating primitive: Copilot, Claude, and Codex sessions can start in Git worktrees, so each agent session can work in an isolated copy of the repository. The same release cluster improved the Agents window with side-by-side code review, compact diffs, running subagent visibility, pull-request update handling from chat, and multi-chat sessions for exploring peer approaches.

On the same day, Copilot in Visual Studio added a new agent built on the Copilot SDK, built-in .NET and Azure skills that are off by default, selected-code review, and organization-level custom instructions. Also on 30 July, GitHub Models was retired: the playground, catalog, inference API, and BYOK surface are no longer available, with Microsoft Foundry and GitHub Copilot named as the migration paths.

Read separately, those are IDE features and a retired model surface. Read together, they point to a more practical rule for small teams using agents on real web work: parallelism is now easy enough that isolation has to be designed on purpose.

The repeated angle to avoid

The last ten posts here covered stacked pull requests, review-agent context, package-malware lifecycle, inference-region routing, long-running agent checkpoints, overlapping work taxonomies, edge-controlled uploads, agent work intake, spend-capable agents, and model routing. Older related posts covered pull-request dashboards, review environments, runtime credentials, prompt-injection triage, AI coding telemetry, feature-flag diffs, and audit trails.

The weak version of this article would repeat the old X needs Y formula: coding agents need isolation. That is true but too generic. The sharper thesis is that worktrees, multi-chat sessions, built-in skills, organization instructions, and model-surface retirements make isolation a coordination policy. A team has to decide which experiments can run in parallel, which context follows them, which evidence is comparable, and when one lane becomes the merge candidate.

Worktrees change what "safe to try" means

A Git worktree gives one repository multiple checked-out working directories. That matters for agents because concurrency is no longer only a human habit. A developer can ask one session to refactor a quote form, another to explore a new analytics schema, and a third to investigate a failed test. If those sessions share one working directory, they collide through files, terminal state, generated artifacts, and partially applied assumptions.

Worktree-backed sessions reduce that collision. Each lane can have its own branch, diffs, tests, logs, and abandoned dead ends. For practical web teams, that changes the cost curve of experimentation:

Parallel lane	Useful for	Isolation risk to control
Bug investigation	Reproducing a checkout, booking, or CRM failure without committing to a fix	Agent invents a broad refactor instead of a narrow diagnosis
Design alternative	Comparing two form flows, product-page layouts, or schema migrations	Evidence is not comparable because each lane changes different assumptions
Dependency update	Testing package, framework, or SDK upgrades	Lockfile and generated files drift across lanes
CI repair	Fixing a failed check while feature work continues	The repair branch quietly includes unrelated product changes
Cleanup	Removing old flags, events, redirects, or wrappers	Cleanup becomes entangled with a customer-visible change

The mechanism is simple: isolation makes parallel work cheaper, but it also creates more candidate histories. Without a policy, the team can end up with three plausible branches and no clear reason to trust one.

Multi-chat needs a comparison contract

Multi-chat sessions are useful because a team can fork an idea without repeating context. That is excellent for exploration. It is also a source of decision noise.

If one peer chat tries a minimal fix, another proposes a structural refactor, and a third changes the test harness, the operator needs a comparison contract before accepting any result. The question is not "which answer sounded best?" It is:

1. Did each lane start from the same base commit?
2. Which files and business surfaces was each lane allowed to touch?
3. Which tests, previews, screenshots, or fixture comparisons did each lane produce?
4. Which risks did each lane leave unresolved?
5. Which lane is easiest to roll back if the change reaches production and fails?

This is especially important for small ecommerce and local-service funnels. A clever agent may improve the local code shape while changing lead attribution, payment copy, booking validation, canonical URLs, structured data, or email routing. Parallel chats make it easier to find a good answer, but they do not automatically preserve the business contract.

Skills and instructions should not leak across lanes

The Visual Studio update matters because built-in .NET and Azure skills are available but off by default, and organization-level custom instructions can apply across repositories. Both are useful. Both can also change an agent lane's behaviour without appearing as a normal source-code diff.

Treat skills and instructions like part of the workspace configuration. A lane using Azure deployment knowledge should say so. A lane applying organization-wide review preferences should expose them in the agent transcript or pull request body. A selected-code review should identify the chosen snippet and the rule set it applied, rather than looking like generic advice.

A practical rule:

If two agent lanes are being compared, record the model, skills, custom instructions, tools, base commit, and branch for both lanes before choosing a winner.

That may sound bureaucratic, but it prevents a common failure mode: the team chooses the lane with the most polished explanation, not the lane with the strongest evidence.

Model retirement is a reminder to avoid hidden platform dependencies

GitHub Models retiring on 30 July is not just a migration notice for teams that used that API. It is a reminder that agent workflows are built on vendor surfaces that can move, consolidate, or disappear. A worktree can isolate files, but it cannot by itself isolate a workflow from model availability, catalog changes, BYOK assumptions, or prompt-evaluation drift.

For small teams, the implementation consequence is straightforward. Keep model access behind a small internal route or configuration layer when the workflow matters. Record the selected model surface in the run receipt. Test critical agent flows after a platform change, not only after code changes. If an agent lane depends on a model or skill that is being retired or moved, treat that as a reason to rerun the comparison rather than merge stale evidence.

This connects to the recent model-routing and inference-region posts without repeating them. The new point is narrower: workspace isolation and model-surface stability have to meet at the evidence layer. A branch produced by an agent is not self-explaining unless the team can also explain the runtime that produced it.

An isolation policy for agent lanes

Use this lightweight policy before letting multiple agents or chats work on the same repository.

agent_lane_policy:
  base:
    commit: required
    repository: required
    business_surface: checkout | booking | lead_form | content | internal_tool
  lanes:
    - lane_id: required
      branch: agent/<task>-<approach>
      worktree_path: .worktrees/<lane_id>
      task_class: investigation | design_alternative | change_proposal | ci_repair
      allowed_files:
        - src/checkout/**
        - tests/checkout/**
      forbidden_without_new_approval:
        - payment_provider_config
        - production_deploy
        - customer_data_write
        - secrets_or_auth
      runtime_context:
        model_surface: copilot | foundry | other_gateway
        model_name: recorded_at_run_time
        enabled_skills:
          - recorded_or_none
        custom_instructions: org | repo | lane_specific | none
        tools:
          - read_only_docs
          - local_tests
      required_evidence:
        - git_diff_summary
        - tests_run
        - preview_or_screenshot_if_user_facing
        - unresolved_risks
      merge_rule: only_one_lane_merges_without_rebase_and_retest

The important field is merge_rule. Parallel lanes are allowed to be messy while they are experiments. The merge candidate should become boring: one branch, one diff, one evidence bundle, one reviewer path, and a retest after rebasing onto current main.

Failure modes to design around

• Cross-lane contamination. An agent copies a useful patch from one worktree into another without carrying over the test or context that justified it.
• Evidence mismatch. One lane reports unit tests, another reports a browser preview, and a third reports only a convincing explanation. Those are not equivalent proofs.
• Instruction drift. Organization instructions, built-in skills, or repository guidance change while a long-running lane is still being evaluated.
• Model drift. A model surface retires, is renamed, changes availability, or routes through a different provider before the team reruns verification.
• Review compression. The IDE makes it easy to review diffs beside chat, but the reviewer accepts a set of changes without checking the business surface affected by each lane.
• Abandoned worktrees. Old branches keep stale secrets in logs, generated artifacts, or half-finished changes that future agents rediscover.

What operators should do differently this week

Start small. Pick one repository where agents are already useful but risky: a storefront, booking funnel, lead form, analytics pipeline, or internal admin tool. Add a lane policy to the issue template or pull-request template. Require each agent run to name its base commit, branch, worktree, model surface, enabled skills, and required evidence.

Then change the review habit. Do not ask, "Which agent gave the best answer?" Ask, "Which isolated lane produced the smallest trustworthy diff against the business contract?" That question turns agent concurrency from a novelty into a repeatable engineering practice.