agent-pool pour Google AI et Gemini CLI lancé avec pipelines, cron et bounce-back

Google AI et Gemini CLI disposent désormais d'une nouvelle couche d'orchestration d'agents open source. Le serveur agent-pool MCP collecte les délégations dispersées en pipelines, peut renvoyer les tâches pour révision, les exécuter selon un calendrier et décharger l'exécution sur des machines distantes.

Orchestration Automatique

Le problème que rencontre presque tout scénario multi-agent est simple : l'agent principal passe trop de temps non pas à travailler, mais à dispatcher. Si les étapes dépendent les unes des autres—analyse, refactorisation, tests, déploiement—l'orchestrateur doit interroger les statuts, analyser les réponses et lancer manuellement l'exécuteur suivant. Agent-pool déplace cette logique vers un daemon d'arrière-plan.

Via create_pipeline, les étapes et les dépendances sont décrites à l'avance, et le processus lui-même reste actif même après le redémarrage de l'IDE. L'idée clé n'est pas simplement d'exécuter un worker, mais de donner aux agents un langage de coordination. Après l'achèvement d'une étape, l'exécuteur envoie un signal de disponibilité, et si les données manquent, la tâche peut être renvoyée pour révision avec une explication.

Ce bounce-back est similaire à Request Changes en code review : l'étape précédente complète l'artefact et le remet à la chaîne. Cela transforme le pipeline non en un script linéaire, mais en une boucle gérée avec un nombre limité de retours.

«

Un worker peut déléguer des tâches par lui-même—c'est ainsi que toute l'orchestration fractale est construite. »

L'article décrit les principaux mécanismes d'un tel schéma :

• on_complete—lance l'étape suivante après qu'un worker spécifique soit terminé
• on_complete_all—attend tout le groupe et fait un fan-in avant l'étape suivante
• on_file—réagit à l'apparition d'un fichier sur le disque
• signal_step_complete—informe le daemon que l'étape est véritablement achevée
• bounce_back—renvoie la tâche en arrière, et maxBounces limite le nombre de cycles

Cron et SSH

La planification est gérée séparément. L'outil schedule_task utilise le format cron standard, donc un agent peut être configuré pour s'exécuter quotidiennement ou toutes les heures sans un planificateur séparé. Important : le daemon définit des verrous de fichiers atomiques : même si vous ouvrez plusieurs fenêtres d'IDE simultanément, la même tâche ne s'exécutera qu'une seule fois.

Les résultats sont stockés dans un dossier scheduled-results, donc le scénario peut être utilisé à la fois pour les vérifications de serveurs de routine et pour l'assemblage périodique de rapports hebdomadaires. Si une machine locale n'est pas suffisante, les workers peuvent être envoyés sur un serveur distant via SSH. Le runner est décrit dans la configuration agent-pool, après quoi des tâches spécifiques commencent à s'exécuter sur une machine dédiée avec Gemini CLI installé.

La valeur pratique est claire : les tests, la refactorisation ou l'analyse en masse de code se poursuivent même après la fermeture de l'ordinateur portable. L'auteur décrit un flux de travail typique : les agents travaillent sur une branche séparée, effectuent des commits, poussent les résultats, et le matin le développeur ouvre simplement une pull request et examine le résultat.

Contexte et Contrôle

Un autre détail utile est le passage du contexte entre les agents via les sessions intégrées de Gemini CLI. Un worker peut terminer une recherche, enregistrer la session_id, et le suivant peut reprendre la même conversation et continuer sans rereconter ce qui a été trouvé. Pour les chaînes longues, cela économise les tokens et réduit les erreurs aux limites d'étape : le deuxième agent voit non pas un résumé sec, mais l'historique complet de l'analyse.

Les sessions actives peuvent être visualisées séparément et connectées manuellement si nécessaire. Il y a aussi une couche de restrictions nécessaire pour le vrai travail d'équipe. Via policy, vous pouvez donner à un agent un mode lecture seule ou une édition sécurisée sans droit d'exécuter des commandes.

Si cela ne suffit pas, les règles sont définies avec plus de précision via un fichier YAML séparé. Le paramètre include_dirs complète ce modèle : par défaut un worker ne voit que le répertoire de travail, et l'accès aux configurations externes ou dossiers supplémentaires doit être explicitement activé. Cette approche rend l'automatisation considérablement plus sûre qu'un accès complet sans conditions à tout le projet.

Enfin, agent-pool introduit les groupes—essentiellement des modèles pour les équipes fractales. Vous pouvez enregistrer une fois un runner, une skill, une policy et une limite max_agents dans un groupe, puis envoyer plusieurs exécuteurs à partir de celui-ci sans dupliquer les paramètres. Ces groupes sont enregistrés entre les redémarrages de l'IDE et sont directement connectés aux pipelines.

Si une étape doit s'exécuter en parallèle, le daemon lancera plusieurs agents, distribuera les indices et attendra un résultat commun. Le fail-fast s'applique : si un worker échoue avec une erreur ou envoie un bounce-back, les autres processus sont immédiatement annulés pour éviter de gaspiller du temps et des ressources.

Ce Que Cela Signifie

Pour les développeurs, c'est un signal qu'AgentOps passe du niveau des expériences au niveau des outils quotidiens. Lorsque les pipelines, le planificateur, les runners distants et le contrôle d'accès se réunissent autour d'un seul abonnement Google AI, les scénarios multi-agents deviennent non pas une démonstration, mais une infrastructure fonctionnelle pour le code, les tests et l'automatisation de routine.