Google AI Ultra : transformer l'abonnement en pool d'agents parallèles et en consensus entre modèles

Google AI Ultra peut être vu non comme un abonnement coûteux à Gemini, mais comme le socle d'un environnement multi-agents maison. L'idée : répartir les tâches routinières entre des workers en arrière-plan, et employer l'agent principal comme orchestrateur et relecteur des décisions.

L'abonnement comme infrastructure

La thèse centrale est simple : le prix d'Ultra paraît élevé, mais on peut l'amortir par l'architecture du travail plutôt que par le nombre de conversations. Au lieu d'enfermer un seul modèle dans un refactoring sans fin, on propose d'associer Antigravity IDE, Claude comme agent principal et Gemini CLI comme pool d'exécutants quasi illimité. Si la limite quotidienne d'un modèle est atteinte, le scénario ne s'effondre pas : l'orchestrateur bascule sur un autre modèle et les tâches de fond continuent de tourner séparément.

Cette approche règle deux problèmes à la fois. Le premier est le coût des tokens dans les scénarios API classiques, où chaque agent auxiliaire grignote le budget. Le second est le goulot d'étranglement d'une session d'IDE unique : même si l'environnement sait appeler des sous-agents, il est difficile de les piloter, de leur attribuer des rôles et de bâtir des processus reproductibles. Ici, on présente cela comme le passage d'une fenêtre intelligente à une véritable équipe d'agents, où les uns font de la recherche, d'autres du code, d'autres encore vérifient la solution proposée.

Comment fonctionne le pool

Pour cela, on propose un serveur MCP maison, Agent-Pool-MCP. Il fonctionne sur un modèle pull : la session principale n'attend pas que le worker termine sa tâche, elle reçoit simplement un task_id et poursuit. Avant une modification complexe, on peut d'abord envoyer une recherche en mode readonly, puis interroger séparément un second modèle via consult_peer, et seulement ensuite lancer le refactoring. Autrement dit, au lieu d'un déroulé linéaire (réfléchir, faire, vérifier), on obtient un pipeline où les étapes avancent en parallèle sans se bloquer.

• l'agent principal de l'IDE fixe les tâches et collecte les résultats
• les workers Gemini CLI effectuent analyses, code et vérifications
• consult_peer fournit un second avis d'un autre modèle avant toute modification du code
• le répertoire partagé `.agent/delegation/` sépare les artefacts de chaque agent
• skills et workflows définissent rôles, checklists et pipelines types

La règle clé est stricte : les agents ne doivent pas modifier les mêmes fichiers en même temps. L'un écrit ses conclusions dans un fichier markdown distinct, un autre les lit et rédige une proposition d'architecture, un troisième audite les templates. Cela supprime l'essentiel des collisions et fait ressembler le système d'agents à une équipe de développement avec des couloirs de responsabilité distincts. Le principe est formulé sans détour :

Personne ne touche aux fichiers des autres.

Consensus et contrôle

La partie la plus intéressante est le consensus entre modèles. Comme le pool de workers repose sur Gemini CLI, le rôle d'agent principal de l'IDE est confié à un autre modèle, afin d'obtenir une vraie vérification extérieure de l'idée plutôt qu'un auto-accord. Dans l'exemple, Claude propose une solution d'architecture, et Gemini cherche les angles morts et rend un verdict du type AGREE ou SUGGEST_CHANGES avant que quiconque ne touche à la base de code. S'y ajoute une orchestration fractale : l'orchestrateur peut engendrer de nouvelles équipes et des sous-équipes imbriquées, un peu comme les tech leads et les développeurs d'une organisation d'ingénierie classique.

Le comportement des agents en attente est aussi examiné. Sans configuration supplémentaire, ils interrogent sans raison l'état de la tâche de fond, ou se jettent dessus pour la faire eux-mêmes et dupliquent le travail. Pour y remédier, le système ajoute l'indice on_wait_hint : il indique au modèle quand passer à une autre tâche utile et quand, au contraire, se contenter d'attendre le résultat.

L'accent final porte sur la sécurité : tout serveur MCP doit être considéré comme un point potentiel d'injection de prompt, il faut figer les versions, restreindre l'accès au système de fichiers et ne pas transmettre de secrets dans les prompts.

Ce que cela signifie

Cette analyse illustre un nouveau glissement sur le marché des outils d'IA : la valeur d'un abonnement ne se mesure plus seulement à la qualité du modèle, mais à la facilité avec laquelle on peut en tirer une infrastructure d'agents opérationnelle. Si l'approche s'impose, les offres d'IA haut de gamme ne vendront plus davantage de réponses, mais un environnement complet pour le développement parallèle, la recherche et la relecture interne par IA.