Gemini CLI peut désormais déléguer ses tâches complexes à des agents spécialisés

Ce 15 avril 2026, Google a dévoilé l’arrivée des subagents dans Gemini CLI, son agent IA open source destiné aux développeurs et développeuses. Le principe : quand une tâche est trop complexe, volumineuse ou répétitive pour être traitée dans la session principale, l’agent principal la délègue à un sous-agent spécialisé, puis attend son résultat.

Gemini CLI intègre désormais des sous-agents

Contrairement à un appel d’outil classique, le subagent (ou sous-agent) opère dans un contexte entièrement isolé : ses propres instructions système, ses propres outils et sa propre fenêtre de contexte. Les dizaines d’appels d’outils, de lectures de fichiers ou d’exécutions de tests qu’il effectue ne s’accumulent pas dans l’historique de la session principale. Une fois sa tâche terminée, le subagent transmet uniquement son résultat consolidé à l’agent principal, qui conserve ainsi une session légère et centrée sur les décisions de haut niveau.

Google décrit cette architecture comme un modèle « hub and spoke » : l’agent principal occupe le rôle de stratège et orchestre, les subagents celui de spécialistes interchangeables. Un subagent peut notamment prendre en charge des modifications sur plusieurs fichiers simultanément, l’exécution de commandes produisant de volumineux logs, ou encore des analyses de base de code étendue.

Google explique :

Leur exécution complète, qui peut impliquer des dizaines d’appels d’outils, de recherches de fichiers ou d’exécutions de tests, est consolidée en une seule réponse renvoyée à l’agent principal. Cela évite la saturation de votre fenêtre de contexte principale et garantit des interactions rapides et économiques.

Comment créer un subagent personnalisé

Les sous-agents se définissent via un fichier Markdown avec un en-tête YAML. Ce fichier déclare les métadonnées de l’agent et contient, dans son corps, les instructions système qui lui servent de prompt de départ. Voici les paramètres principaux de l’en-tête :

• name : le nom du subagent, utilisé pour l’appeler via la syntaxe @nom-du-subagent,
• description : une description du rôle de l’agent, qui guide l’agent principal dans sa décision de délégation,
• tools : la liste des outils auxquels le subagent a accès (lecture de fichiers, recherche, shell, serveurs MCP, etc.),
• model : le modèle à utiliser, avec la valeur inherit pour hériter du modèle de la session principale.

Ces fichiers peuvent être stockés à deux niveaux. À l’échelle du projet, dans le dossier .gemini/agents/, ils sont partagés avec l’ensemble de l’équipe. À l’échelle de l’utilisateur, dans ~/.gemini/agents/, ils restent personnels et disponibles sur tous les projets. Les subagents peuvent également être intégrés aux extensions Gemini CLI en fournissant les fichiers de définition dans un dossier agents/ à l’intérieur de l’extension.

Comment invoquer les subagents dans Gemini CLI

Gemini CLI embarque d’emblée trois subagents natifs :

• codebase_investigator, dédié à l’analyse de bases de code et à la cartographie des dépendances,
• cli_help, expert de Gemini CLI lui-même, à solliciter pour les questions de configuration ou de commandes,
• un agent généraliste, aux capacités identiques à celles de l’agent principal, pour les tâches larges qui nécessitent un contexte isolé.

Pour appeler un subagent précis, il suffit de faire précéder le prompt du symbole @ suivi du nom de l’agent, à la manière d’une mention. Sans ce préfixe, c’est l’agent principal qui décide seul de déléguer ou non, selon la nature de la demande.

Gemini CLI prend également en charge des subagents distants via le protocole Agent-to-Agent (A2A), qui permet de déléguer des tâches à des agents hébergés sur des serveurs externes plutôt que sur la machine locale.

Les subagents sont activés par défaut. Pour les désactiver, il suffit de passer enableAgents à « false » dans le fichier settings.json, ou d’utiliser la commande /agents disable à l’échelle d’un projet.