Agent Substrate, gVisor e OpenRL na CNCF: governança e adoção de plataformas de agentes

Uma plataforma corporativa de agentes precisa responder a perguntas que vão além de executar código: quem mantém o runtime, como recuperar uma sessão, quem autoriza uma ação externa e quanto custa abandonar a implementação escolhida?

Em 5 de novembro de 2026, o Google anunciou a doação de Agent Substrate, gVisor e OpenRL à Cloud Native Computing Foundation (CNCF). O comunicado informa que os projetos estão passando pelo onboarding do programa Sandbox e também anuncia Agent Substrate 1.0 e sua disponibilidade geral no Google Kubernetes Engine (GKE). São acontecimentos relacionados, mas não equivalentes: governança comunitária e disponibilidade de um produto gerenciado precisam ser avaliadas separadamente. (cloud.google.com)

Este artigo adota um recorte complementar ao de arquitetura de Agent Substrate, gVisor e OpenRL: como transformar a mudança de governança em critérios de adoção, contratos operacionais e um plano de saída verificável. Não é um tutorial de instalação do conjunto.

1. O que está confirmado — e o que não deve ser presumido

A referência temporal desta análise é 6 de novembro de 2026. É importante distinguir os marcos do processo:

• O projeto gVisor registra a aprovação de sua candidatura em 28 de setembro de 2026 e publicou seu anúncio de doação em 2 de outubro de 2026. A evolução para Incubation aparece como próximo objetivo, não como estágio já alcançado. (gvisor.dev)
• A candidatura de Agent Substrate registra o acordo de contribuição assinado e a criação da tarefa de onboarding em 20 de outubro de 2026. Aprovação, acordo e conclusão da integração institucional são etapas diferentes. (github.com)
• O anúncio conjunto de 5 de novembro de 2026 reúne os três projetos sob a iniciativa de infraestrutura aberta para agentes. (cloud.google.com)

O programa CNCF Sandbox é uma categoria de acolhimento de projetos, não uma certificação de adequação ao seu ambiente de produção. Portanto, a recomendação aqui é não substituir avaliação técnica, requisitos de compliance ou contrato de suporte pela presença de um projeto na fundação. (cncf.io)

2. Três componentes, três decisões de adoção

Não é necessário tratar o conjunto como uma compra indivisível.

Essas responsabilidades estão descritas nas candidaturas e na documentação dos projetos. OpenRL, neste contexto, é o projeto de pós-treinamento associado à candidatura CNCF #518, não uma referência genérica a qualquer biblioteca de reinforcement learning, ou aprendizado por reforço. (github.com)

Minha recomendação: avalie cada camada separadamente. Uma empresa pode precisar de isolamento para execução de código sem operar treinamento próprio. Outra pode precisar de pós-treinamento sem oferecer sessões interativas persistentes aos usuários.

3. O significado estratégico da governança neutra

No anúncio específico do gVisor, a transição contempla governança baseada em mantenedores, participação de mantenedores externos ao Google e mudanças na infraestrutura de testes e builds. Esses elementos são mais relevantes para uma análise de dependência do que simplesmente trocar a organização de um repositório. (gvisor.dev)

A inferência arquitetural é que processos públicos e participação de múltiplas organizações podem reduzir a dependência decisória de um fornecedor. Não significam, por si só, manutenção distribuída, suporte comercial disponível ou integração idêntica em todas as nuvens. O benefício precisa ser acompanhado ao longo do tempo, não presumido na data do anúncio. (gvisor.dev)

Para uma revisão interna, proponho verificar:

1. Autoridade: quem aprova mudanças incompatíveis e releases?
2. Continuidade: quantas organizações conseguem corrigir e publicar o projeto?
3. Segurança: existe processo de divulgação coordenada e política de versões suportadas?
4. Reprodutibilidade: a empresa consegue construir e testar os artefatos necessários?
5. Saída: os dados e procedimentos permitem migrar sem depender exclusivamente do fornecedor original?

Registre as respostas em um Architecture Decision Record (ADR), documento que preserva contexto, alternativas e justificativa da decisão. A doação é um sinal favorável para investigação; a evidência operacional deve determinar a aprovação.

4. Arquitetura de adoção: separar produto, execução e aprendizado

Em vez de repetir o desenho interno dos projetos, proponho o seguinte fluxo de responsabilidade para uma plataforma corporativa:

Produto → autorização e orçamento → admissão da tarefa → execução isolada → evidência durável → avaliação

Nesse desenho proposto:

• Produto: define a intenção e o resultado esperado.
• Autorização e orçamento: decide quais ferramentas, dados e recursos podem ser usados.
• Admissão: aplica limites de concorrência e rejeita trabalho que a plataforma não consegue sustentar.
• Execução: realiza a tarefa dentro da fronteira de isolamento escolhida.
• Evidência durável: registra resultado, identificador da operação e efeitos externos.
• Avaliação: verifica qualidade e, quando houver um programa de treinamento, fornece dados previamente autorizados para esse processo.

Não são APIs nativas inventadas para os projetos: são responsabilidades que recomendo atribuir explicitamente ao produto de plataforma.

O contrato oferecido às equipes consumidoras deve descrever timeout, cancelamento, retenção, identidade, limites e comportamento após falhas. Evite expor detalhes do runtime como se fossem requisitos permanentes do produto.

Portabilidade precisa de um teste de saída

Proponho separar três provas:

• Implantação: instalar a versão fixada em outro ambiente compatível.
• Estado: exportar artefatos e reconstruir uma sessão a partir de dados controlados pela aplicação.
• Operação: reproduzir políticas, auditoria e diagnóstico sem depender de uma interface exclusiva do fornecedor.

Checkpoint/restore é uma capacidade real do gVisor, mas possui requisitos e restrições próprios. A existência dessa função não demonstra que qualquer snapshot seja restaurável entre versões, configurações e plataformas arbitrárias. (gvisor.dev)

Por isso, mantenha um caminho de recuperação baseado em estado lógico: arquivos persistidos, histórico autorizado, resultados e operações idempotentes. Trate o snapshot de memória como otimização sujeita a uma matriz de compatibilidade, não como único formato de sobrevivência do negócio.

5. Exemplo corporativo: agentes que preparam correções

Cenário hipotético: uma empresa quer permitir que agentes analisem incidentes e preparem pull requests. Ações em produção continuam dependendo de aprovação humana.

Problema: o time precisa escolher uma base de execução sem entregar às sessões acesso administrativo ao cluster nem criar uma dependência impossível de substituir.

Solução proposta: separar o serviço que coordena tarefas, os ambientes de execução e o registro durável de operações. PostgreSQL pode guardar o estado transacional da tarefa; armazenamento de objetos pode guardar artefatos e evidências, conforme os requisitos da empresa.

Implementação sugerida:

1. Começar com repositórios de teste e dados sintéticos.
2. Atribuir um identificador estável a cada tarefa e ação externa.
3. Limitar concorrência por equipe e exigir aprovação para operações destrutivas.
4. Executar testes de perda de worker, indisponibilidade de armazenamento e expiração de credenciais.
5. Repetir a tarefa após falha e verificar que uma ação externa não seja duplicada.
6. Exercitar a exportação de artefatos para a implementação alternativa escolhida.

Resultado esperado, não medido: uma decisão de adoção sustentada por evidências de recuperação, isolamento e custo. Não se presume redução de latência ou economia antes do piloto.

6. YAML: um orçamento de admissão para o piloto

O exemplo abaixo usa apenas recursos nativos do Kubernetes. Ele cria um namespace de avaliação com um teto de recursos declarados. Não instala Agent Substrate, gVisor ou OpenRL e não define cotas por Actor. ResourceQuota opera sobre recursos do namespace Kubernetes. (kubernetes.io)

apiVersion: v1
kind: Namespace
metadata:
  name: agent-platform-evaluation
---
apiVersion: v1
kind: ResourceQuota
metadata:
  name: evaluation-budget
  namespace: agent-platform-evaluation
spec:
  hard:
    requests.cpu: "8"
    requests.memory: 16Gi
    limits.cpu: "16"
    limits.memory: 32Gi
    pods: "30"

requests.* e limits.* restringem os totais declarados; pods limita a contagem de Pods não terminados. A quota pode impedir novas admissões, mas não reserva nós nem representa um limite monetário da nuvem. Os valores são didáticos e devem ser recalculados para o piloto. (kubernetes.io)

Como decisão operacional, reserve margem para atualizações e recuperação antes de liberar novas equipes. Não aplique esse exemplo indiscriminadamente ao namespace dos componentes centrais. Para o piloto, exija requests e limits explícitos nos manifests; caso adote valores padrão via LimitRange, documente-os para evitar dimensionamento implícito. (kubernetes.io)

O ponto específico de plataformas multiplexadas é importante: não use a quantidade de Pods como substituto de um orçamento de sessões. Minha proposta é implementar controles adicionais de sessões ativas, fila, armazenamento e consumo de modelos na camada que admite tarefas.

Salve o manifesto como evaluation-budget.yaml e execute:

kubectl apply -f evaluation-budget.yaml
kubectl get resourcequota -n agent-platform-evaluation
kubectl describe resourcequota evaluation-budget -n agent-platform-evaluation

A consulta de quotas e de seu consumo faz parte do fluxo documentado de administração desse recurso. (kubernetes.io)

7. Produção: critérios antes da expansão

Os itens seguintes são uma proposta de checklist de aceitação, não funcionalidades automaticamente entregues pela doação.

Disponibilidade e recuperação

• Exigir múltiplas réplicas dos serviços que suportam replicação e distribuir capacidade entre zonas.
• Validar readiness, liveness e startup probes dos serviços persistentes, evitando reinicializações causadas apenas por dependências temporariamente lentas.
• Testar indisponibilidade do armazenamento, perda de worker e falha durante uma ação externa.
• Definir Recovery Time Objective (RTO), tempo-alvo de recuperação, e Recovery Point Objective (RPO), perda de dados aceitável.
• Testar restauração dos dados de aplicação, não apenas a existência de snapshots.

Use PodDisruptionBudget quando apropriado para controlar disrupções voluntárias; ele não substitui redundância nem impede falhas involuntárias de nós. (kubernetes.io)

Segurança e identidade

O modelo de segurança do gVisor trata da contenção do workload. Ele não deve ser interpretado como autorização de negócio para as ações que o código consegue executar pelos acessos concedidos. A recomendação é avaliar isolamento e permissões como controles complementares. (gvisor.dev)

Proponho os seguintes requisitos:

• Separar identidades do plano de controle, workers e aplicações consumidoras.
• Aplicar Role-Based Access Control (RBAC), controle de acesso baseado em papéis, com o menor privilégio necessário.
• Usar ServiceAccounts específicas e evitar montagem automática de tokens onde não sejam necessários. (kubernetes.io)
• Não entregar credenciais administrativas nem Secrets compartilhados aos ambientes de execução.
• Exigir credenciais temporárias, rotação, Transport Layer Security (TLS), criptografia do armazenamento e autorização por destino.
• Tratar snapshots como dados sensíveis e testar a renovação de credenciais após retomadas.

As decisões de conectividade merecem avaliação própria; para esse recorte, veja rede de sandboxes de agentes em Kubernetes.

Upgrades e rollback

Minha proposta é fixar versões e digests, manter configuração em GitOps e promover mudanças somente depois de testes de compatibilidade. Faça canário com tarefas sem efeitos externos e valide restauração antes de atualizar todo o pool.

O plano de rollback deve responder a uma pergunta concreta: a versão anterior consegue consumir os dados produzidos pela nova? Se a resposta não estiver demonstrada, prefira drenar sessões e reconstruí-las a partir do estado lógico. Não considere um simples retorno da imagem como prova de recuperação completa.

8. Observabilidade e FinOps orientados à tarefa

Para o piloto, proponho instrumentar quatro perspectivas:

Defina Service Level Indicators (SLIs), indicadores de serviço, e Service Level Objectives (SLOs), objetivos de serviço, a partir da tarefa percebida pelo usuário. Não use apenas disponibilidade dos Pods como critério de sucesso.

Recomendo correlacionar logs e traces por identificador de tarefa, mantendo identificadores de alta cardinalidade fora dos rótulos de métricas. Evite registrar prompts, tokens de autenticação e conteúdo de repositórios por padrão.

Para capacidade, use inicialmente a relação de planejamento concorrência média ≈ taxa de chegada × tempo ativo médio, validando-a com medições. Em um exemplo exclusivamente hipotético, 2 tarefas por segundo com 5 segundos ativos representam média de 10 execuções simultâneas. Isso não dimensiona o pico nem substitui margem para falhas, espera e distribuição desigual.

Como modelo financeiro proposto:

custo por tarefa válida = custos atribuídos no período / tarefas concluídas e aprovadas no período

Inclua capacidade aquecida ociosa, snapshots, tráfego entre zonas, load balancers, observabilidade, chamadas de modelos e operação humana. Para tarefas reiniciáveis, avalie capacidade Spot; para o plano de controle e a capacidade mínima necessária ao SLO, priorize previsibilidade. Não presuma economia apenas porque a execução foi suspensa.

9. Troubleshooting orientado a hipóteses

Os procedimentos abaixo são uma proposta de investigação para o piloto. Os comandos de quota consultam recursos nativos; eles não inspecionam sessões internas dos projetos. (kubernetes.io)

Uma quota maior não é correção universal: se a recuperação não cabe na capacidade física disponível, elevar o teto apenas desloca o problema.

10. Desenvolvimento, alternativas e critérios de decisão

Em desenvolvimento, proponho aceitar um único ambiente, baixo volume e observabilidade simplificada, desde que os dados sejam descartáveis e as limitações explícitas. Em produção, a aprovação deve exigir testes de restauração, alertas, redundância, política de acesso e rollback demonstrado.

A tabela é um roteiro de decisão, não um benchmark entre implementações.

Evite adotar as três camadas simultaneamente para um problema pequeno. Também evite credenciais hardcoded, ausência de requests, serviços permanentes sem probes, infraestrutura sem backup, exposição pública desnecessária e expansão sem responsável operacional.

Resumo prático

• Separe anúncio, aprovação institucional, onboarding e prontidão operacional.
• Avalie ciclo de vida, isolamento e treinamento como decisões independentes.
• Exija provas de recuperação e saída, não apenas uma demonstração de execução.
• Combine orçamento Kubernetes com controles de sessões e consumo externo.
• Meça custo e confiabilidade por tarefa válida.
• Aprove produção somente quando suporte, segurança e rollback tiverem responsáveis e evidências.

Conclusão

A oportunidade estratégica da doação é transformar infraestrutura de agentes em uma dependência mais discutível, auditável e compartilhada. Essa é uma interpretação arquitetural do movimento de governança, não uma garantia de portabilidade ou maturidade uniforme.

Para DevOps, SRE e Platform Engineering, o próximo passo não deveria ser migrar toda a plataforma por causa do anúncio. Deveria ser construir um piloto com contratos explícitos, critérios de aprovação, testes de falha e uma alternativa de saída. A fundação aberta pode melhorar o contexto da decisão; a engenharia continua responsável por demonstrar que a plataforma é segura, recuperável e economicamente sustentável.