Air's task model: every job gets its own sandbox

The first time someone walked me through Air's task model I nodded along and didn't actually get it. Describe a task, an agent runs it, you approve the result. Fine, every agentic tool does some version of that. What I missed is where the work happens.

Each task in Air runs in its own isolated workspace. Not a mental abstraction: a real, separate place. It can be a plain local checkout, a git worktree, a Docker container, or, on the roadmap, a cloud container you never have to provision by hand. The agent makes its edits there, and you review the diff before any of it touches your main working copy.

That sounds like an implementation detail.

It's the whole point.

why the sandbox is the feature

For years my parallel work looked like this: three half-finished ideas stacked on one branch, a stash pile I was quietly afraid of, and the constant small tax of switching context by stashing and popping. Air kills that. Task A refactors a Kotlin repository layer in one worktree while Task B bumps a fragile dependency in another, and neither can touch the other because they're literally in different directories. I can let an agent grind on a slow migration in one workspace and keep hand-editing in a second, and they don't corrupt each other.

The feature is the agent doing the work somewhere it can't wreck mine.

it's the worktree pattern, filed smooth

If you've run Claude Code in git worktrees, this'll feel familiar, because it's the same idea with the rough edges sanded off. I've done the worktree dance by hand for about a year: a script that spins up a worktree per agent, a tmux layout I half-remember, a sticky note on my monitor tracking which agent sits where. Air just does it. The isolation guarantees are the ones I care about whenever I'm sandboxing coding agents: the agent gets a real place to work and a boundary it can't cross without my say-so.

the bottleneck I didn't expect

Here's where I was wrong. I assumed the limit on parallel agents was compute or context, so I bought the biggest machine I could talk myself into (an M2 Ultra Mac Studio) expecting to run five or six tasks at once. I was the bottleneck, not the machine. Three agents finishing around the same time means three diffs to review, and careful review doesn't parallelize. By my third day I had a queue of four finished tasks and a rising dread about merging them in the right order without snapping the build.

The fix was boring and human. I stopped launching tasks I wasn't ready to review, and I got strict about merge order. Two well-scoped tasks I actually read beat six I rubber-stamp.

the catch nobody mentions

Isolation has a cost, and the cost is integration. Two agents editing the same module in separate worktrees can hand you two diffs that both apply cleanly and still conflict in meaning. That's the kind of clash git won't flag for you. Air doesn't solve that; it just makes the situation trivial to create. The merge discipline stays yours, and if anything Air raises the stakes by making parallel work so cheap to start.

I still think it's the cleanest version of this pattern I've used, and it reshaped how I plan a day more than any single feature in the first look did. Start fewer tasks than you can run. Review them like you mean it. The sandbox hands you the freedom to parallelize; it won't do the merging for you.