Gemini CLI just got a genuinely big upgrade: it can now act less like a single chatbot in your terminal and more like a small AI team, thanks to a new feature called subagents. Instead of pushing one model to juggle every task, Gemini CLI can spin up specialist agents in the background, each with its own tools, instructions, and context window, and then stitch their work back into a single, clean response for you.

If you are used to working with large codebases or long-running prompts, the pain point is familiar: one long, messy context window where your assistant slowly forgets what matters, tools pile up, and performance gets worse as the session grows. Subagents are Google’s answer to that “context rot.” In this model, the main Gemini CLI agent behaves like an orchestrator: you give it a broad goal, and it quietly delegates distinct subtasks to whichever specialist it thinks is best suited. Those specialists run in isolated context loops with their own system prompts, tool sets, and memory, and then return a summarized or formatted result instead of dumping their entire inner monologue into your main session.

The design is intentionally pragmatic. A subagent can have a very focused persona (“frontend performance cop,” “auth flow investigator,” “docs librarian”) and a narrow set of tools – maybe just file‑reading, grep, and web search – while your primary agent stays responsible for strategy and final answers. That separation is crucial: it keeps your main context lean and cheaper to run, while still letting you offload deep dives that might involve dozens of tool calls or test runs. Google explicitly pitches this as a way to avoid both context pollution and decision fatigue; the main agent focuses on “What’s the right thing to do?” while subagents handle “Do the grunt work and bring me back the gist.”

What really makes this interesting is how easy it is to create your own experts. Gemini CLI defines subagents using plain Markdown files with YAML frontmatter – nothing more exotic than a structured header plus a free-form description of the agent’s persona and guidelines. Drop a file like frontend-specialist.md into ~/.gemini/agents for personal use or into .gemini/agents in a repo to share it with your team, and that agent immediately becomes available to the CLI. Extensions can also bundle subagents by shipping these Markdown definitions in an agents/ directory, which means libraries, frameworks, or internal platforms can deliver opinionated “house experts” along with their tooling.

The example Google shares is a “frontend-specialist” agent that reads a bit like a very demanding senior engineer: it is instructed to care about architecture, Core Web Vitals, accessibility, browser-first design, and maintainability, and to only make strategic suggestions instead of editing code directly. By constraining the tools available – file reading, directory listing, web fetch, and search – this specialist is prevented from touching things it should not, while still being able to analyze your codebase and suggest improvements. Multiply that pattern across security, performance, data engineering, or documentation, and you get a team of reusable, codified review personas that can be version-controlled alongside your app.

On the usage side, Gemini CLI tries to make subagents feel natural rather than like a separate product. The main agent will automatically route certain tasks to built-in subagents when their descriptions match your request – for example, a codebase investigation might go to a codebase_investigator agent, and “How do subagents work?” might get routed to cli_help, which is wired to the Gemini CLI documentation. There is also a generalist subagent that behaves like a copy of the main agent but is optimized for heavy, tool-driven work such as batch refactoring or commands with large output.

When you want explicit control, you can just “@ mention” subagents in your prompt. A line like “@frontend-specialist Can you review our app and flag potential improvements?” tells Gemini to hand off that request to the named expert, run it in its own context, and then report back when it is done. The same pattern works for other built-ins: “@generalist Update the license headers across the whole project” or “@codebase_investigator Map out the authentication flow.” Under the hood, this is still one CLI, but the UX borrows from chat apps and GitHub bots: you call an expert by tagging it, and the orchestrator handles the details.

Parallel execution is where the “team” metaphor really comes alive. Gemini CLI can spin up multiple subagents at once – or multiple instances of the same subagent – and run them in parallel when tasks are independent. If you have five packages that all need a frontend audit, you can literally say, “Run the frontend-specialist on each package in parallel,” and Gemini will dispatch concurrent jobs and unify their results back into your main session. For workflows like multi-file refactors, codebase mapping, or cross-service documentation checks, that parallelism can cut cycle time dramatically compared to serial conversations with a single agent.

There are guardrails, and Google is pretty upfront about them. Parallel subagents that all edit code can easily trip over one another, causing write conflicts or overwrites, especially in large monorepos. Running many agents at once also means many concurrent model calls, so quota and rate limits will be hit faster if you over-parallelize everything. The guidance from both Google’s docs and early community write-ups is to keep parallel runs for read-heavy or analysis-heavy workloads, and to be more conservative when you are letting AI touch the filesystem.

Outside of the orchestrator and routing logic, Gemini CLI gives you some basic ergonomics for managing this growing cast of characters. Commands like /agents (or /agents list) show which agents are configured locally or remotely, and there are controls to reload definitions or enable and disable specific subagents as you tweak your Markdown files. That sounds minor, but as teams start accumulating dozens of bespoke experts – performance reviewers, security checkers, migration assistants – having a central registry in the CLI becomes essential.

Zooming out, this release lands in a broader shift across AI tooling: instead of one general model trying to be everything for everyone, we are seeing multi‑agent patterns become the default for real-world development workflows. Gemini CLI was already positioning itself as an “AI teammate” that can live in your terminal or your GitHub Actions, automating issue triage, reviews, and code modifications. Subagents push that metaphor further by turning the “teammate” into a team: one agent keeps the big picture in mind while specialists do deep, focused work, all wrapped behind a single command-line interface.

For developers, the practical impact will show up in small, everyday moments. Instead of manually walking a model through the same “read these files, understand this architecture, now tell me where auth is fragile” ritual each time, you can create a reusable auth investigator subagent and call it with a quick @-mention. Instead of watching a conversation degrade as the context grows, you let subagents operate in their own windows and only bring back what matters. And when a deadline is looming, you can ask Gemini to run several of those experts at once and pull their findings together while you focus on decisions, not setup.

This is still early – the subagent docs only went live in mid-April 2026, and the ecosystem of community-maintained agents is just starting to emerge on GitHub. But the shape of the future is clear: Gemini CLI is not just a single AI assistant in your terminal anymore; it is an orchestration layer for a small fleet of programmable specialists, all driven by simple Markdown and a handful of commands.