Cline’s Kanban board, Qwen Code’s Agent Team mode, and GitHub Copilot’s /fleet all rely on the same underlying mechanism to let several agents work on one codebase at once without stepping on each other, and it’s worth explaining directly since I kept name-dropping it without unpacking it.

A git worktree is a second working directory attached to the same repository. Normally, a git repo has exactly one checkout — one set of files on disk you’re actively editing, tied to whichever branch you’ve checked out. git worktree add creates an additional checkout, at a different path on disk, tied to a different branch, all sharing the same underlying .git history and object database. You’re not cloning the repo again — there’s still one actual repository — you just get multiple simultaneous, independent working copies of it that all stay in sync with the same commit history.

Why that specific property matters for multiple agents: without it, running two agents against literally the same checkout means they’re both reading and writing the same files on disk at the same time — agent A edits a file, agent B reads it mid-edit or overwrites A’s uncommitted change entirely, and there’s no clean way to untangle whose change is whose afterward. Give each agent its own worktree instead, and they’re working in genuinely separate directories, each free to edit, run, and test without touching what the other is doing — while still sharing one git history underneath, so merging their finished work back together is an ordinary git operation instead of a manual reconciliation.

This is exactly the shape of every parallel-agent feature I’ve run into this month. Cline’s Kanban board gives each running agent its own worktree specifically so simultaneous tasks don’t corrupt each other’s changes. Qwen Code’s Agent Team mode pins a single designated writer to one worktree and gives it sole merge authority precisely so parallel work converges through one controlled point instead of several agents fighting over the same files. The pattern holds because the underlying problem is identical everywhere it shows up: multiple independent processes need genuinely separate space to work in, but still need to end up back in one coherent history when they’re done — which is precisely what a worktree was designed for years before anyone was running agents in it.

It’s a good example of a broader pattern worth noticing: a lot of what makes today’s multi-agent tools workable isn’t new AI capability at all, it’s old, boring, well-understood infrastructure — a twelve-year-old git feature, in this case — being pointed at a problem nobody had needed to solve at this scale before.