Isolation for Parallel Execution
Understand why isolation — ephemeral environments, scoped identities, branch-per-task — is the precondition for running agents in parallel without them stepping on each other or on production state.
Isolation for Parallel Execution
Two agents running in parallel without isolation is just two scripts racing each other. The exam expects you to recognise the three primitives that make safe concurrent agent execution possible: ephemeral environments, scoped identities, and branch-per-task working trees.
Why isolation is the precondition for parallelism
Imagine three issues filed at once. If a single agent processes them serially you get correctness but no leverage. If three agents work in parallel inside the same working tree, you get speed and total chaos — every save races every other save, and there's no way to attribute a bad commit to one task.
The GitHub Copilot coding agent solves this with three rules:
- One task, one ephemeral GitHub Actions sandbox. A fresh runner is spun up per task and destroyed when the agent is done.
- One task, one branch, one PR. "Copilot can only work on one branch at a time" and opens "exactly one pull request to address each task" — concurrency comes from running many tasks, not from cramming many edits into one branch.
- A scoped identity per run. Each agent acts under a managed identity scoped to the resources of its task, so the audit log can name the responsible agent.
The three isolation primitives
| Primitive | What it prevents | How Foundry / GitHub provides it | | --- | --- | --- | | Ephemeral environment | Cross-run state leakage, persistent compromise | Ephemeral Actions runners; BYO VNet sessions in VM-isolated sandboxes | | Branch-per-task working tree | Concurrent edit collisions | One Copilot task = one branch = one PR | | Scoped managed identity | Privilege escalation, attribution loss | Dedicated Microsoft Entra identities per agent |
Exam tip: When a question asks "what's the minimum change to safely run N agents in parallel?", check whether the proposed design has all three primitives. If any is missing, the answer is almost always "add the missing primitive", not "add another guardrail on top".
Quick check
Quick check
You want three GitHub Copilot coding agents to address three issues in parallel. What's the correct isolation model?
Where this shows up on the exam
GH-600 questions on multi-agent systems frequently start with a scenario about "two agents that need to…". The first instinct should be: can these tasks be split onto separate branches in separate ephemeral environments? If yes, that's the answer. If no — because they genuinely need shared mutable state — the answer shifts to conflict detection and a coordination strategy (covered in the next topic).
Key terms
- Ephemeral environment
- A short-lived sandbox (VM, container, Actions runner) provisioned for one agent run and destroyed afterwards.
- Branch-per-task
- Each agent works on its own git branch (or worktree) so multiple agents can edit the repo at once without colliding.
- Scoped identity
- A dedicated managed identity (e.g., Microsoft Entra) per agent so its permissions can be limited and its actions audited independently.
- Shared mutable state
- Resources (a file, a database row, a queue) two agents can both write to simultaneously — the primary source of multi-agent conflicts.
Common pitfalls
- Running parallel agents against a single shared working tree — every agent's edits race the others and the last writer silently wins.
- Granting all agents the same broad service principal so you can't tell whose action caused a bad change.
- Assuming containers alone provide isolation while still mounting a shared writable volume.
- Forgetting that the coding agent can only work on one branch at a time per task — parallelism comes from running multiple tasks, each in its own ephemeral env.