- Início
- The Thinking Wire
- O Stack de Contenção Se Completou: Quatro Camadas em Uma Semana
O Stack de Contenção Se Completou: Quatro Camadas em Uma Semana
Entre 20 e 21 de maio, quatro organizações lançaram quatro coisas bem diferentes dentro do mesmo problema. A Dropbox abriu o código do Nova, uma plataforma interna que embrulha agentes de codificação em isolamento de workflow. A CNCF anunciou o Prempti, uma camada de política derivada do Falco que intercepta as ações que o agente tenta executar antes de chegarem ao host. O Google lançou o Agent Executor (o runtime open-source ax) junto com o Agent Substrate sobre Kubernetes, um runtime distribuído para agentes que precisam sobreviver a reinícios, ramificar a própria trajetória e escalar para milhões de instâncias registradas. A IBM, no mesmo keynote do Think, fez o caso executivo para “digital workers” como uma classe de trabalho gerenciada, com crachá, onboarding e aposentadoria.
Lidos isoladamente, são quatro anúncios de fornecedor. Lidos em conjunto, na ordem em que apareceram no feed, descrevem quatro andares de um edifício que a Victorino esboçou um mês atrás no ensaio original sobre convergência e que agora está sendo preenchido por empresas que não se coordenaram. A história interessante desta semana não é que todas lançaram. É que lançaram em altitudes diferentes.
Camada 1: Isolamento de Workflow (Dropbox Nova)
O post do Nova é o mais próximo do chão dos quatro lançamentos. Nova é uma plataforma para rodar agentes de codificação dentro dos próprios workflows de engenharia da Dropbox, com três restrições que importam:
Um teto de cinco iterações por workflow. Um agente que não convergiu depois de cinco tentativas não recebe a sexta; o workflow para e um humano assume. A plataforma se recusa a gastar tokens infinitos perseguindo um plano ruim.
Um deflaker que valida cada correção candidata contra mais de 100 execuções de CI antes do merge. Agentes de codificação propõem código o tempo todo; o gargalo não é geração, é verificar que a proposta não introduz um teste instável. A Nova trata o deflaker como componente de primeira classe do workflow, não como reflexão posterior.
Snapshots herméticos por commit. Cada execução do agente recebe uma visão congelada do repositório em um commit conhecido, de modo que reexecuções são reproduzíveis e agentes concorrentes não enxergam trabalho meio feito uns dos outros.
O que a Dropbox lançou não é sandbox no sentido de sistema operacional. É sandbox no sentido de workflow: o agente roda contra uma versão delimitada do repositório, com um número delimitado de tentativas, supervisionado por um validador determinístico. A fronteira de confiança é o próprio workflow. Esta é a camada mais próxima do trabalho real do agente, e é onde a maior parte dos times acidentalmente não tem nada.
Camada 2: Interceptação de Ações (CNCF Prempti)
Um andar acima do isolamento de workflow está a interceptação de ações. O anúncio do Prempti pela CNCF é a implementação de referência que não existia no mês passado. Prempti é construído em cima do projeto Falco de segurança de runtime e observa as coisas que agentes de codificação tentam fazer e não deveriam: ler chaves SSH, exfiltrar credenciais AWS, modificar a configuração de servidores MCP para escalar as próprias permissões, injetar comandos em git hooks.
A decisão de design que merece ser nomeada: Prempti é pré-execução, não auditoria pós-fato. Uma violação registrada é útil para forense, mas não impede que a chave SSH do laptop saia do prédio. A instrumentação de kernel do Falco permite ao Prempti bloquear o syscall antes que ele complete. Suporta Claude Code hoje em Linux, macOS e Windows, com Codex no roadmap.
Esta camada responde a uma pergunta que a camada de workflow não consegue: “O que o agente está de fato tentando fazer no host?” O teto de cinco iterações do Nova não protege se a iteração três silenciosamente lê ~/.ssh/id_rsa e dispara um POST para um webhook do Discord. A camada de workflow confia na intenção do workflow. A camada de ações não confia em nada e inspeciona cada toque no sistema.
O Prempti também produz a telemetria de que as duas camadas seguintes dependem. Sem atribuição por ação, você não consegue dizer qual agente fez o quê, e os andares de cima perdem a capacidade de tomar decisões sobre instâncias específicas.
Camada 3: Durabilidade de Runtime (Google Agent Executor)
Dois andares acima, você bate na pergunta que o Google escolheu responder nesta semana: como agentes sobrevivem em escala? O anúncio do Agent Executor e o repositório google/ax correspondente definem um runtime, não um sandbox. As primitivas são execução durável (um agente pode cair e retomar no meio da trajetória), sandboxes seguros por processo de agente, ramificação de trajetória (o agente pode bifurcar o próprio raciocínio e descartar o ramo pior) e Agent Substrate, um registry sobre Kubernetes desenhado para milhões de agentes registrados.
O runtime é compatível com o protocolo A2A, ou seja, agentes escritos para ele interoperam com outros endpoints A2A, incluindo o ecossistema agente-a-agente que cobrimos nas notas do Cloud Next. A escolha deliberada é fazer do runtime, não do framework, a peça que escala. O grafo de tarefas do agente é a unidade de execução; o framework que o produziu é intercambiável.
Durabilidade é o andar que as pessoas pulam porque tudo funciona bem até não funcionar. Um agente no meio de uma trajetória de 40 passos é desalojado por uma falha de nó Kubernetes. Sem execução durável, o agente reinicia do passo um, queima os tokens de novo, possivelmente segue um caminho diferente e silenciosamente diverge. Com execução durável, ele retoma no passo 23 com o mesmo contexto e continua. A diferença é invisível no dashboard até você contar a computação desperdiçada e os resultados inconsistentes.
O Agent Executor fica acima da camada de ações porque assume que o host já está protegido. É a camada em que um agente vira uma workload de longa duração, observável e reiniciável, do mesmo jeito que serviços viraram workloads de longa duração observáveis uma década atrás.
Camada 4: Gestão de Ciclo de Vida (Digital Workers da IBM)
O andar de cima é o que a IBM marcou no Think nesta semana. O keynote de Mohamad Ali (SVP, IBM Consulting, falando sob o mandato de Krishna) enquadrou agentes não como código, mas como trabalhadores com ciclo de vida: contratados, integrados, certificados, auditados, aposentados. A parceria com a Pearson produz badges de habilidade que controlam quais agentes podem assumir quais trabalhos. A Providence Health cortou em 12 dias o ciclo de recrutamento de enfermeiros usando um pool de digital workers. A aplicação interna da IBM decompôs 490 workflows de consultoria, reivindica US$ 4,5 bilhões em ganhos de produtividade e atribui 20 pontos percentuais de aumento de margem em consultoria entre 2024 e 2025.
Tirando o enquadramento de keynote, a afirmação operacional é esta: em escala corporativa, agentes não são workloads, são headcount. As perguntas que o RH sempre fez sobre funcionários se aplicam aos agentes nesta camada. A quem ele se reporta? Em que é certificado? O que se faz quando ele erra? Qual é o procedimento de offboarding que remove os acessos de forma limpa? A aposta da IBM é que organizações operando com centenas a milhares de agentes precisam de uma camada com formato de RH acima do runtime, não de mais um runtime.
Esta é a camada que não cabe em nenhuma das três de baixo. A Nova gerencia workflows. O Prempti gerencia ações. O Agent Executor gerencia processos. Nenhum responde: “Este agente específico deveria ter permissão para assumir este trabalho específico hoje?” Essa é uma pergunta de ciclo de vida. O crachá, o papel, a aposentadoria, a trilha de auditoria de quem contratou este agente e por quê, tudo isso fica acima do runtime e abaixo da decisão de negócio.
Por Que o Diagrama da Pilha Importa Mais Que Qualquer Fornecedor
Você não precisa escolher entre Dropbox, CNCF, Google ou IBM. Precisa escolher uma camada para ser honesto a respeito. Se você roda agentes de codificação e o único controle é o prompt, está sem a camada 1. Se tem isolamento de workflow mas não tem interceptação de ações, um teto de iterações não te salva de uma exfiltração. Se seus agentes reiniciam do zero toda vez que um nó morre, não há camada 3. Se você opera mais de cinquenta agentes em produção e não consegue responder “quem certificou este aqui a tocar dados de cobrança”, não há camada 4.
Os quatro fornecedores desta semana não se coordenaram. Mas expuseram as camadas com clareza suficiente para que você audite o próprio stack contra o diagrama. É isso que governança como produto parece quando os produtos chegam na mesma semana e se encaixam em andares diferentes. É também por que a história da convergência do início do mês estava subestimando: chamou a tendência certa, mas subestimou a velocidade da diferenciação por camada.
A camada que a maioria dos times vai querer comprar primeiro é a 4 (tem narrativa executiva, métricas amigáveis ao board e alegação de ROI). A camada de que a maioria dos times realmente precisa primeiro é a 2 (um agente sem interceptação de ações é uma exfiltração de credencial esperando para acontecer). A camada para a qual a maioria já tem alguma resposta é a 3 (o Kubernetes já estava ali; só falta um runtime que saiba usá-lo). A camada que a maioria subestima é a 1 (porque as restrições de workflow parecem imposto de produtividade até a primeira vez em que um agente queima 200 iterações em um plano errado).
Faça Isto Agora
Reserve 45 minutos com o líder de plataforma ainda esta semana. Desenhe as quatro camadas em um quadro. Para cada uma, anote o fornecedor ou sistema que a opera no seu stack, ou escreva “nenhum” se ninguém a opera. Conte os “nenhum”. Esse número é a sua dívida honesta de contenção.
Depois, pegue o “nenhum” de menor número e atribua um dono. Não um projeto. Um dono. A ordem das camadas importa porque os andares de cima assumem que os de baixo existem. Comprar gestão de ciclo de vida da camada 4 antes de ter interceptação de ações da camada 2 é contratar diretor de RH para um prédio sem porta de entrada.
O diagrama agora foi desenhado por pessoas que não trabalham com você e que lançaram tudo numa terça. A parte difícil é a auditoria que você roda dentro do próprio prédio. Você vai descobrir pelo menos um andar faltando. Esse é o trabalho do próximo trimestre.
Fontes
- Dropbox Engineering. “Introducing Nova, Dropbox’s Internal Platform for Coding Agents.” Maio de 2026.
- CNCF. “Introducing Prempti: Policy and Visibility for AI Coding Agents.” Maio de 2026.
- Google Cloud. “Introducing Agent Executor, Google’s Distributed Agent Runtime.” Maio de 2026.
- SiliconANGLE / IBM. “Managing Digital Worker Lifecycle.” Maio de 2026.
A Victorino ajuda times a escolher camadas de contenção que combinam com o risco real do workflow, não com o marketing do fornecedor: contato@victorino.com.br | www.victorino.com.br
Todos os artigos do The Thinking Wire são escritos com o auxílio do modelo LLM Opus da Anthropic. Cada publicação passa por pesquisa multi-agente para verificar fatos e identificar contradições, seguida de revisão e aprovação humana antes da publicação. Se você encontrar alguma informação imprecisa ou deseja entrar em contato com o editorial, escreva para editorial@victorino.com.br . Sobre o The Thinking Wire →
Se isso faz sentido, vamos conversar
Ajudamos empresas a implementar IA sem perder o controle.
Agendar uma Conversa