Why This Matters
In Chapter 7, you gave every task a worktree. But not every task needs that overhead. Fixing a typo in a README does not need an isolated branch, a commit, and a merge. Conversely, running user-submitted code needs more isolation than a worktree provides — you want a sandboxed container where a rogue while(true) cannot freeze your machine.
Production agents do not use one execution mode for everything. They choose based on the task: fast and direct for simple edits, isolated for feature work, fully sandboxed for untrusted execution. This is the execution lane concept — three modes with different tradeoffs, selected dynamically.
What You Will Build
An ExecutionLaneRunner that evaluates a task and selects the appropriate execution mode. You will implement three lanes: local (fast, no isolation), worktree (file-level isolation from Chapter 7), and cloud-like (simulated full isolation with timeouts and resource limits).
Story Mode for this chapter is coming soon
We are crafting a fun, code-free explanation with metaphors and interactive mini-games. In the meantime, switch to Builder Mode to start learning.
What's Next
You have completed Part II of OrchestCode. Your agent now has a full execution infrastructure: safe file editing with patches (Chapter 5), policy-based approval gates (Chapter 6), git worktree isolation (Chapter 7), and dynamic execution lane selection (Chapter 8).
Together, these four chapters transform the raw agent loop from Part I into a system that can safely execute complex coding tasks. The agent chooses how to run each task, isolates its work, applies changes surgically, and asks for permission before doing anything dangerous.
In Part III, you will scale this to multiple agents working together: delegation, coordination, and the orchestration patterns that make systems like Codex work at scale.