Agentes K8s: Autonomia Faseada para Infraestrutura

A CNCF aceitou frameworks de agentes no tier Sandbox. O projeto kagent, agora open source, oferece um exemplo concreto de como agentes de IA podem operar dentro de clusters Kubernetes. Vikram Seshadri, da DoiT, descreve uma abordagem progressiva onde cada etapa amplia o que o agente está autorizado a fazer. A progressão é explícita, auditável e reversível.

Isso importa porque Kubernetes é onde governança de infraestrutura funciona ou falha em escala. E o padrão que o kagent introduz se transfere para muito além de clusters.

As Quatro Fases

O artigo recomenda uma abordagem progressiva para autonomia de agentes:

Fase 1: Somente leitura. O agente observa o estado do cluster, lê logs, inspeciona recursos. Não pode alterar nada. Toda consulta é registrada. O operador ganha confiança no que o agente entende antes de conceder qualquer autoridade para agir. É o período de integração.

Fase 2: Gerador de patches. O agente propõe mudanças como patches ou pull requests. Um humano revisa e aplica. O agente raciocina; o humano executa. A separação é estrutural.

Fase 3: Baixo risco aprovado. O agente executa um conjunto definido de operações sem aprovação humana. O limite é explícito: ações específicas, em tipos de recurso específicos, dentro de namespaces específicos. A superfície de aprovação é documentada e auditável.

Fase 4: Autônomo em operações conhecidas. O agente lida com operações rotineiras de ponta a ponta. Scaling, rolling restarts, renovação de certificados, limpeza de recursos. São operações que o time já executou centenas de vezes, onde os modos de falha são conhecidos e o caminho de rollback está testado.

As fases funcionam como uma escada de confiança, onde cada degrau é uma decisão deliberada. Alguns agentes vão permanecer na Fase 2 permanentemente. Isso é decisão de design.

Agente Raciocina, Operador Executa

A separação arquitetural no kagent merece estudo por si só. O agente é um componente de raciocínio. Ele observa estado, interpreta intenção e propõe ações. O operador Kubernetes é o componente de execução. Ele valida a ação proposta contra a política, aplica no cluster e registra o resultado.

Essa separação tem duas consequências.

Primeiro, o agente não precisa de autoridade irrestrita sobre o cluster. O operador media cada ação. A superfície de comprometimento do agente se limita a recomendações ruins, não a mutações não autorizadas. Uma falha de raciocínio produz um patch rejeitado. Uma falha de operador produz uma entrada de auditoria com um alvo de rollback.

Segundo, a camada de política fica entre raciocínio e execução, não depois da execução. Monitoramento tradicional captura problemas em retrospecto. Essa arquitetura os captura antes que aconteçam. O operador pode impor restrições que o agente desconhece: cotas de recursos, políticas de rede, labels de compliance. O agente propõe um deployment para um namespace que considera apropriado. O operador verifica se aquele namespace aceita workloads daquela classificação. A rejeição acontece antes de qualquer pod ser agendado.

Quatro Propriedades de Toda Ação

Seshadri argumenta que toda ação de agente deve satisfazer quatro propriedades: autorizada, limitada, observável e reversível.

Autorizada significa que a ação corresponde a uma permissão que o agente recebeu explicitamente. O conjunto de permissões é um documento deliberado, não um efeito colateral do RBAC do cluster.

Limitada significa que o raio de explosão é definido antes da execução. O limite não é consultivo. O operador o impõe.

Observável significa que a ação produz uma entrada de log estruturada que inclui a cadeia de raciocínio, a ação proposta, o resultado da avaliação de política e o resultado da execução. Os logs constituem a trilha de auditoria que justifica o nível de autonomia.

Reversível significa que a ação tem um caminho de rollback testado. Ações que não têm reversão limpa exigem um nível de autorização mais alto e, na maioria das configurações, aprovação humana independentemente da fase de autonomia do agente.

Essas quatro propriedades não são específicas do Kubernetes. Aplicam-se a qualquer sistema onde um agente atua sobre infraestrutura.

Além do Kubernetes

O modelo de autonomia faseada se transfere para qualquer domínio onde agentes tocam sistemas em produção. Agentes de banco de dados que começam gerando planos de consulta (Fase 2) antes de executá-los (Fase 3). Agentes de CI/CD que propõem mudanças de pipeline como pull requests antes de mergeá-los. Agentes de custo em nuvem que recomendam right-sizing antes de aplicá-lo.

A separação raciocínio-execução também se transfere. Um agente que recomenda uma mudança Terraform e um operador que a aplica após avaliação de política segue a mesma arquitetura. O agente nunca detém credenciais de nuvem. A camada de política fica entre a recomendação e a chamada de API.

Equipes que já constroem governança dentro de suas ferramentas entendem o princípio. O que o kagent adiciona é um modelo concreto de progressão. Em vez de estados binários (humano no loop ou totalmente autônomo), as quatro fases dão aos times um vocabulário para estados intermediários. Cada agente pode estar em uma fase diferente para tipos diferentes de operação, e a atribuição de fase é um documento que o time pode revisar.

O Que Isso Significa na Prática

Se o seu time opera agentes contra infraestrutura hoje, mapeie cada agente para as quatro fases do kagent. Você provavelmente vai descobrir que a maioria opera na Fase 1 ou na Fase 4 sem nada entre elas. As fases intermediárias são onde a maturidade operacional se desenvolve. Um agente na Fase 2 que gera patches por seis semanas ensina ao time o que o agente acerta e onde ele desvia. Esses dados justificam a definição de limites da Fase 3.

Agentes que ainda carecem da separação raciocínio-execução merecem essa mudança arquitetural primeiro. Um agente que detém credenciais e executa as próprias recomendações não tem um ponto estrutural onde a política pode intervir. A separação é o mecanismo que torna as fases aplicáveis.

A aceitação de frameworks de agentes no Sandbox pela CNCF sinaliza que o ecossistema Kubernetes trata governança de agentes como infraestrutura, não como preocupação de aplicação. O modelo de quatro fases, a separação raciocínio-execução e as quatro propriedades (autorizada, limitada, observável, reversível) vão aparecer em outros ecossistemas dentro do ano. Equipes que adotam o padrão agora terão os dados operacionais para afiná-lo. Equipes que esperam vão adotá-lo sob pressão, sem esses dados.

Fontes

Seshadri, Vikram. “AI Agents Kubernetes Control.” DoiT/The New Stack, Outubro de 2026.

A Victorino ajuda equipes a implementar autonomia faseada para agentes de infraestrutura. contato@victorino.com.br | www.victorino.com.br