Google adds subagents to Gemini CLI to handle parallel coding tasks

AI coding agents might be able to take on more complex work, but they still tend to work through tasks one at a time. And that can become a huge bottleneck once tasks start to stack up.

Google is addressing that with a new “subagents” feature in its Gemini CLI, introducing a way to split work across multiple specialised agents within the same environment.

Subagents are defined with their own instructions, tools, and context. The main agent can delegate parts of a task to them, allowing work to be broken down and handled in parallel. Rather than one agent working through everything step by step, tasks can be distributed and executed at the same time.

For example, a developer could tell Gemini CLI that the backend for an analytics API is done and ask it to update the frontend, tests, and documentation, with subagents then spun up for each part of the job — a frontend specialist, a unit test agent, and a docs writer.

Delegating work inside the CLI

The setup is designed to handle tasks that would otherwise overload a single agent session. A developer can create subagents for specific roles — such as code review, testing, or documentation — and call on them when needed.

Each subagent runs with its own context, allowing the main agent to hand off work and receive results without carrying everything in a single thread. That keeps tasks more contained and avoids long chains of instructions building up in one session.

This approach has been present in other tools for some time. Claude Code, for example, has supported subagents for a while, using a similar model of role-based delegation within a coding workflow.

Parallel execution and context separation

A key part of the feature is that subagents can run at the same time, allowing different parts of a task to be processed in parallel.

Each subagent also operates in its own working space, so instructions and outputs remain separate. That reduces the risk of tasks interfering with one another, which can happen in longer, more complex sessions.

Together, this allows larger pieces of work to be broken down and handled without losing track of what each part is doing.

This also extends to running multiple instances of the same subagent at once. A developer can, for example, run a frontend-focused agent across several packages in parallel, with each instance analysing a different part of the codebase at the same time.

It’s worth noting that in Gemini CLI, this coordination happens within a single session, with subagents spun up to handle parts of a task before returning control to the main agent.

Other systems are exploring a more extensive setup. Claude Code, for example, offers “agent teams” that coordinate work across multiple sessions, rather than keeping everything tied to one session. That approach can support longer-running tasks, but adds more overhead in how those agents are defined and managed.

How to use subagents in Gemini CLI

Gemini CLI comes with a set of built-in subagents that can be used straight away, each geared toward a specific type of task. These include a “generalist” agent that can handle a wide range of coding and command-line tasks, a CLI-focused agent that can answer questions about how the tool works, and a codebase-focused agent for exploring architecture, dependencies, and debugging issues.

Developers can also create their own subagents by defining them in a Markdown file with YAML frontmatter, followed by plain-text instructions describing the agent’s role and behaviour. These files can be stored locally or alongside a project to share across a team.

The system will automatically route tasks to these subagents when it decides one is a better fit. That means routine or well-defined work can be handled without needing to specify which agent should take it on.

Developers can also take direct control. By using the @ syntax followed by a subagent’s name, tasks can be explicitly assigned to a specific role — for example, asking a frontend-focused agent to review an interface, or a codebase-focused agent to map out part of a system. Each subagent then handles the task within its own context, separate from the main session.

To see which subagents are available at any point, the CLI provides a simple /agents command, which lists the current set of configured agents.