Back to Garden

Parallel Agents

Parallel Agents

What?

Yea, that's right

Why have one agent when you can have multiple?

I've been meaning to get into that world of spinning up multiple instances and running tasks in parallel and finally got into that for the past few days. One of the earliest instances of "parallel" work I did like many others was having multiple different agents/software IDE's work on different features on the same repo. For example, having codex and antigravity work on the same repo, different features

Result

The initial runs were chaotic. The agents frequently overwrote each other's files, caused build errors, and left many files corrupted or straying from their intended functionality.

Spiderman
How files would destroy each other with multiple agents

That's where worktrees come in

Worktrees let you spin up a separate working folder for each feature, like having two folders, one for codex and one for antigravity, so agents don’t trip over each other’s changes, or even having multiple agents from the same agent execution (codex, antigravity, claude code, your choice!)

There's always a catch

Yea, the catch is that the entire philosophy of parallel agents, is having them work on features such that they don't overlap in task and execution. For example, you ideally shouldn't have a task for agent A be "Add user authentication" and task for agent B be "Add a profile page", at the time of merging, there will more than likely be merge conflicts. This of course comes with the precedent that worktrees allow for isolated workflows, edits, dependencies to each agent allocated to that worktree, but alas at the time of merge, it is very possible conflicts may arise, where you will have to make your choices.

Aside from that, you're definetely gonna need a high tier subscription from your agent provider of choosing (Claude Max, Cursor Pro+, etc.) if you want to get serious deep work done.

The real fix

The true skill is in dividing the work so each agent tackles different files (or at least, different lines!). If you can’t guarantee that, you’re back to two main strategies:

Option 1: Serialize the dependent stuff.
If two agents need to edit the same files, just run them one after the other. Literally! Just stick to your default nature of "vibe coding" prompting and editing, prompting and editing, repeat!

Option 2: Embrace the conflict, then review.
Sometimes, you want multiple ideas on the same code, so you let the agents overlap intentionally. Run them in parallel, then bring their branches together and manually pick the best parts.

Bottom line: You don't need to do parallel agents if you need to, they come with their own side of overhead and confusion, but they are a gateway to make agents progress together without stomping mid way. The smoother you split up the tasks, the less pain at merge time.