Multi-Agent Workflows

Table of Contents

1. Why run more than one agent
2. Give each agent its own view: --clone
3. Watching them all at once
4. Keeping agents from colliding
5. Where this course ends and governance begins
6. Beginner Pitfalls

1. Why run more than one agent

Every sandbox in this course so far ran one agent (or one shell) at a time. Once an agent is just another process you can start and isolate cheaply, running several at once stops being exotic: one agent fixing a bug while another writes tests for a different module, one agent per pull request you're reviewing, or the same task handed to two different agents so you can compare their approaches. sbx doesn't need a different mode for this — it's the same commands from Parts 2–9, just run more than once.

2. Give each agent its own view: --clone

The default workspace mount is shared and read-write: an agent edits your actual working tree, and you see its changes as an ordinary Git diff. That's right for one agent. For two or more agents against the same repository at the same time, sharing one working tree means their edits interleave and Git status becomes unreadable.

--clone fixes this by giving the agent its own private, in-sandbox Git clone instead of a mount:

cd ~/some-real-project
sbx run --clone --name agent-fix-bug claude
sbx run --clone --name agent-write-tests codex

Each sandbox now has its own copy of the repository, on its own branch of work, isolated from the other. Nothing reaches your actual working tree until you deliberately pull an agent's branch out and review it — the same "review before it touches anything real" guarantee --clone gives you for a single agent in Part 9, just applied to several at once.

3. Watching them all at once

sbx ls

SANDBOX            AGENT   STATUS    PORTS   WORKSPACE
agent-fix-bug       claude  running           ~/some-real-project (clone)
agent-write-tests   codex   running           ~/some-real-project (clone)

Reach into any one of them without attaching to its interactive session — useful for checking progress or grabbing a file mid-run:

sbx exec agent-fix-bug -- git log --oneline -5
sbx exec agent-write-tests -- cat package.json

sbx with no arguments still opens the interactive dashboard from Part 2 — with several sandboxes running, this is the fastest way to jump between them without remembering every --name you used.

4. Keeping agents from colliding

A few habits carry the isolation guarantees from earlier parts into a multi-agent setup:

• Name deliberately. --name isn't just cosmetic once you have three sandboxes running — it's how you tell sbx ls, sbx exec, and sbx stop/sbx rm apart.
• Clone when workspaces overlap, mount when they don't. Two agents working on genuinely separate projects can both use a plain shared mount safely; two agents working on the same project should both use --clone.
• Scope credentials per sandbox, not globally, when the agents don't need the same access. A secret provisioned with sbx env (see Part 11) can be scoped with --sandbox <name> instead of applying everywhere.
• Publish ports deliberately. If two agents both run a dev server on port 3000 inside their own sandboxes, that's fine — sbx ports lets you publish each one to a different host port, since the collision only matters the moment you expose them to your host.

5. Where this course ends and governance begins

Everything from Part 1 through here is one developer's toolkit — you, running sbx on your own machine, deciding what each sandbox can touch. That toolkit stops being enough the moment it's not just you: a team sharing conventions across everyone's sandboxes, or an organization that needs a guarantee no developer's local sbx policy can override.

That's organization governance — configured centrally (in Docker Home or via a Governance API), not on any individual's machine. It can control the same three things you've been controlling locally all course — network access, filesystem/workspace access, and MCP server/tool access — but as a floor everyone's sandboxes sit on top of. The precedence rule is what makes it a floor rather than just a suggestion: once org governance is active, only its own allow rules grant access — a developer's local sbx policy allow rules stop being evaluated — while a developer's local sbx policy deny rules still apply on top. An individual can always make their own sandbox stricter; only the organization can make it looser.

That's genuinely a different scope of problem than this course covers — Parts 1 through 13 are everything one developer needs to use Docker Sandboxes well, alone or alongside a few other agents, without ever touching an admin console.

6. Beginner Pitfalls

• --clone isolates the workspace, not credentials or network policy — two cloned agents still share whatever secrets or network rules you gave their sandboxes individually. Isolating a workspace and isolating access are two separate decisions.
• Running many agents at once is still running many sandboxes at once — each one costs the same memory/CPU as before. sbx ls is worth checking before starting a fourth or fifth sandbox on a laptop.
• Organization governance is not something you can turn on for yourself from a personal machine — it's an org-wide setting an admin configures. If you're evaluating it, that conversation starts in Docker Home, not in sbx policy.