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

Google AI Ultra peut être envisagé non pas comme un cher abonnement à Gemini, mais comme la base de votre propre environnement multi-agent. L'idée est de distribuer les tâches routinières entre des workers d'arrière-plan, tout en utilisant l'agent principal comme orchestrateur et examinateur des solutions.

L'Abonnement comme Infrastructure

La thèse principale de cette analyse est simple: le prix d'Ultra semble élevé, mais il peut être justifié non pas par le nombre de chats, mais par l'architecture du travail. Au lieu de faire subir à un modèle une refactorisation interminable, la proposition est une combinaison d'Antigravity IDE, Claude en tant qu'agent principal et Gemini CLI en tant que pool d'exécutants presque illimité. Si la limite quotidienne d'un modèle est dépassée, le scénario ne s'effondre pas: l'orchestrateur bascule vers un autre modèle et les tâches d'arrière-plan continuent séparément.

Cette approche résout deux problèmes à la fois. Le premier est le coût des tokens dans les scénarios API classiques, où chaque agent auxiliaire consomme du budget. Le second est le goulot d'étranglement d'une seule session IDE: même si l'environnement peut appeler des sous-agents, c'est difficile à gérer, à assigner des rôles et à construire des processus répétables.

Ici, c'est présenté comme une transition d'une seule fenêtre intelligente vers une équipe complète d'agents, où certains gèrent la recherche, certains le code et certains vérifient la solution proposée.

Comment Fonctionne le Pool

Pour cela, un serveur MCP personnalisé appelé Agent-Pool-MCP est proposé. Il fonctionne sur un modèle pull: la session principale n'attend pas que l'exécutant d'arrière-plan termine une tâche, elle obtient simplement un task_id et continue. Avant un changement complexe, vous pouvez d'abord envoyer la recherche en mode lecture seule, puis demander séparément un second modèle via consult_peer, et seulement ensuite lancer la refactorisation. Au lieu d'un scénario linéaire—pensez, faites, vérifiez—vous obtenez un pipeline où différentes étapes s'exécutent en parallèle et ne se bloquent pas mutuellement.

• l'agent IDE principal définit les tâches et collecte les résultats
• les workers d'arrière-plan sur Gemini CLI effectuent l'analyse, le code et les vérifications
• consult_peer donne un deuxième avis d'un autre modèle avant les changements de code
• le répertoire partagé `.agent/delegation/` achemine les artefacts entre les agents
• les skills et workflows définissent les rôles, les checklists et les pipelines standards

La règle clé ici est extrêmement stricte: les agents ne doivent pas modifier les mêmes fichiers simultanément. L'un écrit les conclusions dans un fichier markdown séparé, l'autre les lit et formule une proposition architecturale, un tiers audite les templates. Cela élimine la plupart des collisions et transforme le système d'agents en quelque chose comme une équipe de développement avec des voies de responsabilité séparées. Le principe est énoncé de la manière la plus directe:

Personne ne touche aux fichiers des autres.

Consensus et Contrôle

La partie la plus intéressante est le consensus entre modèles. Puisque le pool de workers est construit sur Gemini CLI, un autre modèle prend le rôle d'agent IDE principal pour obtenir non pas l'auto-accord, mais une vérification externe réelle de l'idée. Dans l'exemple, Claude propose une solution architecturale et Gemini recherche les points aveugles et retourne un verdict comme AGREE ou SUGGEST_CHANGES avant que quiconque ne modifie la base de code. Par-dessus cela se construit une orchestration fractale, où l'orchestrateur peut générer de nouvelles équipes et sous-équipes imbriquées presque comme des responsables d'ingénierie et des développeurs dans une structure ordinaire.

Le comportement des agents en attente est discuté séparément. Sans réglage supplémentaire, ils interrogent sans sens le statut d'une tâche d'arrière-plan, ou se précipitent pour la faire eux-mêmes et dupliquent le travail. Pour cela, un indice appelé on_wait_hint est ajouté au système: il dit au modèle quand basculer vers une autre tâche utile et quand, au contraire, simplement attendre le résultat. L'accent final est la sécurité: tout serveur MCP doit être considéré comme un point potentiel d'injection de prompt; verrouiller les versions, restreindre l'accès au système de fichiers et ne pas transmettre les secrets dans les prompts.

Ce Que Cela Signifie

Cette analyse illustre bien un nouveau changement sur le marché des outils IA: la valeur d'un abonnement est maintenant mesurée non seulement par la qualité du modèle, mais aussi par la facilité avec laquelle vous pouvez construire une infrastructure d'agents fonctionnelle à partir de celui-ci. Si cette approche prend, les plans IA coûteux ne vendront pas plus de réponses, mais un environnement complet pour le développement parallèle, la recherche et l'examen interne de l'IA.