Running five coding agents at once in the GitHub Copilot app

At Microsoft Build this week, GitHub announced a standalone Copilot desktop app, now in technical preview for all existing Copilot Pro, Pro+, Business and Enterprise subscribers. Rather than another editor plugin, it is a control centre for running multiple AI coding agents in parallel, with each session isolated in its own git worktree and a unified "My Work" view spanning sessions, issues, pull requests and background automations. For Swedish and EU teams already paying for Copilot Business or Enterprise, the significant part is procurement-shaped: multi-agent development just arrived inside a licence you already hold. The hard questions are no longer about buying tools. They are about worktree hygiene and supervision cadence, and about what happens to your code review process when one developer can produce five pull requests before lunch.

What GitHub actually shipped

The Copilot app is a desktop application for Windows 11 (including Arm), macOS and Linux. GitHub describes it as "the agent-native desktop experience built on GitHub", and the design centre of gravity is managing several agents at once rather than chatting with one. The pieces that matter:

My Work view. A single dashboard showing everything in motion across your connected repositories: active agent sessions, assigned issues, open pull requests and background automations. This replaces the pile of chat windows that multi-agent work has meant until now.
Worktree-isolated sessions. Every session runs in its own git worktree, a real, isolated copy of your branch. The app creates and manages these automatically, so parallel agents cannot step on each other's files.
Canvases. Bidirectional work surfaces showing plans, pull requests, terminals and deployments. You can edit, reorder, approve or redirect the agent's work rather than just watching a scrolling transcript.
Sandboxing. Local sandboxes constrain filesystem and network access on your machine; cloud sandboxes provide ephemeral Linux environments and let you pick a session up from another device.
Agent Merge. Configurable automation that shepherds a pull request through CI checks and review requirements once you approve the direction.
Remote control. Sessions can be monitored and steered from a phone via github.com or GitHub Mobile.

Alongside the app, GitHub moved its Copilot SDK to general availability across Node.js/TypeScript, Python, Go, .NET, Rust and Java, added a medium tier for code review that routes complex pull requests to higher-reasoning models, and introduced a Copilot Max tier for heavy agent users. The technical preview initially sat behind a waitlist; as of this week it is open to all existing paid subscribers, with free-tier access promised later.

Why worktrees are the right isolation primitive

If you have run more than one coding agent against the same checkout, you already know why this matters. Two agents editing the same working directory produce corrupted state: one runs the test suite while the other is mid-refactor, and staged changes bleed between tasks. You spend the time you saved untangling the mess. The common workarounds, a full repository clone per agent or a container per agent, work but are heavy. Clones duplicate the entire object database; containers add image-build and volume-mount ceremony to every task.

Git worktrees are the lightweight middle path, and they have been in git since version 2.5. A worktree is an additional working directory attached to the same repository: it shares the object database and refs, but checks out its own branch with a separate index and separate untracked files. What the Copilot app automates is essentially this:

# One repo, three parallel agent workspaces
git worktree add ../myrepo-agent-auth  -b agent/fix-auth-timeout
git worktree add ../myrepo-agent-docs  -b agent/api-docs-update
git worktree add ../myrepo-agent-perf  -b agent/query-caching

git worktree list
# /repos/myrepo             abc1234 [main]
# /repos/myrepo-agent-auth  abc1234 [agent/fix-auth-timeout]
# /repos/myrepo-agent-docs  abc1234 [agent/api-docs-update]
# /repos/myrepo-agent-perf  abc1234 [agent/query-caching]

Each agent gets a genuine filesystem view of the code, can run builds and tests without contention, and produces a clean branch for a pull request. Because worktrees share objects, disk cost is roughly the size of a checkout rather than a clone, a difference you notice on the multi-gigabyte monorepos common in enterprise .NET estates.

Worktree hygiene rules worth adopting now

The app manages worktrees for you, but hygiene still matters, especially if you also run agents from the CLI or CI. Rules we would put in a team playbook:

One task, one worktree, one branch. Never let an agent reuse a worktree for a second unrelated task; stale build artefacts and leftover config changes contaminate results.
Prune aggressively. Abandoned worktrees accumulate. Schedule a periodic cleanup so sessions that went nowhere do not linger with uncommitted changes nobody remembers.
Watch shared local state. Worktrees isolate files, not databases, local containers, dev ports or global package caches. Two agents both starting a local SQL Server container or binding port 5000 will still collide. Push integration-level work into the cloud sandboxes instead.
Keep secrets out of the tree. Every worktree is another full copy of anything committed or dropped into the repo directory. If your .env discipline is weak, five worktrees means five copies of the problem, each visible to an agent.

A practical operating model for five parallel agents

The genuinely new skill here is portfolio management, not prompting. Running one agent is pair programming; running five is running a small team, and the same management failure modes apply: unclear task definitions, no acceptance criteria, and a supervisor who context-switches until nothing gets reviewed properly.

What to parallelise, and what not to

Parallel agents pay off on independent, bounded tasks with a verifiable outcome. They fail when tasks are entangled or open-ended. Good candidates for parallel sessions:

Mechanical migrations sliced by module: nullable annotations, logging framework swaps, target-framework bumps.
Test-coverage debt: one agent per untested project, with a coverage threshold as the acceptance criterion.
Independent bug tickets that touch disjoint areas of the codebase.
Documentation and API reference updates alongside the feature work they describe.
Spikes: three agents attempting three different approaches to the same problem, and you keep the best.

Keep sequential (one agent, your full attention): anything touching authentication or authorisation logic, cross-cutting refactors where later steps depend on earlier decisions, schema migrations, and work in areas with weak test coverage. In those areas review is your only safety net, and review is exactly the resource parallelism strains.

Decision framework: should this task go to a parallel agent session?

1. Verifiable? Is there an automated check (tests, build, linter, coverage gate) that meaningfully validates the result? No → do it yourself or write the check first.
2. Independent? Can it merge in any order relative to the other in-flight sessions without semantic conflicts? No → sequence it.
3. Bounded? Can you write the acceptance criteria in three sentences? No → it is a design task, not an agent task.
4. Low blast radius? If a subtle mistake shipped, would it be embarrassing or expensive? Expensive → sequential, with your best reviewer.
5. Reviewable in under 30 minutes? If the expected diff exceeds what one person can properly review in half an hour, split the task before starting the session.

Supervision cadence

The My Work view and canvases exist because the alternative, polling five chat transcripts, does not scale. A cadence that works in practice: write acceptance criteria into the task before launching the session. Check each canvas at natural breakpoints (plan produced, first commit, tests green) rather than continuously. Intervene early on the plan, not late on the diff. Redirecting an agent after it has produced 800 lines is far more expensive than correcting its three-line plan. The mobile steering option is genuinely useful for the plan-approval step, and a poor place to do anything more substantive.

Keeping code review from becoming the bottleneck

Here is the uncomfortable arithmetic. If agents triple the rate at which pull requests are opened, and your review capacity stays flat, one of three things happens: a growing PR queue, rubber-stamped approvals, or reviewers becoming the constraint on the whole system. The first kills the throughput you bought the tooling for; the second quietly converts agent mistakes into production incidents. Neither is acceptable, so review capacity has to be engineered deliberately.

GitHub's own answer is layered automation: Copilot code review as a first pass (with the new medium tier routing complex PRs to higher-reasoning models, plus skills such as a security review pass), and Agent Merge to shepherd approved PRs through CI and merge mechanics. Used well, this reserves human attention for the judgements machines are worst at. Used lazily, it is agents reviewing agents with nobody accountable. Our recommended layering:

Layer 0: machine gates. Build, tests, static analysis and coverage thresholds as required checks. Non-negotiable before any human looks at agent output. If your branch protection rules are loose today, fix that before scaling agent sessions.
Layer 1: AI first pass. Automated review to catch mechanical issues and produce a summary, so the human reviewer starts oriented instead of cold.
Layer 2: tiered human review. Not every agent PR deserves the same scrutiny. A docs update that passed layers 0–1 can take a skim; a change inside payment logic gets a full review from a senior engineer regardless of how clean it looks. Write the tiers down: path-based rules in CODEOWNERS are a good enforcement point.
Layer 3: accountability. The person who launched the session owns the PR. "The agent wrote it" is never an answer in a post-incident review, and making that explicit up front changes how carefully people scope tasks.

Two further habits help more than any tooling. First, enforce small diffs: the 30-minute reviewability test in the framework above is really a review-capacity budget applied at task-creation time. Second, schedule review as first-class work. If a developer runs five sessions a day, roughly a third of their day is now review and steering; pretending otherwise just moves the queue somewhere less visible.

The Swedish and EU angle

For most Swedish enterprises the procurement story is the headline: the app is a technical preview inside existing Copilot Business and Enterprise subscriptions, not a new product requiring a new supplier assessment. If Copilot has already been through your leverantörsbedömning and security review, and the works council has had its conversation, the marginal governance work is a delta review, not a fresh procurement cycle. That said, three points deserve attention before broad rollout:

Cloud sandboxes change the data-flow picture. Local worktrees keep code on the developer's machine; the ephemeral cloud Linux environments do not. If your existing Copilot DPIA was written around code-completion telemetry, it likely does not cover full repository checkouts executing in vendor-managed cloud sandboxes. Establish where those environments run and update the assessment before enabling them for repositories containing personal data or material under strict confidentiality clauses.
Technical preview means preview terms. Preview features commonly sit outside the contractual commitments that apply to GA services. For regulated workloads (banking, health, public sector), treat the preview as an evaluation on non-sensitive repositories, and let the policy decision wait for GA terms.
Agent supervision is becoming a governance topic, not just an engineering one. Under the EU AI Act's general-purpose AI provisions and under plain-vanilla operational risk frameworks alike, "who reviewed this change and on what basis" is a question you want crisp answers to. The layered review model above doubles as the documentation trail: the required checks and review tiers, with named ownership per PR, are exactly the evidence an auditor will ask for.

For Azure-first teams there is a small bonus in the announcement: Copilot code review gained native Azure DevOps support, so organisations still running Azure Repos are no longer excluded from the AI-review layer while they plan any migration to GitHub.

Getting started this month

A sensible four-week evaluation for a team already on Copilot Business: week one, install the app for two or three senior engineers and run single sessions on real but low-risk tickets to learn the canvas workflow. Week two, go parallel, at two to three sessions per person, on a test-coverage or migration backlog with clear machine-verifiable outcomes. Week three, pressure-test review: measure PR queue depth and time-to-merge, and tune the layered review model until they hold steady. Week four, write the playbook (task selection criteria, worktree hygiene, review tiers, sandbox policy) and decide whether to widen the rollout. Treat review capacity and supervision as design constraints from day one; launching more sessions without them only relocates the bottleneck.