Vos agents sont inactifs. Pas votre facture Kubernetes.

Qu'est-ce qu'Agent Substrate ?

Agent Substrate est un runtime d'exécution d'agents sécurisé par défaut, conçu pour faire tourner des millions de sandboxes à une densité 10 fois supérieure à celle des runtimes de conteneurs standard, avec une reprise en moins de 500 ms et plus de 500 activations suspend/resume par seconde. L'isolation repose sur gVisor par défaut, avec une classe de sandbox micro-VM optionnelle (Kata Containers plus Cloud Hypervisor) pour les workloads qui exigent une isolation renforcée.

L'idée centrale est le multiplexage. Substrate mappe un grand nombre d'acteurs — vos instances d'agents — sur un pool bien plus réduit de workers, les sandboxes qui les exécutent réellement, en partant du principe que les workloads de type agent passent la majeure partie de leur temps inactifs.

Quelques termes à connaître avant d'aller plus loin :

• Actor : une instance en cours d'exécution d'un agent
• ActorTemplate : le plan immuable (image de conteneur, environnement, politique de snapshot) utilisé pour créer les acteurs d'une version donnée
• Worker : le pod sandbox où s'exécute un acteur actif
• WorkerPool : une flotte de workers préchauffés prêts à recevoir un acteur
• Atespace : un regroupement de type namespace dans lequel vivent acteurs et templates

Si cette approche atteint une densité bien supérieure au modèle d'un Pod par agent, c'est parce que Substrate retire le control plane Kubernetes du chemin critique. Kubernetes continue de provisionner et de gérer les Pods sous-jacents ; Substrate ne fait simplement pas transiter chaque cycle de suspension et de reprise par le scheduling des Pods. Son propre control plane s'en charge directement : ateapi pour le cycle de vie des acteurs et des workers, atecontroller pour la réconciliation des WorkerPools, atenet pour le DNS et le routage, atelet exécuté en DaemonSet au niveau des nœuds.

Agent Substrate fonctionne avec tout framework produisant des conteneurs OCI standard. Le projet documente des patterns d'intégration pour l'Agent Development Kit, LangChain et Claude Code. Ce n'est ni un framework d'agents ni un SDK en soi, mais le substrat qui les sous-tend.

Pourquoi cette complexité en vaut la peine

Le code non fiable, qu'il soit généré par une IA ou issu d'un appel d'outil ponctuel, s'exécute dans une isolation kernel et réseau sans exposer le reste du cluster. La mémoire de travail et les fichiers d'un acteur persistent à travers les cycles de suspension : il reprend exactement là où il s'était arrêté au lieu de repartir de zéro. La restauration est assez rapide — une fraction de seconde — pour que la latence de réponse reste acceptable, même pour des agents à activité sporadique en interaction directe avec des humains. Et comme un pool partagé de workers préchauffés sert de nombreux acteurs, vous ne payez pas pour du calcul que les acteurs inactifs n'utilisent pas.

Cette combinaison convient particulièrement bien à certains workloads. Les assistants d'arrière-plan qui conservent du contexte pendant des jours mais ne sont actifs que par courtes rafales tirent l'essentiel de leurs économies de la suspension entre ces rafales. Les sandboxes jetables destinées à exécuter du code non fiable généré par un LLM profitent de la restauration en moins d'une seconde : en lancer une, exécuter la tâche, la libérer, sans démarrage à froid complet à chaque fois. Les agents de codage qui entretiennent un échange en temps réel avec un développeur conservent l'état de leur terminal et de leur système de fichiers entre deux prompts, tandis que le cluster ne dépense du calcul que pour les développeurs réellement actifs.

Le parcours concret d'une requête

Lorsqu'un acteur est créé à partir d'un template, Substrate démarre un golden pod temporaire, exécute une fois la logique de démarrage de votre conteneur et capture un golden snapshot dès la fin de l'initialisation. Chaque acteur ultérieur de ce template reprend depuis ce snapshot plutôt que de démarrer à froid : c'est pourquoi les initialisations coûteuses (chargement d'un modèle, ouverture des connexions de base) ont leur place dans votre point d'entrée, plutôt qu'à un endroit où elles seraient répétées à chaque réveil.

Un point d'attention à signaler : Substrate ne détecte pas encore l'inactivité par lui-même. La suspension est déclenchée par un appel API explicite du système qui orchestre les acteurs, et non par Substrate qui observerait l'activité et déciderait seul.

Configuration : WorkerPool et ActorTemplate

Les ressources Substrate sont des CRD Kubernetes sous le groupe d'API ate.dev/v1alpha1 et s'intègrent donc dans un flux GitOps classique. Deux ressources font l'essentiel du travail.

Un WorkerPool définit la capacité physique : combien de pods préchauffés maintenir en attente, quel runtime de sandbox ils utilisent, et d'éventuelles règles de placement sur les nœuds.

apiVersion: ate.dev/v1alpha1
kind: WorkerPool
metadata:
  name: research-agent-pool
  namespace: ate-demo
spec:
  replicas: 10
  ateomImage: ko://github.com/agent-substrate/substrate/cmd/ateom-gvisor
  # sandboxClass defaults to gvisor; set to microvm for a Kata + Cloud
  # Hypervisor pool if your workload needs stronger isolation.

Un ActorTemplate définit le workload lui-même : son conteneur, l'emplacement de stockage des snapshots et les pools de workers sur lesquels il est autorisé à s'exécuter.

apiVersion: ate.dev/v1alpha1
kind: ActorTemplate
metadata:
  name: research-agent
  namespace: ate-demo
spec:
  pauseImage: "gcr.io/gke-release/pause@sha256:<digest>"
  containers:
  - name: agent
    image: registry.example.com/research-agent@sha256:<digest>
    readyz:
      httpGet:
        path: /readyz
        port: 8080
  sandboxClass: gvisor
  workerSelector:
    matchLabels:
      workload: research-agent
  snapshotsConfig:
    location: gs://my-bucket/snapshots/research-agent/

Quelques détails à connaître avant d'écrire vos propres ressources. Les images de conteneurs doivent être épinglées par digest, car changer d'image invalide les snapshots existants. La sonde readyz est optionnelle mais mérite d'être définie : elle conditionne aussi bien le démarrage à froid que la restauration au fait que votre workload soit réellement prêt à servir du trafic, et pas seulement démarré. Et chaque nouvelle version de votre agent devrait avoir son propre ActorTemplate (research-agent-v2, et ainsi de suite), puisque Substrate traite un template comme une racine d'état immuable plutôt que comme un objet à modifier en place.

Une fois le template passé à l'état Ready, vous créez logiquement un acteur avec la CLI :

kubectl ate create atespace demo
kubectl ate create actor my-agent-1 -a demo --template=research-agent

et il reprend sur n'importe quel worker libre du pool référencé dès qu'une requête arrive.