The first generation of AI dev CLIs gave you a chat loop and tool-use. The second generation is consolidating around a specific next primitive: the subagent. Claude Code shipped its Agent tool earlier this year with markdown-plus-YAML configs, explicit delegation via tool-calling syntax, parallel invocation, and isolated contexts. Google's Gemini CLI has now shipped essentially the same primitive. InfoQ has the writeup, and the shape is close enough that Claude Code users will recognize it at a glance.
Subagents in Gemini CLI are defined in markdown files with YAML frontmatter, specifying roles, tools, and behavioral guidelines. That matches the pattern Claude Code users already use under `.claude/agents/`. Delegation is explicit: users assign tasks to specific agents through prompt syntax, mirroring how Claude Code invokes the Agent tool. Parallel execution is supported. Google's examples include analyzing different parts of a codebase or running multiple research tasks at once, and InfoQ notes the obvious risk: conflicting code changes and increased usage limits from concurrent requests. Each subagent runs in an isolated environment and returns a summarized result to the main session, which is the same architecture Claude Code uses to keep the parent context lean. Gemini CLI ships three built-in subagents out of the box: a general-purpose assistant, a CLI helper, and a codebase investigation agent.
This isn't coincidental convergence — it's the shape the problem forces on you. Once you've built agentic CLI sessions that need to do long-running research, code investigation, or bulk file modification, you hit two constraints fast: parent context budget and parallelism. Markdown-plus-YAML configs handle the "how should this agent behave" axis. Isolated environments with summarized returns handle the context-budget axis. Explicit delegation via prompt syntax keeps the programming model simple for CLI users who don't want a full orchestration framework. Gemini CLI landing this primitive means the pattern is now the industry standard for agentic dev tools, not a Claude Code idiosyncrasy.
If you're building agent tooling on top of either CLI, the practical implication is that your subagent configs can be written once and nearly-reused across both. The schema differences are tractable; the mental model is identical. Worth noting that both camps warn about parallel subagents producing conflicting edits, which is a solved problem in theory (version control, check-before-write, merge) but an unsolved problem in UX. Whoever cracks the "spawn five subagents editing the same repo and merge cleanly" flow first will have a real differentiator. Until then, the convergent primitive is here, and your agent playbook can be written against it regardless of which CLI your team uses.