Seus agentes estão ociosos. Sua conta do Kubernetes, não.

O que é o Agent Substrate

O Agent Substrate é um runtime de execução de agentes seguro por padrão, criado para rodar milhões de sandboxes com 10x a densidade dos runtimes de contêiner convencionais, com retomada em menos de 500 ms e mais de 500 ativações de suspensão/retomada por segundo. O isolamento vem do gVisor por padrão, com uma classe opcional de sandbox micro-VM (Kata Containers com Cloud Hypervisor) para workloads que precisam de um isolamento mais rígido.

A ideia central é a multiplexação. O Substrate mapeia um grande número de actors — suas instâncias de agente — em um pool bem menor de workers — as sandboxes que de fato os executam — partindo do pressuposto de que workloads do tipo agente passam a maior parte do tempo ociosas.

Alguns termos que vale conhecer antes que o resto faça sentido:

• Actor: uma instância em execução de um agente
• ActorTemplate: o blueprint imutável (imagem de contêiner, ambiente, política de snapshot) usado para criar actors de uma determinada versão
• Worker: o pod sandbox onde um actor ativo é executado
• WorkerPool: uma frota de workers pré-aquecidos prontos para receber um actor
• Atespace: um agrupamento semelhante a um namespace onde vivem actors e templates

O motivo de isso conseguir rodar com densidade muito maior do que um Pod por agente é que o Substrate tira o control plane do Kubernetes do caminho crítico. O Kubernetes continua provisionando e gerenciando os Pods subjacentes; o Substrate apenas não roteia cada ciclo de suspensão e retomada pelo agendamento de Pods. Seu próprio control plane cuida disso diretamente: ateapi para o ciclo de vida de actors e workers, atecontroller reconciliando WorkerPools, atenet para DNS e roteamento, atelet rodando como um DaemonSet no nível do nó.

O Agent Substrate funciona com qualquer framework que produza contêineres OCI padrão. O projeto lista padrões de integração para o Agent Development Kit, LangChain e Claude Code. Ele não é um framework de agentes nem um SDK em si, mas o substrato que fica por baixo de um.

Por que vale a complexidade

Código não confiável — seja gerado por IA ou uma chamada de ferramenta pontual — roda com isolamento de kernel e de rede sem expor o resto do cluster. A memória de trabalho e os arquivos de um actor persistem entre ciclos de suspensão, então ele retoma exatamente de onde parou em vez de começar do zero. A restauração é rápida o bastante — fração de segundo — para que a latência de resposta continue aceitável até para agentes com picos de uso e voltados a humanos. E como um pool compartilhado de workers aquecidos atende muitos actors, você não paga por computação que actors ociosos não estão usando.

Essa combinação atende bem a um conjunto específico de workloads. Assistentes em segundo plano que mantêm contexto por dias, mas só ficam ativos em rajadas curtas, obtêm a maior parte da economia suspendendo entre essas rajadas. Sandboxes descartáveis para executar código não confiável gerado por LLM se beneficiam da restauração em menos de um segundo: crie uma, execute a tarefa, libere-a, sem um cold boot completo a cada vez. Agentes de programação que mantêm um vai e vem em tempo real com um desenvolvedor preservam o estado do terminal e do sistema de arquivos entre prompts, enquanto o cluster só gasta computação com desenvolvedores realmente ativos.

Como uma requisição realmente flui pelo sistema

Quando um actor é criado a partir de um template, o Substrate sobe um "golden pod" temporário, executa a lógica de inicialização do seu contêiner uma única vez e tira um golden snapshot assim que ela é concluída. Todo actor subsequente daquele template retoma a partir desse snapshot em vez de inicializar a frio — por isso, inicializações caras (carregar um modelo, abrir conexões básicas) devem ficar no seu entry point, e não em algum lugar onde seriam repetidas a cada despertar.

Uma ressalva que vale destacar: atualmente o Substrate não detecta ociosidade por conta própria. A suspensão é acionada por uma chamada de API explícita do sistema que estiver orquestrando os actors, não pelo Substrate observando a atividade e decidindo sozinho.

Configurando: WorkerPool e ActorTemplate

Os recursos do Substrate são CRDs do Kubernetes sob o grupo de API ate.dev/v1alpha1, então se encaixam em um fluxo GitOps normal. Dois recursos fazem a maior parte do trabalho.

Um WorkerPool define a capacidade física: quantos pods aquecidos manter em prontidão, qual runtime de sandbox eles usam e eventuais regras de posicionamento em nós.

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.

Um ActorTemplate define a workload em si: seu contêiner, onde os snapshots são armazenados e em quais worker pools ele pode rodar.

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/

Alguns detalhes que vale conhecer antes de escrever o seu. As imagens de contêiner precisam ser fixadas por digest, já que alterar a imagem invalida os snapshots existentes. O probe readyz é opcional, mas vale configurar: ele condiciona tanto o cold boot quanto a restauração a que sua workload esteja de fato pronta para atender tráfego, e não apenas iniciada. E cada nova versão do seu agente deve ter seu próprio ActorTemplate (research-agent-v2, e assim por diante), já que o Substrate trata um template como uma raiz de estado imutável, e não como algo que você modifica diretamente.

Quando o template chega ao estado Ready, você cria um actor de forma lógica com a CLI:

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

e ele retoma em qualquer worker livre do pool referenciado assim que uma requisição chegar.