Architecture du conseil avec Gemini et Argon 4 dans Google Antigravity : comment nous avons réparti les capacités ?

Résumé : Faire tourner un modèle d'IA très puissant dans une seule fenêtre de chat à la fois comme chercheur qui parcourt des centaines de fichiers, comme développeur qui écrit du code, comme exécuteur de tests et comme auditeur de sécurité finit par réduire le rendement. À mesure que la fenêtre de contexte se remplit de sorties brutes, l'attention du modèle se disperse, les règles initiales sont oubliées et le coût en jetons (tokens) augmente inutilement. Dans cet article, j'explique d'abord pourquoi, sur Google Antigravity, nous avons positionné le modèle Gemini 4 Argon non pas comme un ouvrier travaillant seul mais comme un chef d'orchestre et contrôleur final, puis comment nous avons constitué notre conseil de 12 membres, comment nous avons réparti 19 extensions, plus de 300 paquets de compétences SKILL.md et plus de 45 serveurs MCP selon leurs domaines de mission. Dans la dernière partie, j'ai rassemblé des recommandations pratiques directement applicables pour ceux qui veulent utiliser Argon 4 plus efficacement dans leurs propres flux de travail.

Pourquoi confier toutes les tâches à un seul modèle finit-il par saturer ?

Dans le travail quotidien de développement logiciel, ouvrir un modèle à forte capacité de raisonnement comme Gemini 4 Argon et lui faire réaliser tout le projet en une seule session semble facile au premier abord. Mais à mesure que la tâche grandit, trois problèmes concrets apparaissent :

La pollution de la fenêtre de contexte : lorsque vous faites lire 30 à 40 fichiers différents pour trouver un bug ou ajouter une nouvelle fonctionnalité, lorsque vous empilez les sorties de compilation et les journaux d'erreurs dans la même conversation, l'espace de travail (context) du modèle se remplit de bruit. Ce phénomène, connu dans la littérature de recherche sous le nom de Lost in the Middle (perdu au milieu), conduit le modèle à négliger les règles d'architecture ou les contraintes de sécurité que vous avez données au départ.
Consommer un modèle de même poids pour chaque tâche : exécuter à plusieurs reprises le modèle de raisonnement le plus haut de gamme avec un contexte gigantesque pour un renommage mécanique sur plusieurs fichiers, un test unitaire de routine ou une simple mise à jour de dépendance allonge le temps et gaspille le budget de jetons.
L'aveuglement à relire son propre code : lorsque le modèle qui écrit le code et celui qui l'audite partagent le même historique de conversation, le modèle a tendance à considérer comme correcte, lors de la vérification, une hypothèse erronée qu'il a faite en écrivant le code.

Pour surmonter ce blocage, nous avons changé notre organisation de travail dans Antigravity. Nous avons fait d'Argon 4 non plus un agent unique qui écrit lui-même chaque ligne, mais un président de conseil qui pilote des outils spécialisés et des sous-modèles.

Quels modèles composent le conseil et comment avons-nous réparti leurs rôles ?

Notre système comporte une couche de tâches déclarative (ax.io/v1alpha1) qui fonctionne sous /home/ozdil/Projects/SubAgents/ax. Quand nous disons "konsey ile yap", ce ne sont pas des scripts aléatoires qui s'exécutent ; ce sont 12 membres du conseil, chacun doté de son propre binaire et d'une définition de tâche délimitée, qui entrent en jeu :

Membre du conseil	Outil d'exécution	Tâche principale assumée
Antigravity (Gemini 4 Argon)	`antigravity-chief`	Chef d'orchestre, recherche multimodale, coordination des extensions/compétences/MCP et contrôle final fullstack de la phase 7
Claude Code	`claude` (v2.1.302)	Conception d'architecture système, modèles de solutions cloud, SecOps, IAM, WAF et audit de sécurité HANCORE
J-Code Harness	`jcode` (v0.98.1)	Exécution d'agents Rust à hautes performances, migrations Rust (`migrate-to-rust`), liaisons FFI C/Rust et construction Genkit (Go/Dart)
OpenAI Codex CLI	`codex` (v0.163.0)	Exécution en bac à sable (sandbox) isolé au niveau du noyau, vérification algorithmique, tests unitaires/de composants et calcul scientifique
Google Gemini CLI	`gemini-cli` (v0.64.0)	Analyse de dépôts de code locaux à contexte long de plus de 1M de jetons, Agent Platform, Cloud Run, AlloyDB/Spanner et intégration Firebase
OpenCode	`opencode` (v1.19.3)	Analyse statique basée sur le protocole de serveur de langage (LSP) et architecture d'interface moderne Flutter/Android (Jetpack Compose, CameraX, Media3, LiteRT)
Cline	`cline` (v3.0.72)	Exécution autonome de tâches, web moderne et extensions Chrome, analyse de performance/accessibilité avec Chrome DevTools MCP et intégration Cloudflare
Grok	`grok` (v1.0.62)	Raisonnement algorithmique à grande vitesse, infrastructure de clusters GKE et IA/TPU, Cloud Monitoring/Logging/Trace et SLO/FinOps
Qwen Code	`qwen` (v0.25.2)	Data Agent Kit (10 serveurs MCP DAK), pipelines BigQuery/Spark/Dataflow/Airflow, bioinformatique (41 compétences scientifiques) et localisation
Mimo Code	`mimo` (v0.1.15)	Prototypage rapide isolé, construction de micro-modules, aperçus de composants d'interface et intégrations de SDK publicitaires/médias mobiles
Aider	`aider` (v0.86.2)	Gestion fine des différences (diff) sur plusieurs fichiers, montées de version (AGP 9, migrations Compose) et fusion de correctifs
Jev Gate	`jev-gate` (v0.7.0)	Porte de qualité déterministe (seuil d'acceptation `0.85`), analyse R8/Proguard, conformité aux politiques des stores et audit des citations de sources

Les sous-agents experts intégrés d'Antigravity (Subagents)

En plus de ce conseil de 12 membres, Gemini 4 Argon peut lancer directement 5 sous-agents intégrés dans son propre environnement d'exécution interne via l'outil invoke_subagent. Le principal avantage de ces sous-agents est qu'ils travaillent dans leur propre contexte isolé et ne renvoient que le résultat à Argon sans gonfler la fenêtre de chat principale :

research : Agent de recherche en lecture seule. Lorsqu'il faut parcourir des dizaines de fichiers dans le dépôt de code ou effectuer des recherches web/documentation, nous déléguons le travail à cet agent. La session Argon principale n'est pas polluée par des centaines de lignes de contenu brut de fichiers.
self : Agent jumeau qui hérite de toutes les capacités d'Argon. Lorsqu'il faut exécuter deux tâches indépendantes en parallèle, il travaille dans une branche d'espace de travail séparée (branch ou share) et termine son travail.
firestore-rules-author : Sous-agent expert obligatoire que nous utilisons pour rédiger et auditer les règles de sécurité Cloud Firestore (firestore.rules).
flutter_a11y_agent : Agent expert qui audite les écrans et composants Flutter selon les normes d'accessibilité WCAG.
image-generator : Agent de génération d'images qui intervient lorsqu'il faut des visuels d'interface ou des ressources de design.

Comment avons-nous déployé 19 plugins, plus de 300 packs de compétences et plus de 45 serveurs MCP ?

Dans notre environnement Antigravity, il y a 19 plugins installés, sous ceux-ci plus de 300 guides de compétences SKILL.md et plus de 45 serveurs MCP (Model Context Protocol). Si vous chargez tous ces fichiers de compétences et schémas d'outils MCP en même temps dans le contexte initial d'Argon 4, vous aurez consommé une grande partie du budget de contexte avant même d'écrire une seule ligne de code.

Pour résoudre cela, nous avons mis en place un mécanisme de déploiement à deux niveaux : la matrice de routage par domaine de tâche (DOMAIN_SKILL_MATRIX) et la séparation MCP Eager/Lazy.

1. Matrice de routage par domaine de tâche (`DOMAIN_SKILL_MATRIX`)

Lorsque ax-run est exécuté, il analyse les mots-clés de la demande entrante et le répertoire du projet cible, puis associe le travail aux 12 domaines d'ingénierie concernés. Seuls les agents, plugins, packs SKILL.md et serveurs MCP du domaine sélectionné sont activés :

Domaine de tâches	Extensions déclenchées en cas de correspondance	Capacités phares (`SKILL.md`) et outils MCP
`flutter-dart`	`flutter`, `firebase`, `google-skills-catalog`	`flutter-apply-architecture-best-practices`, `dart-use-ffigen`, `dart-run-static-analysis`, `firebase-mcp-server`
`android-kotlin-devices`	`android-skills`, `android-cli-plugin`	`jetpack-compose-performance`, `navigation-3`, `litert-runtime`, `r8-analyzer`, `android-management-api`
`web-modern-extensions`	`modern-web-guidance-plugin`, `chrome-devtools-plugin`	`modern-web-guidance`, `a11y-debugging`, `debug-optimize-lcp`, `chrome-devtools-mcp`, `cloudflare-*`
`firebase-serverless`	`firebase`, `google-skills-catalog`	`firebase-data-connect`, `firestore-rules-creation`, `firebase-security-rules-auditor`, `cloudrun`
`agent-platform-gemini-genkit`	`google-antigravity-sdk`, `gemini-api`, `google-cloud-developer`	`google-antigravity-sdk`, `gemini-interactions-api`, `developing-genkit-go`, `gemini-api-docs`
`gke-ai-tpu-cloud-infra`	`google-skills-catalog`, `google-cloud-developer`	`gke-golden-path`, `gke-compute-classes`, `gke-ai-troubleshooting-tpu-*`, `google-kubernetes-engine`
`data-bigquery-lakehouse-spark`	`data-agent-kit-plugin`, `google-skills-catalog`	`bigquery-sql`, `bigquery-ai-ml`, `dbt-bigquery`, `gcp-spark`, `dak-bigquery`, `dak-gcs`
`secops-iam-waf-hancore`	`google-skills-catalog`, `firebase`, `android-skills`	`google-cloud-waf-security`, `secops-hunt`, `iam-helper-*`, `google-cloud-organization-policy`
`observability-sre-finops`	`google-skills-catalog`	`cloud-monitoring-promql-query`, `google-cloud-slo-alert-configuration`, `google-cloud-monitoring`
`science-bioinformatics-epigraphy`	`science`	`alphafold-database-fetch-and-analyze`, `alphagenome-variant-impact-score`, `predictingthepast`, `biomolecular_structure_viewer_mcp`
`workspace-maps-ads-media`	`gslides`, `gdocs`, `gsheets`, `gdrive`, `gcalendar`, `google_maps_platform`	`gslides`, `google-maps-platform`, `google-ads-api-mcp-setup`, `canva`, `gmp-code-assist`
`systems-rust-omarchy`	`google-skills-catalog`, `flutter`	`migrate-to-rust`, `dart-use-ffigen`, `agy-customizations`, `github-mcp-server`

2. Chargement MCP Eager (direct) et Lazy (à la demande)

Chacun des plus de 45 serveurs MCP contient des dizaines de sous-outils. Plutôt que de les empiler dans le contexte, nous les avons répartis en deux catégories :

Outils chargés directement (Eager) : les outils fréquemment utilisés gemini_search_docs et gemini_get_doc (gemini-api_gemini-api-docs) sont enregistrés directement comme outils locaux. Argon 4 peut accéder instantanément à la documentation actuelle de l'API Gemini et des SDK.
Outils chargés à la demande (Lazy) : plus de 40 serveurs comme chrome-devtools-mcp, cloudflare-bindings, data-agent-kit-plugin_dak-bigquery, google-kubernetes-engine ou canva ne figurent au démarrage que sous forme de liste de noms. Lorsqu'Argon 4 doit utiliser l'un de ces outils, il lit d'abord le fichier de schéma /home/ozdil/.gemini/antigravity/mcp/<sunucu>/<arac>.json, puis effectue l'appel avec call_mcp_tool. Cette structure permet d'économiser environ 88 pour cent de jetons dans la fenêtre de contexte initiale.

Pipeline d'exécution en 7 étapes : comment fonctionne l'orchestration en sandwich ?

La décision de conception la plus importante du conseil a été de placer le modèle Gemini 4 Argon à la fois tout au début et tout à la fin du processus. On peut appeler cela simplement Orchestration en sandwich (Bookend Verification). Les 7 étapes de notre fichier tasks/pipeline.yaml fonctionnent dans l'ordre suivant :

Découverte et activation (1-discovery-plugins-skills-and-mcp) : La première étape est pilotée par Gemini 4 Argon. Avec gemini-cli (contexte de 1M+) et le sous-agent research, il parcourt le dépôt de code et détermine, via ax-run, quels plugins, fichiers SKILL.md et serveurs MCP seront utilisés.
Architecture et conception de la solution (2-architecture-and-solution-design) : Sous la direction de claude-architect, le schéma système, les types de données et les règles de sécurité (avec firestore-rules-author) sont établis.
Code, données et exécution MCP (3-code-data-and-mcp-implementation) : jcode (Rust/FFI), codex (algorithmes), opencode (mobile/interface), cline (web moderne) et qwen (données/science) écrivent les modules de leur domaine d'expertise et exécutent les outils MCP.
Patch multi-fichiers et migration (4-multi-file-patching-and-migration) : aider-patcher entre en jeu pour fusionner les modifications multi-fichiers et les migrations de version.
Tests en bac à sable, LSP et porte qualité (5-jev-gate-and-sandbox-verification) : codex-sandbox exécute les tests unitaires, opencode l'analyse statique LSP, flutter_a11y_agent le contrôle d'accessibilité et jev-gate le contrôle qualité avec un seuil de 0.85.
Audit SecOps, WAF et HANCORE (6-secops-waf-and-hancore-audit) : Dans une couche à connectivité réseau restreinte (offline-strict), on vérifie les fuites de clés secrètes, les autorisations IAM et les règles de sécurité Linux HANCORE (isolation des processus process_group(0), plafond de lecture de fichier de 1 MiB, permissions de fichier atomiques 0600).
Contrôle final full-stack Argon (7-argon-fullstack-verification) : Le dernier mot revient à nouveau à Gemini 4 Argon. La tâche n'est pas clôturée tant que le front-end, le back-end, la base de données, les sorties MCP, les résultats de compilation et l'intégrité à l'exécution n'ont pas été vérifiés de bout en bout.

Que faire pour utiliser Argon 4 plus efficacement ?

Même si vous ne mettez pas en place un conseil complet de 12 modèles sur votre propre système, adopter ces six habitudes lorsque vous utilisez Gemini 4 Argon dans Antigravity augmente directement le rendement que vous tirez du modèle :

Déléguez les vastes analyses de fichiers au sous-agent research : S'il faut lire 15 à 20 fichiers pour comprendre un problème, ne les faites pas ouvrir un par un dans la conversation principale. Chargez le sous-agent research via invoke_subagent. L'agent de recherche lit tous les fichiers dans son propre contexte et ne renvoie à Argon 4 qu'un résumé propre avec les liens vers les lignes. Ainsi, l'attention d'Argon 4 n'est pas dispersée.
Faites lire le fichier SKILL.md concerné avant d'écrire du code : Plutôt que de vous fier à la mémoire d'entraînement générale du modèle, si un fichier de compétence SKILL.md correspond à votre tâche (par exemple bigquery-sql, jetpack-compose-performance ou migrate-to-rust), faites-le lire d'abord. Les règles d'API à jour entrent ainsi directement dans le contexte de travail.
Exécutez le sous-agent self en parallèle pour les tâches indépendantes : Si deux modules distincts qui ne dépendent pas l'un de l'autre doivent être écrits, n'attendez pas qu'Argon 4 les écrive l'un après l'autre dans une seule fenêtre. Lancez le sous-agent self en mode espace de travail isolé (branch ou share) et exécutez-les en parallèle.
Ne faites pas installer de boucle d'interrogation (polling) pour les tâches en arrière-plan : Antigravity dispose d'un système de réveil réactif (reactive wakeup). Lorsque vous lancez une compilation longue ou un sous-agent, vous n'avez pas besoin de mettre en place une boucle sleep ou d'interrogation d'état ; passez en attente à la fin de l'appel d'outil, le système réveillera automatiquement Argon lorsque la tâche sera terminée.
Sur les gros fichiers, utilisez un patch ciblé plutôt qu'une réécriture complète : Lors d'une modification dans un long fichier existant, faire réécrire tout le fichier depuis le début (write_to_file) est à la fois lent et risque de faire perdre les lignes de commentaire existantes. Préférez plutôt l'outil replace_file_content par plage de lignes, ou, pour les travaux multi-fichiers, des outils axés sur les différences (diff) comme aider.
Utilisez toujours Argon 4 comme « porte de validation finale » : Une fois la génération de code terminée, faites impérativement effectuer par Argon 4 le test de compilation, le test unitaire et, s'il y a une interface web, le contrôle en direct de la console/accessibilité via chrome-devtools-mcp. Le point fort du modèle est de pouvoir évaluer ensemble les sorties des différentes couches et de détecter les erreurs d'intégration passées inaperçues.

Mon analyse

Ce qui est certain : Quelle que soit la taille de la fenêtre de contexte du modèle, empiler toutes les tâches dans un seul historique de conversation finit, à un moment donné, par réduire à la fois la qualité et la vitesse. La décomposition des tâches et l'usage de sous-agents spécialisés ne sont plus un choix, mais une nécessité sur les grands projets.
Ce qui fait le plus de différence en pratique : Séparer plus de 45 serveurs MCP en eager et lazy, et confier les vastes recherches au sous-agent research, a considérablement soulagé la mémoire de travail d'Argon 4.
En résumé : Lorsque vous utilisez Gemini 4 Argon non pas comme un ouvrier qui porte seul chaque pierre, mais comme un chef d'orchestre qui répartit le travail entre les bons experts, construit l'architecture et vérifie tout de bout en bout à la fin, vous découvrez sa véritable puissance.