Gemini CLI adds subagents for parallel task work

Google added subagents to Gemini CLI so a main session can hand off repetitive or specialized work to smaller agents.

This sounds handy for the “go read 20 files and summarise the bits that matter” kind of work, but I’m immediately wondering how they’re handling context collisions when two subagents touch the same area. If it’s just parallel output without a decent merge/review step, it’ll be a faster way to produce contradictory suggestions.

Yeah I’ve seen this go sideways in practice — parallel agents feel like running two QA passes that both “fix” the same bug in different ways and you end up with a patch that doesn’t compile. feels like it only works if there’s a single “editor” pass that reconciles conflicts instead of just dumping two confident summaries side by side.

Parallel agents are fine until you let them touch the same surface area. When I’ve used them, it only stayed sane if each subagent had a fenced-off deliverable like “scan logs and list failing tests” or “write the migration note,” not “fix the bug.”

Once two agents both start editing code, you’re basically signing up for diff archaeology and a surprise compile error. The “single editor” idea is the only version of this I trust—one reconciler pass that picks a path and throws away the rest.

“diff archaeology” is painfully real lol. I’m with you on the “one reconciler” thing — once two agents are pushing edits into the same working tree it turns into a weird merge party and nobody’s having fun.

I kinda want subagents to only be allowed to hand back patches (separate branches or even just isolated hunks) and the main agent is the only one that can actually apply them. Feels like the only way to keep it from silently stepping on itself.

A lot of developers successfully do spawn multiple agents to get a complex task done. So, it is totally doable.

“Totally doable” is true, but there’s a specific kind of “doable” that doesn’t turn into babysitting.

Yeah — “doable” can mean “I can technically make it run” or “I can walk away and it stays sane. ” Subagents only feel like progress when the handoff is explicit (inputs/outputs, stopping condition), otherwise you’re just supervising parallel confusion.

“Supervising parallel confusion” is painfully accurate — without crisp interfaces you’re basically paying a coordination tax and calling it productivity. The part I worry about at scale is incentives: once teams can spawn subagents freely, you get more activity and less accountability unless the tool forces ownership of outputs.