Tus agentes están inactivos. Tu factura de Kubernetes, no.

Qué es Agent Substrate

Agent Substrate es un runtime de ejecución de agentes seguro por defecto, diseñado para ejecutar millones de sandboxes con 10 veces la densidad de los runtimes de contenedores estándar, con reanudación en menos de 500 ms y más de 500 activaciones de suspensión/reanudación por segundo. El aislamiento lo proporciona gVisor de forma predeterminada, con una clase de sandbox opcional de micro-VM (Kata Containers más Cloud Hypervisor) para workloads que necesitan un aislamiento más estricto.

La idea central es el multiplexado. Substrate asigna una gran cantidad de actores —tus instancias de agentes— a un pool mucho más pequeño de workers —los sandboxes que realmente los ejecutan—, bajo el supuesto de que los workloads tipo agente pasan la mayor parte del tiempo inactivos.

Algunos términos que conviene conocer antes de que todo lo demás encaje:

• Actor: una instancia en ejecución de un agente
• ActorTemplate: el modelo inmutable (imagen de contenedor, entorno, política de snapshots) que se usa para crear actores de una versión determinada
• Worker: el pod sandbox donde se ejecuta un actor activo
• WorkerPool: una flota de workers precalentados listos para recibir un actor
• Atespace: una agrupación similar a un namespace donde viven los actores y las plantillas

La razón por la que esto puede funcionar con mucha más densidad que un Pod por agente es que Substrate saca al control plane de Kubernetes de la ruta crítica. Kubernetes sigue aprovisionando y gestionando los Pods subyacentes; Substrate simplemente no enruta cada ciclo de suspensión y reanudación por el scheduling de Pods. Su propio control plane lo maneja directamente: ateapi para el ciclo de vida de actores y workers, atecontroller reconciliando WorkerPools, atenet para DNS y enrutamiento, atelet ejecutándose como un DaemonSet a nivel de nodo.

Agent Substrate funciona con cualquier framework que produzca contenedores OCI estándar. El proyecto lista patrones de integración para Agent Development Kit, LangChain y Claude Code. No es un framework de agentes ni un SDK en sí mismo, sino el sustrato sobre el que se apoya uno.

Por qué vale la pena la complejidad

El código no confiable, ya sea generado por IA o una llamada puntual a una herramienta, se ejecuta dentro de un aislamiento de kernel y de red sin exponer el resto del clúster. La memoria de trabajo y los archivos de un actor persisten a través de los ciclos de suspensión, así que se reanuda exactamente donde se pausó en lugar de empezar de cero. La restauración es lo bastante rápida —una fracción de segundo— como para que la latencia de respuesta se mantenga aceptable incluso en agentes intermitentes que interactúan directamente con personas. Y como un pool compartido de workers precalentados atiende a muchos actores, no pagas por cómputo que los actores inactivos no están usando.

Esa combinación encaja bien con un conjunto específico de workloads. Los asistentes en segundo plano que mantienen contexto durante días pero solo están activos en ráfagas cortas obtienen la mayor parte de su ahorro al suspenderse entre esas ráfagas. Los sandboxes desechables para ejecutar código no confiable generado por LLMs se benefician de la restauración en menos de un segundo: levantas uno, ejecutas la tarea y lo liberas, sin un arranque en frío completo cada vez. Los agentes de código que mantienen un intercambio en tiempo real con un desarrollador conservan intacto el estado de su terminal y su sistema de archivos entre prompts, mientras el clúster solo gasta cómputo en los desarrolladores que realmente están activos.

Cómo fluye realmente una solicitud

Cuando se crea un actor a partir de una plantilla, Substrate levanta un "golden pod" temporal, ejecuta la lógica de arranque de tu contenedor una sola vez y toma un golden snapshot en cuanto queda inicializado. Cada actor posterior de esa plantilla se reanuda desde ese snapshot en lugar de arrancar en frío, y por eso la inicialización costosa (cargar un modelo, abrir conexiones base) debe ir en tu punto de entrada y no en un lugar donde se repita en cada reactivación.

Una salvedad que vale la pena señalar: por ahora Substrate no detecta la inactividad por sí solo. La suspensión se activa mediante una llamada explícita a la API desde el sistema que orquesta los actores, no porque Substrate observe la actividad y decida por su cuenta.

Cómo configurarlo: WorkerPool y ActorTemplate

Los recursos de Substrate son CRDs de Kubernetes bajo el grupo de API ate.dev/v1alpha1, así que encajan en un flujo GitOps normal. Dos recursos hacen la mayor parte del trabajo.

Un WorkerPool define la capacidad física: cuántos pods precalentados mantener en espera, qué runtime de sandbox usan y las reglas de ubicación en los nodos.

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 define el workload en sí: su contenedor, dónde se almacenan los snapshots y en qué worker pools puede ejecutarse.

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/

Algunos detalles que conviene conocer antes de escribir el tuyo. Las imágenes de contenedor deben fijarse por digest, ya que cambiar la imagen invalida los snapshots existentes. La probe readyz es opcional pero vale la pena configurarla: condiciona tanto el arranque en frío como la restauración a que tu workload esté realmente listo para atender tráfico, no solo a que haya arrancado. Y cada nueva versión de tu agente debería tener su propio ActorTemplate (research-agent-v2, y así sucesivamente), ya que Substrate trata una plantilla como una raíz de estado inmutable y no como algo que se modifica directamente.

Una vez que la plantilla llega a Ready, creas un actor de forma lógica con la CLI:

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

y se reanuda en cualquier worker libre del pool referenciado en cuanto llega una solicitud.