7 points clés sur AX, le runtime d’orchestration d’agents de Google

Les agents autonomes posent un problème d’infrastructure inédit : ils accumulent de l’état, sollicitent des API externes et risquent de consommer des ressources en boucle sans surveillance.

Pour répondre à ces contraintes, Google a lancé AX, un orchestrateur déclaratif à haut débit conçu pour exécuter des milliards de tâches d’agents sandboxées au sein d’un cluster via Agent Substrate. Voici les 7 caractéristiques clés à connaître pour maîtriser ce runtime open source.

1. Une architecture déclarative pensée pour des milliards d’agents

Les agents ne se comportent ni comme des microservices sans état, ni comme de simples tâches batch qui s’exécutent jusqu’à leur terme. Ils conservent un état au fil de leurs réflexions, nécessitent une isolation stricte, interrogent des API de modèles ou des serveurs d’outils, et peuvent tourner en boucle indéfiniment si aucune limite n’est fixée.

AX résout ce problème en introduisant un orchestrateur à haut débit conçu pour exécuter des milliards de charges de travail autonomes par cluster. Le système fonctionne au-dessus d’Agent Substrate, qui fournit l’environnement d’exécution isolé (bac à sable).

Pour les habitués de Kubernetes, l’approche est familière :

• Toutes les ressources se définissent via des manifestes déclaratifs sous le groupe d’API ax.io/v1alpha1.
• Chaque ressource est cloisonnée dans un espace d’isolation nommé atespace (l’espace par défaut est default).
• Le projet est distribué sous licence open source Apache License 2.0.

2. Quatre primitives déclaratives pour structurer les workloads

Plutôt que d’enfermer le comportement de l’agent dans un bloc monolithique, AX sépare les responsabilités en quatre primitives configurables via un fichier YAML appliqué en une seule commande :

Action recherchée	Primitive AX
Exécuter du code d’agent non approuvé dans un bac à sable isolé avec limites CPU et mémoire	Task
Pré-câbler des dépôts Git, des serveurs MCP et des compétences pour démarrer à chaud	Workspace
Verrouiller le trafic sortant sur une liste explicite d’hôtes autorisés	Gateway
Configurer le LLM utilisé par la plateforme avec des identifiants issus d’un secret Kubernetes	Model

La Task représente la plus petite unité d’exécution isolée. Elle déclare l’image de conteneur, la commande à lancer, les quotas de calcul, les variables d’environnement, ainsi que les références aux Workspaces et à la Gateway. AX garde cette unité délibérément légère : au cours de son existence, un agent planifie, délègue, retente et distribue ses opérations. Une tâche peut représenter l’intégralité du travail ou servir de racine à un arbre de tâches secondaires créées au fur et à mesure.

La ressource Model n’est pas le modèle lui-même, mais sa configuration centralisée (fournisseur, identifiant comme gemini-3.8-flash, paramètres de génération comme la température, et référence au secret Kubernetes pour la clé API). Cela évite de disperser les clés d’API dans chaque conteneur et simplifie la rotation des accès à l’échelle du cluster.

3. Les Workspaces : préparation de l’environnement et bootstrap par objectif

Préparer l’environnement d’un agent avant sa première action est souvent fastidieux : clonage de dépôts au bon commit, montage de volumes, enregistrement des outils et compétences. Le Workspace mutualise ce travail de manière déclarative.

Défini une seule fois, il peut être rattaché à plusieurs tâches sous spec.workspaces. Le moteur AX matérialise son contenu avant le démarrage de la commande :

• Clonage de dépôts Git dans des sous-répertoires spécifiques (par exemple le dépôt golang/go sur la branche my-fix).
• Connexion aux registres et serveurs MCP (Model Context Protocol).
• Mise à disposition de répertoires de compétences (skills).

Chaque workspace est monté sur son propre chemin, le premier servant de répertoire de travail (working directory) pour la commande de la tâche.

Configuration par objectif (goal) : La liaison d’un workspace peut comporter un champ goal rédigé en langage naturel (par exemple : s’assurer que la chaîne d’outils Go est compilée depuis les sources). Au premier démarrage, le runner transmet cet objectif à un agent Antigravity chargé d’achever la configuration du système. Cet agent requiert la variable GEMINI_API_KEY dans le conteneur et dispose par défaut d’un délai de 10 minutes (modifiable via AX_BOOTSTRAP_TIMEOUT). La tâche ne passe à l’état prêt qu’une fois ce bootstrap achevé.

4. Les Gateways : une frontière réseau stricte pour limiter le trafic sortant

La ressource Gateway agit comme un pare-feu dédié au bac à sable de la tâche. Elle garantit qu’un agent autonome ne peut pas contacter arbitrairement l’extérieur ou exfiltrer des données.

Elle configure deux éléments fondamentaux :

• Listeners : Les ports exposés par la tâche (par exemple 8494/gRPC ou 8080/HTTP).
• Egress allowlist : Une liste stricte d’hôtes et de ports accessibles depuis le bac à sable.

Grâce à ce mécanisme, le trafic réseau peut être limité exclusivement aux serveurs d’API du fournisseur de LLM et aux forges logicielles indispensables. La connectivité avec la tâche en cours d’exécution passe ensuite par le routeur atenet, accessible depuis le cluster, un poste local ou un client gRPC direct.

5. Le contrôle du cycle de vie : suspension, reprise et conditions d’état

Le statut d’une tâche est résumé par status.phase (valeurs possibles : Running, Suspended, Failed, Terminating). La précision sur son avancement provient de ses conditions :

Condition	État True lorsque…
WorkspaceReady	Tous les workspaces ont terminé leur initialisation. Reste à True par la suite.
GatewayReady	Les règles réseau de la passerelle ont été appliquées au bac à sable.
Ready	La tâche est en cours d’exécution et WorkspaceReady est à True. C’est l’indicateur principal de disponibilité.

Deux commandes permettent de gérer l’exécution sans détruire l’état de l’agent :

• ax suspend task <nom> : fige l’état de l’acteur (checkpoint) et suspend la tâche. La condition Ready passe à False avec le motif TaskSuspended.
• ax resume task <nom> : relance l’agent exactement là où il s’était arrêté et repasse la condition Ready à True.

Lors de la suppression via ax delete task <nom>, la tâche entre en phase Terminating pendant le démantèlement du bac à sable, puis disparaît. La commande reste bloquante jusqu’à la libération effective des ressources.

6. L’exécution interne du bac à sable supervisée par ax-task-runner

Chaque conteneur de tâche est démarré avec le binaire ax-task-runner en tant que PID 1. Dès l’initialisation, il orchestre les étapes suivantes :

1. Chargement des spécifications de la tâche et des workspaces associés.
2. Démarrage d’un démon local sur le port 80 (prenant en charge HTTP/1.1 et h2c) pour la gestion des métadonnées et des services invités.
3. Préparation des workspaces dans l’ordre de déclaration (clonage Git, injection des compétences et exécution d’Antigravity si un objectif est défini).
4. Lancement du processus enfant défini par spec.command, avec injection de la variable AX_METADATA_URL et des variables spécifiées dans spec.env.

Le runner reste actif en PID 1 même si la commande enfant s’arrête. Cela permet de consulter les métadonnées et de conserver l’accès SSH. Le code de sortie de la commande est consigné dans les journaux. En cas d’arrêt ou de mise en pause, le runner envoie un signal SIGTERM au groupe de processus, attend 10 secondes, puis applique un SIGKILL aux processus restants.

Les agents peuvent inspecter leur propre configuration sans dépendre d’un SDK spécifique en interrogeant le serveur de métadonnées local via AX_METADATA_URL (ex: http://127.0.0.1:80) :

Point d’entrée	Méthode	Type de retour	Rôle
/healthz	GET	text/plain	Vérification de vie (renvoie toujours 200 OK).
/readyz	GET	text/plain	Vérification d’état (503 durant l’initialisation, 200 dès que les dépôts, serveurs MCP et compétences sont prêts).
/metadata/v1alpha1/ax/task	GET	application/yaml	Spécification complète et statut en direct de la tâche courante.
/metadata/v1alpha1/ax/workspaces	GET	application/yaml	Flux multi-documents de tous les workspaces rattachés.

Depuis l’intérieur d’un bac à sable, la commande suivante permet de récupérer la configuration active :

curl -s "$AX_METADATA_URL/metadata/v1alpha1/ax/task"

7. Un outillage calqué sur kubectl avec services de débogage intégrés

Le binaire CLI ax communique avec le plan de contrôle en gRPC et reprend les verbes usuels de l’écosystème Kubernetes : apply, get, describe, watch et delete.

Pour observer et intervenir directement sur les conteneurs :

• ax watch task <nom> permet de suivre en temps réel les changements de phases et de conditions.
• ax ssh <nom> ouvre un shell interactif dans le bac à sable.
• ax ssh <nom> -- ls -la /workspace exécute une commande ponctuelle sans ouvrir de session interactive.

Condition requise pour SSH : L’accès interactif nécessite l’activation explicite de spec.debug: true sur la tâche. Cette option démarre les services invités (Guest services) d’Agent Substrate en gRPC sur le port 80 : le service de processus (qui gère l’exécution et l’arrêt) et le service de système de fichiers (lecture et écriture en flux continu). Ces services sont désactivés par défaut pour des raisons de sécurité car ils autorisent l’exécution arbitraire de code.

Le CLI s’adapte automatiquement au contexte Kubernetes actif via kubectx, créant les tunnels réseau nécessaires en arrière-plan (état stocké dans ~/.ax/tunnels) :

Drapeau global	Description	Valeur par défaut
-a, --atespace	Périmètre d’atespace ciblé par la commande	default
-n, --namespace	Namespace Kubernetes où AX est déployé	ax-system
--context	Contexte Kubernetes ciblé	Contexte actif (current-context)
--server	Adresse directe du plan de contrôle	Dérivée du contexte ou variable $AX_SERVER

Pour déployer AX :

1. Installez le CLI : go install github.com/google/ax/cmd/ax@latest (le binaire se place dans $(go env GOPATH)/bin).
2. Préparez les prérequis : un cluster Kubernetes, l’outil ko, un registre de conteneurs accessible et une API Agent Substrate Control joignable (adresse par défaut dans le cluster : api.ate-system.svc.cluster.local:443).
3. Déployez le plan de contrôle avec make deploy AX_IMAGE_REPO=<votre-registre>. Cela installe Redis puis déploie les composants dans le namespace ax-system.

Un script de démonstration complet, ./demo.sh, permet de tester le cycle de bout en bout : montage d’un workspace personnalisé, attente de l’état prêt, exécution d’instructions via ax ssh et mise en pause de la tâche.