Google AI Ultra: cómo convertir la suscripción en un pool de agentes paralelos y consenso entre modelos
Google AI Ultra puede servir no solo como acceso a Gemini, sino como base para el desarrollo multiagente. En un esquema con un pool de workers en segundo plano sobre Gemini CLI, el agente principal se encarga de la orquestación y de la verificación cruzada de decisiones entre modelos. En el centro está el servidor MCP Agent-Pool-MCP, que reparte tareas, roles y artefactos entre los agentes.
Procesado por IA desde Habr AI; editado por Hamidun News
Google AI Ultra puede verse no como una costosa suscripción a Gemini, sino como la base de un entorno multiagente propio. La idea es repartir las tareas rutinarias entre workers en segundo plano y usar al agente principal como orquestador y revisor de decisiones.
La suscripción como infraestructura
La tesis central es sencilla: el precio de Ultra parece alto, pero puede amortizarse con la arquitectura del trabajo, no con el número de chats. En lugar de encerrar a un solo modelo en un refactor interminable, se propone combinar Antigravity IDE, Claude como agente principal y Gemini CLI como un pool de ejecutores casi ilimitado. Si se agota el límite diario de un modelo, el flujo no se rompe: el orquestador cambia a otro modelo y las tareas en segundo plano siguen ejecutándose por separado.
Este enfoque resuelve dos problemas a la vez. El primero es el coste de los tokens en los escenarios clásicos de API, donde cada agente auxiliar consume presupuesto. El segundo es el cuello de botella de una sola sesión de IDE: aunque el entorno pueda invocar subagentes, cuesta gestionarlos, asignarles roles y montar procesos repetibles. Aquí se plantea como el paso de una ventana inteligente a un equipo completo de agentes, donde unos investigan, otros escriben código y otros revisan la solución propuesta.
Cómo funciona el pool
Para ello se propone un servidor MCP propio, Agent-Pool-MCP. Funciona con un modelo pull: la sesión principal no espera a que el worker termine la tarea, sino que recibe un task_id y sigue adelante. Antes de un cambio complejo se puede enviar primero una investigación en modo readonly, luego consultar por separado a un segundo modelo mediante consult_peer, y solo después lanzar el refactor. Es decir, en lugar de un flujo lineal de pensar, hacer y comprobar, se obtiene una cadena en la que las etapas avanzan en paralelo y no se bloquean entre sí.
- el agente principal del IDE plantea tareas y recoge resultados
- los workers de Gemini CLI ejecutan análisis, código y comprobaciones
- consult_peer ofrece una segunda opinión de otro modelo antes de cambiar el código
- el directorio compartido `.agent/delegation/` separa los artefactos de cada agente
- skills y workflows definen roles, listas de comprobación y pipelines típicos
La regla clave es tajante: los agentes no deben editar los mismos archivos al mismo tiempo. Uno escribe sus conclusiones en un archivo markdown aparte, otro las lee y elabora una propuesta de arquitectura, un tercero audita plantillas. Así se evita la mayoría de colisiones y el sistema de agentes se parece a un equipo de desarrollo con carriles de responsabilidad separados. El principio se formula sin rodeos:
Nadie toca los archivos de los demás.
Consenso y control
La parte más interesante es el consenso entre modelos. Como el pool de workers funciona sobre Gemini CLI, el papel de agente principal del IDE lo ocupa otro modelo, de modo que se obtiene una verificación externa real de la idea y no un autoacuerdo. En el ejemplo, Claude propone una solución de arquitectura y Gemini busca puntos ciegos y devuelve un veredicto como AGREE o SUGGEST_CHANGES antes de que nadie modifique la base de código. Sobre esto se construye una orquestación fractal, en la que el orquestador puede generar nuevos equipos y subequipos anidados, casi como los líderes técnicos y desarrolladores de una estructura de ingeniería habitual.
También se analiza el comportamiento de los agentes mientras esperan. Sin configuración adicional, o bien consultan sin sentido el estado de la tarea en segundo plano, o bien se lanzan a hacerla ellos mismos y duplican el trabajo. Para evitarlo, el sistema añade la pista on_wait_hint: indica al modelo cuándo conviene pasar a otra tarea útil y cuándo, por el contrario, basta con esperar el resultado.
El énfasis final es la seguridad: cualquier servidor MCP debe considerarse un posible punto de inyección de prompts, hay que fijar versiones, limitar el acceso al sistema de archivos y no pasar secretos en los prompts.
Qué significa
El análisis muestra un nuevo giro en el mercado de herramientas de IA: el valor de una suscripción ya no se mide solo por la calidad del modelo, sino por lo fácil que resulta montar con ella una infraestructura de agentes funcional. Si el enfoque cuaja, los planes de IA caros no venderán más respuestas, sino un entorno completo para desarrollo paralelo, investigación y revisión interna con IA.
- 1 nov 2026Prueba de 16 modelos en 7 buscadores: Exa obtuvo una media de 10,5 puntos de 14; SearXNG, en torno a 3
- 1 nov 2026StreamVibe, el agente de vídeo de Google, supera en un 10,7 % a otros modelos en momento y calidad de respuesta
- 1 nov 2026OpenAI reescribe las reglas de comportamiento de GPT: cinco valores y una cadena de prioridades
- 1 nov 2026Los bots de voz con LLM recurren al clasificador rápido Jev: decisiones en 200–500 ms
Preguntas frecuentes sobre la noticia
¿Qué se sabe sobre La suscripción como infraestructura?
La tesis central es sencilla: el precio de Ultra parece alto, pero puede amortizarse con la arquitectura del trabajo, no con el número de chats. En lugar de encerrar a un solo modelo en un refactor interminable, se propone combinar Antigravity IDE, Claude como agente principal y Gemini CLI como un pool de ejecutores casi ilimitado. Si se agota el límite diario de un modelo, el flujo no se rompe: el orquestador cambia a otro modelo y las tareas en segundo plano siguen ejecutándose por separado. Este enfoque resuelve dos problemas a la vez. El primero es el coste de los token
Cómo funciona el pool?
Para ello se propone un servidor MCP propio, Agent-Pool-MCP. Funciona con un modelo pull: la sesión principal no espera a que el worker termine la tarea, sino que recibe un task_id y sigue adelante. Antes de un cambio complejo se puede enviar primero una investigación en modo readonly, luego consultar por separado a un segundo modelo mediante consult_peer, y solo después lanzar el refactor. Es decir, en lugar de un flujo lineal de pensar, hacer y comprobar, se obtiene una cadena en la que las etapas avanzan en paralelo y no se bloquean entre sí. el agente principal del IDE
¿Qué se sabe sobre Consenso y control?
La parte más interesante es el consenso entre modelos. Como el pool de workers funciona sobre Gemini CLI, el papel de agente principal del IDE lo ocupa otro modelo, de modo que se obtiene una verificación externa real de la idea y no un autoacuerdo. En el ejemplo, Claude propone una solución de arquitectura y Gemini busca puntos ciegos y devuelve un veredicto como AGREE o SUGGEST_CHANGES antes de que nadie modifique la base de código. Sobre esto se construye una orquestación fractal, en la que el orquestador puede generar nuevos equipos y subequipos anidados, casi como los
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.
Lo esencial de la IA — una vez por semana
Siete historias que de verdad importaron, elegidas a mano. Sin ruido ni notas de prensa.
¡Listo! Revisa tu correo para la confirmación.