When a subagent in Gemini CLI completes a task, it sends back a single consolidated summary — and nothing else. No record of which tools it called. No log of what it saw. Just the output. Google's new subagent architecture, shipped in Gemini CLI v0.38.1 on April 15, solves a real developer problem: the slow drift of context that makes long AI coding sessions exhausting. It also creates a question Google's documentation does not answer: when something goes wrong inside an isolated subagent, who is responsible?
The isolation model is real and well-documented. Each subagent runs in its own separate context window with its own system instructions, toolset, and conversation history. When it finishes, it consolidates into a single summary and returns only that to the main agent. Google's phrase for this is context rot prevention. The phrase Google's docs do not use but should: accountability boundary.
The isolation boundary goes further than context management. According to Gemini CLI's documentation, if a subagent is granted wildcard tool access — the equivalent of root permissions on a system — it still cannot see or invoke other agents. Google's own language: "Subagent tool isolation moves Gemini CLI away from a single global tool registry." That is a structural separation of the tool layer itself, not just a permission setting. No other AI coding CLI has documented an equivalent guarantee.
Cursor and Claude Code have both shipped multi-agent workflows. Neither has published a comparable tool-level isolation boundary in their documentation. For enterprise security teams evaluating AI coding tools for production use, that distinction belongs in the evaluation brief.
The implementation uses Markdown files with YAML frontmatter to define custom subagents — no new syntax, no platform lock-in. Drop a file in ~/.gemini/agents/ and Gemini CLI routes tasks to it by name using the @agent syntax. Three built-in agents ship ready to use: generalist (full tool access), cli_help (Gemini CLI documentation), and codebase_investigator (codebase analysis). The /stats command, also shipped in v0.38.1, breaks down request counts by main agent versus subagent versus utility function — giving developers visibility into where compute is going, which becomes relevant once you start running multiple agents in parallel.
There is a caveat Google does not bury: do not run multiple subagents simultaneously for heavy code editing. "Multiple agents editing code at the same time can lead to conflicts and agents overwriting one another," the release notes state, in the same paragraph that advertises the parallel execution feature. The parallelism is real. The isolation guarantee is real. The combination is not production-ready for concurrent code editing, and Google says so in its own documentation.
What nobody has done is run adversarial tests against this isolation model in a live environment. Google's documentation describes the boundary clearly. Independent security researchers have not yet published their findings either way. That is the precise window for this story: the claims exist, the verification does not, and the architecture is unusual enough that verification matters. Context rot is a genuine developer pain point — watching an AI assistant gradually lose focus over a long session, re-reading the same files, burning tokens on irrelevant context. Google's fix addresses it at the architecture level rather than the surface level. Whether the architecture holds under adversarial pressure is the next question. Google shipped an answer. Nobody has checked their work.
