I Suoi agenti sono inattivi. La Sua bolletta Kubernetes no.

Che cos'è Agent Substrate

Agent Substrate è un runtime di esecuzione per agenti secure-by-default, progettato per eseguire milioni di sandbox con una densità 10 volte superiore rispetto ai runtime container standard, con ripristino in meno di 500 ms e oltre 500 attivazioni di suspend/resume al secondo. L'isolamento è garantito da gVisor per impostazione predefinita, con una classe di sandbox micro-VM opzionale (Kata Containers più Cloud Hypervisor) per i workloads che richiedono un isolamento più rigoroso.

L'idea centrale è il multiplexing. Substrate mappa un gran numero di actor, le istanze degli agenti, su un pool molto più ridotto di worker, le sandbox che li eseguono effettivamente, partendo dal presupposto che i workloads di tipo agente trascorrano la maggior parte del tempo inattivi.

Alcuni termini utili da conoscere per orientarsi nel resto:

• Actor: un'istanza in esecuzione di un agente
• ActorTemplate: il blueprint immutabile (immagine container, environment, policy di snapshot) usato per creare gli actor di una determinata versione
• Worker: il pod sandbox in cui viene eseguito un actor attivo
• WorkerPool: una flotta di worker pre-riscaldati pronti a ricevere un actor
• Atespace: un raggruppamento simile a un namespace in cui vivono actor e template

Il motivo per cui questo approccio raggiunge una densità molto maggiore rispetto a un Pod per agente è che Substrate toglie il control plane di Kubernetes dal percorso critico. Kubernetes continua a effettuare il provisioning e a gestire i Pod sottostanti; Substrate semplicemente non fa passare ogni ciclo di suspend e resume attraverso lo scheduling dei Pod. Se ne occupa direttamente il suo control plane: ateapi per il ciclo di vita di actor e worker, atecontroller che riconcilia i WorkerPool, atenet per DNS e routing, atelet in esecuzione come DaemonSet a livello di nodo.

Agent Substrate funziona con qualsiasi framework che produca container OCI standard. Il progetto elenca pattern di integrazione per Agent Development Kit, LangChain e Claude Code. Non è un framework per agenti né un SDK: è il substrato su cui poggiano.

Perché vale la pena affrontarne la complessità

Il codice non attendibile, che sia generato dall'AI o una singola chiamata a un tool, viene eseguito all'interno di un isolamento a livello di kernel e di rete senza esporre il resto del cluster. La memoria di lavoro e i file di un actor persistono attraverso i cicli di sospensione, quindi l'actor riprende esattamente da dove si era fermato invece di ripartire da zero. Il ripristino è abbastanza veloce, una frazione di secondo, da mantenere una latenza di risposta accettabile anche per agenti rivolti alle persone e con attività a raffiche. E poiché un pool condiviso di worker caldi serve molti actor, non si paga per capacità di calcolo che gli actor inattivi non stanno usando.

Questa combinazione si adatta bene a un insieme specifico di workloads. Gli assistenti in background che mantengono il contesto per giorni ma sono attivi solo in brevi raffiche ottengono la maggior parte dei risparmi dalla sospensione tra una raffica e l'altra. Le sandbox usa e getta per eseguire codice non attendibile generato da LLM beneficiano del ripristino in meno di un secondo: se ne avvia una, si esegue il task, la si rilascia, senza un cold boot completo ogni volta. Gli agenti di coding che mantengono un botta e risposta in tempo reale con uno sviluppatore conservano intatto lo stato del terminale e del filesystem tra un prompt e l'altro, mentre il cluster spende risorse di calcolo solo per gli sviluppatori effettivamente attivi.

Come fluisce effettivamente una richiesta

Quando un actor viene creato da un template, Substrate avvia un "golden pod" temporaneo, esegue una sola volta la logica di avvio del container e cattura un golden snapshot nel momento in cui l'inizializzazione è completata. Ogni actor successivo di quel template riprende da quello snapshot invece di avviarsi a freddo: ecco perché l'inizializzazione costosa (caricare un modello, aprire le connessioni di base) va messa nell'entry point e non in un punto in cui verrebbe ripetuta a ogni risveglio.

Una precisazione doverosa: al momento Substrate non rileva autonomamente l'inattività. La sospensione viene attivata da una chiamata API esplicita da parte del sistema che orchestra gli actor, non da Substrate che osserva l'attività e decide da sé.

Come configurarlo: WorkerPool e ActorTemplate

Le risorse di Substrate sono CRD Kubernetes sotto il gruppo API ate.dev/v1alpha1, quindi si inseriscono in un normale flusso GitOps. Due risorse fanno la maggior parte del lavoro.

Un WorkerPool definisce la capacità fisica: quanti pod caldi tenere in standby, quale runtime sandbox utilizzano ed eventuali regole di posizionamento sui nodi.

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 definisce il workload vero e proprio: il suo container, dove vengono archiviati gli snapshot e su quali worker pool è autorizzato a girare.

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/

Alcuni dettagli da conoscere prima di scrivere il proprio. Le immagini container devono essere bloccate tramite digest, perché cambiare l'immagine invalida gli snapshot esistenti. La probe readyz è facoltativa ma vale la pena impostarla: condiziona sia il cold boot sia il ripristino al fatto che il workload sia effettivamente pronto a servire traffico, non solo avviato. E ogni nuova versione dell'agente dovrebbe avere il proprio ActorTemplate (research-agent-v2, e così via), perché Substrate tratta un template come una radice di stato immutabile e non come qualcosa da modificare in place.

Una volta che il template raggiunge lo stato Ready, si crea logicamente un actor con la CLI:

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

e questo riprende su qualsiasi worker libero del pool referenziato nel momento in cui arriva una richiesta.