Présentation du système AX

AX, développé par Google, propose un plan de contrôle déclaratif dédié à l’exécution d’agents autonomes. Le projet expose quatre primitives – Task, Workspace, Gateway et Model – qui permettent de déclarer, isoler et gérer des agents sans recourir à des micro‑services classiques ou à des jobs batch. Chaque tâche s’exécute dans un sandbox limité en CPU et en mémoire, ce qui garantit une isolation stricte tout en restant peu coûteux à créer, suspendre ou supprimer.

apiVersion: ax.io/v1alpha1
kind: Workspace
metadata:
  name: golang
spec:
  git:
  - repo: https://github.com/golang/go.git
    branch: "my-fix"
---
apiVersion: ax.io/v1alpha1
kind: Task
metadata:
  name: test
spec:
  workspaces:
  - name: golang
  goal: "Ensure that Go tool chain is available and is built from source"
  debug: true

Les commandes ax apply -f task.yaml, ax watch task test ou ax ssh test -- ls /workspace illustrent le flux complet : création du workspace, lancement de la tâche, inspection interactive et contrôle du cycle de vie (suspend, resume, delete).

Architecture et primitives

AX s’appuie sur Agent Substrate, un runtime conçu pour la densité massive et la gestion rapide du cycle de vie d’acteurs stateful. Chaque tâche devient un acteur léger, ce qui permet à un même nœud de partager ses ressources entre des dizaines de tâches. La primitive Workspace décrit les dépôts Git, les serveurs MCP et les compétences nécessaires ; le système prépare automatiquement l’environnement avant le démarrage de la tâche. Gateway applique des politiques réseau explicites, limitant le trafic à une liste blanche d’hôtes et de ports et injectant les identifiants requis. Enfin, Model centralise la configuration des modèles d’IA, leurs paramètres et leurs secrets, facilitant le remplacement d’une version de modèle par une simple opération apply.

Scalabilité et performances

Le texte indique que AX peut gérer « billions de tâches » simultanément par cluster, grâce à la combinaison de deux mécanismes. Premièrement, la suspension sous‑seconde met en pause les agents en attente de réponses de modèle, d’outils externes ou d’intervention humaine, puis les reprend en moins d’une seconde sans délai de démarrage à froid. Deuxièmement, le multiplexage dense exploite les intervalles d’inactivité des agents pour exécuter d’autres tâches sur les mêmes ressources CPU, réduisant ainsi le coût d’opération à l’unité active. Cette approche contraste avec les orchestrateurs traditionnels, qui facturent les sandboxes même lorsqu’elles restent inactives.

Limites et perspectives

Bien que la documentation souligne la capacité à exécuter des charges de travail « bursty » et à grande densité, aucune métrique précise (latence moyenne, consommation mémoire par acteur, taux d’erreur) n’est fournie. L’absence de chiffres empêche d’évaluer la viabilité économique dans des environnements de production à très grande échelle. De plus, la dépendance à Agent Substrate implique que les utilisateurs doivent accepter une couche d’abstraction supplémentaire, ce qui peut compliquer le diagnostic de problèmes de bas niveau. Enfin, la gestion des secrets via la primitive Model repose sur des mécanismes internes non détaillés, soulevant des questions de conformité pour les organisations soumises à des exigences de sécurité strictes.