How I Stopped Losing Track of Which Agent Owns Which Task
Two agents in one workspace is annoying. Three agents in one workspace is when you stop knowing which agent is responsible for which PR. That is the moment ownership breaks.
Where ownership actually fails
You think ownership breaks at the file level. It does not. It breaks at the question level.
When agent A and agent B share a workspace, both write commits, both push branches, both touch files. When something goes wrong, you ask: which agent introduced this regression? In a shared workspace, the answer requires archaeology. You read git blame, you read the diff, you read the commit messages. By the time you find the answer, you have spent more time on attribution than on the fix.
The third agent multiplies this. With three agents in one workspace, every regression has three suspects. You stop reviewing and start investigating.
The mapping that fixed it
One task. One branch. One worktree. One agent. No exceptions.
task: DEV-23
branch: feature/dev-23-epic-add-nestjs-api
worktree: ../blog-devigner-worktrees/feature/dev-23-epic-...
workspace: herdr workspace "dev-23"
agent: claude (autonomous mode)When something breaks, the blame chain is short. The task name tells me the branch. The branch tells me the worktree. The worktree tells me the workspace. The workspace tells me the agent. Five hops, all named, all queryable.
Why this is harder than it sounds
The temptation is to share. "This task is small, I will just do it in the main workspace." Every time I have done that, the small task has bled into the next task, and I have lost the boundary.
The discipline is to spawn a worktree even for a one-line fix. The worktree costs maybe ten seconds to create. The cost of not creating it is paid later, when you cannot isolate the change for review.
What one-to-one mapping does not solve
One agent per worktree does not mean the agents are independent. Agent A can be changing a schema that agent B depends on. Both worktrees build clean in isolation. The PR from agent A merges first. The PR from agent B breaks CI on merge, because the schema it was built against no longer exists.
One-to-one mapping solves attribution. It does not solve coordination.
Check yours
List your last five merged PRs. For each, name the agent that produced it in one sentence. If any row is blank, your agents are sharing a workspace they should not be sharing.
Recommended for you
- CollaborationClaude CodeFigma
Cutting Designer-Engineer Handoff From Two Weeks to Two Hours
The bottleneck is not engineering speed. It is the loop between intent and working interface. Claude Design compresses that loop, but only if you use it the way that actually pays off.
- CollaborationClaude CodeAmp
Why I Stopped Running Parallel Agents in the Same Repo
Three agents in one workspace collide on branches, stash each other's state, and inherit leftover files. Sibling worktrees plus a fresh base branch fix all three. Here is the setup.
- CollaborationHerdrClaude Code
I Tried Running Four Agents in Parallel. Twenty Minutes of Silence Is Where It Broke.
Three agents pushed branches on schedule. The fourth stalled on a quota ceiling and I did not notice for twenty minutes. The fix was not better agents. It was inspectable ones.
- CollaborationHerdrClaude Code
Why Your Coding Agent Terminal Becomes Unreadable Past Three Panes
Two agents fit on one screen. Three forces you to switch. Four means you stop reading the output. The terminal is not the right unit for parallel agents.
Enjoyed this article?
Subscribe for new articles. No spam. Unsubscribe anytime.
By subscribing you agree to receive the newsletter. See the Privacy page.