Google publie en open source Scion, un banc d’essai expérimental d’orchestration d’agents

• Plateforme expérimentale conçue pour gérer des agents basés sur des LLM s’exécutant simultanément dans des conteneurs, sur des machines locales comme sur des clusters distants
• Chaque agent fonctionne comme un processus isolé avec une identité, des identifiants et un espace de travail propres, afin de poursuivre de façon dynamique et parallèle divers objectifs comme le code, l’audit ou les tests
• Défini comme un « hyperviseur pour agents », le projet adopte une philosophie d’isolation externe via des conteneurs, des git worktrees et des politiques réseau, plutôt que d’injecter des règles de comportement dans le contexte
• Intègre les principaux agents comme Gemini CLI, Claude Code, OpenCode et Codex via des adaptateurs harness, avec prise en charge de Docker, Podman, Apple Container et Kubernetes comme runtimes
• Suit le cycle de vie des agents (Phase), leur comportement actuel (Activity) et leur état détaillé (Detail) via un modèle d’état en trois dimensions, et démontre des scénarios collaboratifs sur une base de code de jeu de démonstration

---

Qu’est-ce que Scion ?

• Banc d’essai expérimental d’orchestration qui gère des groupes d’agents basés sur des LLM s’exécutant simultanément dans des conteneurs, sur des machines locales, des VM distantes et des clusters Kubernetes
• Attribue à chaque agent une identité, des identifiants et un espace de travail indépendants, afin d’exécuter des objectifs différents comme la recherche, le code, l’audit ou les tests sous la forme d’un graphe de tâches parallèles à évolution dynamique
• Google définit Scion comme un « hyperviseur pour agents », qui unifie la mémoire des agents, les salons de discussion et la gestion des tâches comme des préoccupations indépendantes (orthogonales)

Philosophie de conception centrale : l’isolation plutôt que la restriction

• Au lieu de limiter le comportement des agents par des règles, la sécurité est assurée par des frontières au niveau de l’infrastructure, comme les conteneurs, les git worktrees et les politiques réseau
• Les agents peuvent s’exécuter librement en mode --yolo, tandis que la couche d’isolation joue le rôle de garde-fou depuis l’extérieur
• Cette approche évite d’avoir à injecter des règles complexes dans le contexte des agents, ce qui leur permet de se concentrer uniquement sur leur tâche

Concepts clés (glossaire)

Scion utilise sa propre terminologie ; il faut donc d’abord comprendre les concepts ci-dessous

• Agent : processus isolé qui exécute une boucle LLM + Harness. C’est l’unité d’exécution de base de Scion, avec une identité, des identifiants et un espace de travail indépendants
• Grove : espace de travail de projet dans lequel les agents existent. Correspond au répertoire .scion du système de fichiers, et peut se trouver à la racine d’un dépôt git ou dans le dossier personnel de l’utilisateur
  • Les Grove basés sur git utilisent UUID v5 (généré de façon déterministe à partir de l’URL du dépôt), tandis que les Grove natifs du Hub utilisent UUID v4
• Hub : plan de contrôle central de l’architecture Scion hébergée. Il joue le rôle de « cerveau » en coordonnant l’état entre les utilisateurs, les Grove et les brokers de runtime
  • Gère l’identité et l’authentification basées sur OAuth, stocke dans une base centrale l’état des agents, Grove et templates, distribue les commandes du cycle de vie et fournit une vue collaborative via un tableau de bord web
• Profile : spécification d’environnement d’exécution qui regroupe les paramètres d’un runtime et d’un Harness. Pour passer d’un environnement à un autre comme « Local Docker » ou « Production Kubernetes », il suffit de changer le Profile sans modifier le template
• Harness : adaptateur qui intègre un outil LLM spécifique, comme Gemini CLI, Claude Code ou Codex, dans l’écosystème Scion. Il garantit que les commandes génériques Scion comme start, stop, attach et resume fonctionnent de manière cohérente avec n’importe quel agent
• Template : modèle de création d’agent. Il définit la configuration par défaut, le prompt système et les outils, et est stocké dans .scion/templates/
  • En plus des templates fournis (gemini, claude, opencode, codex), il est possible de créer des templates de rôles personnalisés comme « auditeur sécurité » ou « expert React »
• Runtime : couche d’infrastructure qui exécute les conteneurs des agents. Prend en charge Docker, Podman, Apple Container et Kubernetes
• Runtime Broker : nœud de calcul (serveur, ordinateur portable, cluster K8s) enregistré auprès du Hub pour fournir de la capacité d’exécution. Il prend en charge la gestion du cycle de vie des agents, la synchronisation des espaces de travail et le streaming des logs

Architecture : structure Manager-Worker

• scion CLI : outil côté hôte qui orchestre le cycle de vie des agents. Il fournit aussi la gestion des Grove (espaces de travail de projet) et celle des templates (scion templates)
• Agents : exécutent des logiciels d’agent comme Gemini CLI, Claude Code et Codex dans des conteneurs runtime isolés tels que Docker
• Flux d’utilisation de base :
  1. scion init — crée le répertoire .scion à la racine du projet
  2. scion start <agent-name> "<task>" — lance un agent
  3. scion attach <agent-name> — se connecte de manière interactive à une session d’agent, ou consulte la sortie avec scion logs
  4. scion resume <agent-name> — redémarre un agent interrompu en conservant son état

Stratégie d’espace de travail : isolation via git

Il existe deux méthodes pour attribuer à chaque agent un espace de travail git indépendant

• Mode local — Git Worktrees : utilisé lors d’une exécution sans Hub
  • Crée un worktree avec une branche dédiée dans ../.scion_worktrees/<grove>/<agent>
  • Monté dans /workspace à l’intérieur du conteneur, il partage l’historique du même dépôt tout en conservant un répertoire de travail indépendant
  • Une fois le travail terminé, la fusion se fait manuellement avec git merge <agent-branch>
• Mode Hub — Git Init + Fetch : appliqué quand le Hub est utilisé
  • Le broker injecte SCION_GIT_CLONE_URL, SCION_GIT_BRANCH et GITHUB_TOKEN dans le conteneur
  • Dans le conteneur, sciontool init initialise l’espace de travail, récupère le dépôt en HTTPS, puis extrait la branche scion/<agent-name>
  • Les identifiants SSH de l’hôte ne sont pas nécessaires, mais GITHUB_TOKEN est requis
  • Garantit un comportement cohérent sur toutes les machines broker, que le dépôt soit ou non présent localement

Mécanismes d’isolation des ressources

• Système de fichiers : montage d’un répertoire personnel dédié à chaque agent dans le conteneur
• Shadow Mounts (tmpfs) : l’accès aux données de configuration .scion ou aux espaces de travail d’autres agents est bloqué via des shadow mounts tmpfs
• Identifiants : les identifiants sensibles, comme l’authentification gcloud, sont exposés de manière limitée à l’agent concerné uniquement, via un montage en lecture seule ou une injection par variable d’environnement
• Externalisation des données Grove : les données Grove non git et les répertoires personnels des agents sont externalisés, empêchant un agent de parcourir les données d’autres agents depuis l’espace de travail

Modèle d’état des agents (3 dimensions)

L’état des agents est suivi selon trois dimensions afin de distinguer les événements d’infrastructure de l’état cognitif de l’agent

• Phase (étape du cycle de vie) : created → provisioning → cloning → starting → running → stopping → stopped (ou error)
• Activity (comportement de l’agent pendant running) : idle, thinking, executing, waiting_for_input, blocked, completed, limits_exceeded, offline
  • completed, blocked et limits_exceeded sont des états « sticky », conservés jusqu’à ce que l’agent soit explicitement redémarré ou arrêté
  • blocked est défini par l’agent lui-même pour indiquer qu’il attend la fin d’un sous-agent, ce qui évite au système de le confondre avec une erreur
  • offline survient lorsqu’aucun heartbeat de l’agent n’est détecté pendant un certain temps ; cela peut être dû à un échec de renouvellement du jeton d’authentification
• Detail : contexte additionnel de l’Activity en cours (nom de l’outil, message, résumé de tâche, etc., en format libre)

Système de plugins

• Architecture de plugins basée sur hashicorp/go-plugin, permettant d’étendre le système, avec communication en gRPC
• Plugins de broker de messages : fournissent des backends personnalisés pour les notifications d’agents et la messagerie structurée
• Plugins de harness d’agent : permettent d’implémenter des harness personnalisés pour intégrer de nouveaux outils LLM dans Scion sans modifier le code de base
• Le projet est actuellement à un stade initial (foundational stage), avec des implémentations de référence fournies pour les deux types de plugins