Google AI Ultra: Turning a Subscription into a Pool of Parallel Agents and Model Consensus

Google AI Ultra can serve as more than access to Gemini: it can anchor multi-agent development. In a setup built around a pool of background workers on Gemini CLI, the main agent handles orchestration and cross-model review of decisions. At the center is the MCP server Agent-Pool-MCP, which distributes tasks, roles and artifacts among the agents.

AI-processed from Habr AI; edited by Hamidun News
Google AI Ultra: Turning a Subscription into a Pool of Parallel Agents and Model Consensus
Source: Habr AI. Collage: Hamidun News.
Listen to article
Article Fact Sheet & Key Figures
ParameterDetails
Primary sourceHabr AI ↗
Editor-in-Chief
Key metric #1the main IDE agent sets tasks and collects results
Key metric #2background workers on Gemini CLI perform analysis, coding and checks
Key metric #3consult_peer provides a second opinion from another model before any code changes

Google AI Ultra can be seen not as an expensive Gemini subscription but as the foundation for your own multi-agent environment. The idea is to spread routine tasks across background workers and use the main agent as an orchestrator and reviewer of decisions.

The subscription as infrastructure

The core argument is simple: Ultra's price looks high, but you can recoup it through how you architect your work rather than through the number of chats. Instead of forcing one model through endless refactoring, the proposal combines Antigravity IDE, Claude as the main agent and Gemini CLI as a nearly unlimited pool of executors. If one model's daily limit runs out, the workflow does not collapse: the orchestrator switches to another model, and background tasks keep running separately.

This approach tackles two problems at once. The first is token cost in classic API scenarios, where every auxiliary agent eats into the budget. The second is the bottleneck of a single IDE session: even if the environment can call subagents, it is hard to manage them, assign roles and build repeatable processes. Here the setup is presented as a move from one smart window to a full team of agents, where some do research, some write code and some review the proposed solution.

How the pool works

For this, the author proposes a custom MCP server, Agent-Pool-MCP. It works on a pull model: the main session does not wait for a background worker to finish a task, but simply receives a task_id and moves on. Before a complex change, you can first send a research job in readonly mode, then separately ask a second model via consult_peer, and only after that start the refactoring. In other words, instead of a linear think-do-check flow, you get a pipeline in which the stages run in parallel and do not block one another.

  • the main IDE agent sets tasks and collects results
  • background workers on Gemini CLI perform analysis, coding and checks
  • consult_peer provides a second opinion from another model before any code changes
  • the shared `.agent/delegation/` directory keeps agents' artifacts separate
  • skills and workflows define roles, checklists and standard pipelines

The key rule is strict: agents must not edit the same files at the same time. One writes its findings to a separate markdown file, another reads them and drafts an architecture proposal, a third audits templates. This removes most collisions and turns the agent system into something like a development team with separate lanes of responsibility. The principle is stated bluntly:

Nobody touches anyone else's files.

Consensus and control

The most interesting part is cross-model consensus. Because the worker pool runs on Gemini CLI, a different model takes the main IDE agent role, so that you get a real outside check of an idea rather than self-agreement. In the example, Claude proposes an architectural solution, and Gemini looks for blind spots and returns a verdict such as AGREE or SUGGEST_CHANGES before anyone modifies the codebase. On top of this sits fractal orchestration, where the orchestrator can spawn new teams and nested sub-teams, much like team leads and developers in a conventional engineering organization.

The article also examines how agents behave while waiting. Without extra configuration, they either pointlessly poll the status of a background task or jump in to do it themselves, duplicating work. To address this, the system adds an on_wait_hint prompt: it tells the model when to switch to another useful task and when, conversely, to simply wait for the result.

The final emphasis is security: treat any MCP server as a potential prompt-injection point, pin versions, restrict file system access and do not pass secrets in prompts.

What this means

The write-up illustrates a new shift in the AI tools market: a subscription's value is now measured not only by model quality but by how easily you can build a working agent infrastructure from it. If the approach catches on, expensive AI plans will sell not more answers but a complete environment for parallel development, research and internal AI review.

Story

Key Questions Answered

What are the key details on The subscription as infrastructure?

The core argument is simple: Ultra's price looks high, but you can recoup it through how you architect your work rather than through the number of chats. Instead of forcing one model through endless refactoring, the proposal combines Antigravity IDE, Claude as the main agent and Gemini CLI as a nearly unlimited pool of executors. If one model's daily limit runs out, the workflow does not collapse: the orchestrator switches to another model, and background tasks keep running separately. This approach tackles two problems at once. The first is token cost in classic API scenar

How the pool works?

For this, the author proposes a custom MCP server, Agent-Pool-MCP. It works on a pull model: the main session does not wait for a background worker to finish a task, but simply receives a task_id and moves on. Before a complex change, you can first send a research job in readonly mode, then separately ask a second model via consult_peer, and only after that start the refactoring. In other words, instead of a linear think-do-check flow, you get a pipeline in which the stages run in parallel and do not block one another. the main IDE agent sets tasks and collects results back

What are the key details on Consensus and control?

The most interesting part is cross-model consensus. Because the worker pool runs on Gemini CLI, a different model takes the main IDE agent role, so that you get a real outside check of an idea rather than self-agreement. In the example, Claude proposes an architectural solution, and Gemini looks for blind spots and returns a verdict such as AGREE or SUGGEST_CHANGES before anyone modifies the codebase. On top of this sits fractal orchestration, where the orchestrator can spawn new teams and nested sub-teams, much like team leads and developers in a conventional engineering o

ZK
Zhemal Khamidun — CPO at Alpina Digital, product manager of AlpinaGPT. Building AI products since 2019. Hamidun News is a pet project that grew into a production aggregator with 6,000+ readers.
✦ Hands-On AI Engineering · Hamidun Academy

Build & Ship Production AI Agents Without Boilerplate Code

Start your free 72-hour trial at Hamidun Academy (academy.hamidun.com) — interactive lessons on Claude Code & Cursor, live Tech Radar, and production agent templates.

Start 72h Free Trial →Vibe-Coding Intensive
What do you think?
Loading comments…