Agent Manager: Run Multiple AI Agents in Parallel Without the Chaos
Published on 09.06.2026
Agent Manager: Run Multiple AI Agents in Parallel Without the Chaos
TLDR: Kilo Code's Agent Manager lets you run multiple AI agents simultaneously by giving each one its own git worktree, so they never step on each other's files. You get a kanban-style board to track progress, a built-in diff review before anything gets committed, and the ability to run the same prompt against different models side by side to compare results.
Summary:
Here's a scenario I've lived through too many times. You've got six things burning a hole in your backlog, so you open six AI agent tabs and let them all loose at once. Within an hour you've got agents overwriting each other's files, merge conflicts that look like abstract art, and context from the "add Stripe billing" task bleeding into the "fix flaky CI" work. You end up spending more time untangling git state than actually shipping anything.
Kilo Code's Agent Manager is a direct answer to that specific pain. The core insight is simple and the execution is clean: each agent gets its own git worktree, which means a completely isolated copy of the repo with its own branch in a separate directory on disk. The agent working on authentication refactoring literally cannot touch the files that the documentation agent is reading, because they're in different places. This isn't coordination or locking or anything clever. It's just isolation.
The workspace itself is a kanban-style board with To Do, Doing, and Done columns. You create a new worktree, write a prompt like "Implement Stripe checkout with webhook verification," pick your model and mode, and hit Create. Kilo initializes the worktree, starts the agent, and the card on the board shows you live status as it reads the codebase, plans, and writes files. You can watch it or walk away and check back later. I appreciate that it doesn't demand your attention.
One feature I find genuinely interesting is the ability to run the same prompt against multiple models simultaneously. Send "Implement Stripe checkout" to Claude Sonnet, GPT-5.5, and Claude Opus at the same time. They work independently in separate worktrees. When they're done, you review all three diffs and pick the implementation you prefer. Maybe one has cleaner architecture, another has better error handling, a third handles edge cases you hadn't thought of. This turns model comparison from a theoretical exercise into something you can actually act on.
When an agent finishes, you click "Review Changes" and get a full syntax-highlighted diff showing exactly what changed before anything is committed. When you're satisfied, you can open the worktree directly in VS Code as a normal folder window. IntelliSense, the debugger, the test runner, the terminal, everything works because it genuinely is just a normal VS Code workspace. If an agent hits an error mid-task, you open the built-in terminal (which is already in the right directory) to fix it, and the agent picks back up from where it left off.
Key takeaways:
- Each agent runs in its own git worktree, completely isolated from other agents, preventing file conflicts and context bleed between parallel tasks
- The kanban board (To Do, Doing, Done) gives you a single view across all running agents with live status updates
- You can run the same prompt against multiple models simultaneously and compare their diffs before choosing which implementation to keep
- Finished worktrees open directly as full VS Code windows with all tooling intact, and the built-in terminal drops you into the correct directory for debugging mid-task errors
Why do I care:
From a senior architecture perspective, the worktree-per-agent model is the right abstraction here. Git worktrees are a mature, well-understood feature that most developers already trust, so Kilo isn't introducing a proprietary isolation mechanism that you have to reason about differently. The multi-model comparison workflow is the part I'd actually push teams to use. Running the same task against two or three models and doing a structured diff review before merging is a workflow that could genuinely improve output quality in ways that "just pick a model and trust it" doesn't. The kanban view also makes the organizational overhead of parallel AI work tractable for individual developers, not just teams with dedicated tooling.