A Semana em que a Infraestrutura de Agentes Amadureceu

Em uma única semana de março de 2026, quatro projetos independentes publicaram infraestrutura de produção para agentes de IA. Não demos de conferência. Não artigos acadêmicos. Infraestrutura real, em repositórios públicos, com documentação operacional.

A Connectwise colocou em produção um copiloto de SRE que gerencia 90.000 servidores. O Kubernetes publicou um CRD experimental para sandboxes de agentes. A Grafana lançou observabilidade de agentes com duas linhas de código. E a Stripe revelou que agentes já escrevem 1.300 pull requests por semana em produção.

Cada anúncio, isoladamente, é interessante. Juntos, contam uma história diferente: a infraestrutura de agentes deixou de ser um problema de orquestração de containers. Virou uma categoria própria.

O copiloto que gerencia 90.000 servidores

O CW Copilot da Connectwise é talvez o exemplo mais concreto de agente de IA em produção corporativa que existe hoje. Mais de um ano de desenvolvimento. 90.000 servidores. 500.000 aplicações. Claude Sonnet 4 como modelo base. Ansible para orquestração. Celery com Redis para filas.

O detalhe que importa não está na escala. Está na decisão de segurança: cada agente roda como um usuário Linux dedicado com acesso restrito. Não é um container isolado. É um usuário no sistema operacional, com permissões granulares no nível de arquivo e processo.

Essa escolha revela algo sobre o estado atual da infraestrutura de agentes. Quando você precisa de controle fino sobre o que um agente pode tocar em um servidor, as abstrações de container não bastam. Você volta para o primitivo mais antigo de isolamento que o Linux oferece: contas de usuário com permissões POSIX.

Compare com o que documentamos em A Convergência da Contenção, onde NVIDIA, Docker e OpenAI chegaram independentemente a proxies de saída e políticas YAML. O CW Copilot opera em uma camada abaixo. Não isola agentes em containers. Isola agentes como usuários dentro de servidores que já existem. É contenção sem virtualização.

Kubernetes descobre que agentes não são pods

Em 20 de março, o blog oficial do Kubernetes publicou um KEP (Kubernetes Enhancement Proposal) para Sandbox de Agentes. O nome é descritivo. A arquitetura, reveladora.

O CRD define três conceitos que não existiam no vocabulário do Kubernetes: workloads singleton (um agente, um pod, sem réplicas), estado persistente entre invocações, e isolamento de rede por padrão. Ao lado do Sandbox, um segundo recurso chamado SandboxWarmPool resolve o problema de cold start. Pods pré-provisionados ficam prontos, eliminando a latência de criação que tornaria agentes responsivos inviáveis.

O isolamento usa gVisor ou Kata Containers. O ciclo de vida suporta suspend/resume e escalonamento para zero. Um Python SDK já está disponível.

Três decisões de design merecem atenção.

Primeiro, o modelo singleton. Kubernetes foi construído para escalar horizontalmente. Réplicas são o caso padrão. Agentes são o oposto: cada instância é única, carrega estado, e não pode ser substituída por outra. Criar um recurso específico para workloads que por definição não escalam horizontalmente é uma admissão de que o modelo de deployment tradicional não serve.

Segundo, a persistência de estado. Pods no Kubernetes são efêmeros por design. Agentes precisam lembrar o que fizeram, onde pararam, e o que ainda falta. O Sandbox trata isso como requisito de primeira classe, não como um volume montado por fora.

Terceiro, o isolamento padrão. Em Kubernetes convencional, pods compartilham rede por padrão e o isolamento é opt-in via NetworkPolicy. O Sandbox inverte: isolamento é o padrão, e a conectividade é opt-in. Agentes não conversam entre si a menos que você explicitamente permita.

Essa inversão de padrões reflete uma mudança de modelo mental. Software tradicional é colaborativo por padrão e isolado por exceção. Software agentic é isolado por padrão e colaborativo por exceção.

Observabilidade em duas linhas de código

No mesmo dia, a Grafana publicou uma integração de observabilidade para agentes baseada em OpenLIT e OpenTelemetry. A proposta: instrumentar qualquer agente com duas linhas de código Python e receber dashboards pré-construídos com latência p95/p99, duração de invocações de ferramentas, e uso de contexto.

O detalhe que importa é o que não foi dito. A Grafana não construiu um produto novo. Usou OpenTelemetry, que é vendor-neutral por design. Qualquer backend de observabilidade compatível funciona. A instrumentação via OpenLIT é uma biblioteca, não um serviço proprietário.

Isso resolve um problema que identificamos em O Loop de Governança Escondido no Monitoramento do Seu Agente: a convergência entre observabilidade e governança precisa de dados padronizados para funcionar. Se cada fornecedor usa seu próprio formato de traces, o loop de melhoria contínua quebra na fronteira entre ferramentas. OpenTelemetry é a resposta de infraestrutura para esse problema de governança.

P95 e p99 de latência são métricas conhecidas. Duração de invocação de ferramentas, também. Mas uso de contexto é uma métrica nova, específica de agentes. Ela mede quanto da janela de contexto do LLM o agente está consumindo a cada passo. Quando o contexto se esgota, o agente começa a “esquecer” instruções anteriores. Monitorar isso é monitorar a degradação cognitiva do agente em tempo real.

É uma métrica que não existia em infraestrutura de software até agora. Nenhum servidor web perde capacidade cognitiva sob carga.

1.300 pull requests por semana

O quarto sinal veio de um artigo de Alex Opsahl sobre Software Factories. O dado mais concreto: Stripe Minions, o sistema de agentes de engenharia da Stripe, já produz mais de 1.300 pull requests por semana. Não protótipos. Pull requests que passam por CI e entram em produção.

O padrão que a Stripe adotou se chama Blueprint. A ideia é combinar determinismo com comportamento agentic. Um blueprint define a estrutura do trabalho. O agente executa dentro dessa estrutura. Se o CI falha, o agente tem no máximo dois rounds para corrigir. Se não resolve, o trabalho volta para um humano.

A restrição de dois rounds é a decisão de design mais importante. Sem ela, um agente poderia entrar em loop, consumindo CI e gerando commits que pioram o código a cada iteração. Duas tentativas e um fallback humano é uma política de governança operacional. Define o limite exato de autonomia.

A frase mais citada do artigo é: “Um time de 5 em 2026 pode entregar o que um time de 50 entregava em 2016.” Verdade ou não, o que importa é a premissa implícita. Para que 5 pessoas entreguem o trabalho de 50, os outros 45 “trabalhadores” precisam de infraestrutura operacional própria. Precisam de deployment, monitoramento, limites de autonomia, protocolos de falha. Tudo o que um trabalhador humano recebe de RH, TI e gestão, um agente precisa receber de infraestrutura.

Como analisamos em The Most Governed Software Factory, o que parece remoção de humanos é, na prática, substituição de supervisão humana por governança codificada. A Stripe reforça esse padrão.

O que os quatro anúncios revelam juntos

Olhe para os quatro anúncios como um sistema.

O CW Copilot mostra que agentes de produção precisam de identidade no sistema operacional. O Kubernetes Sandbox mostra que o modelo de deployment precisa ser reinventado para workloads singleton, stateful, isolados. A Grafana mostra que a observabilidade precisa de métricas novas (uso de contexto) e padrões abertos. A Stripe mostra que agentes em produção precisam de limites de autonomia codificados.

Nenhum desses problemas é resolvido por “colocar o agente em um container e rodar no Kubernetes.” Cada um exige infraestrutura específica que ainda não existia.

A analogia mais próxima é o que aconteceu com microsserviços entre 2014 e 2018. Quando empresas começaram a decompor monolitos, descobriram que precisavam de service mesh, circuit breakers, distributed tracing, API gateways. Nada disso existia como categoria quando os microsserviços eram apenas “SOA bem feito.” A infraestrutura surgiu porque o padrão de deployment exigiu.

Agentes estão no mesmo ponto. O padrão de deployment exige infraestrutura que não existia. E essa infraestrutura está surgindo agora. Não como produto de um fornecedor, mas como convergência de soluções independentes para os mesmos problemas.

O que muda para quem opera IA

Se você está avaliando ou operando agentes de IA em produção, três implicações práticas emergem dessa semana.

Identidade de agente é um requisito de infraestrutura. O CW Copilot usa usuários Linux. O Kubernetes Sandbox usa CRDs dedicados. Ambos resolvem o mesmo problema: um agente precisa de uma identidade no sistema, com permissões, limites e auditoria próprios. Se seus agentes rodam como “o container da aplicação”, você não consegue auditar o que cada um fez.

Isolamento padrão, colaboração explícita. O Kubernetes Sandbox isola por padrão. O CW Copilot restringe por padrão. A Stripe limita tentativas por padrão. O modelo mental de infraestrutura de agentes é o inverso do modelo de microsserviços: em vez de conectar tudo e restringir onde necessário, isolar tudo e conectar onde necessário.

Métricas de agente são uma categoria nova. Uso de contexto, rounds de autocorreção, taxa de fallback para humanos. Essas métricas não existem em painéis de observabilidade tradicionais. Se sua observabilidade de agentes é “os mesmos dashboards que usamos para APIs”, você está medindo o carro pela velocidade do cavalo.

Essa semana de março de 2026 não foi sobre quatro produtos. Foi sobre o reconhecimento coletivo de que agentes de IA em produção precisam de infraestrutura operacional projetada para eles. Não adaptada de containers. Não improvisada com scripts. Projetada.

A infraestrutura tradicional não foi feita para software que toma decisões, carrega estado, e precisa de limites de autonomia. A semana em que quatro organizações independentes chegaram a essa conclusão, cada uma por seu caminho, marca o momento em que a infraestrutura de agentes deixou de ser um experimento e virou uma disciplina.

Fontes

Connectwise. “CW Copilot Architecture: SRE AI for 90,000+ Servers.” Março 2026.
Kubernetes Blog. “Scalable and Secure AI Agent Sandboxes in Kubernetes.” 20 março 2026.
Grafana / OpenLIT. “Agent Observability with OpenTelemetry.” 20 março 2026.
Opsahl, Alex. “The Software Factory.” alexop.dev, 22 março 2026.

Victorino Group ajuda organizações a projetar infraestrutura operacional para agentes de IA em produção: contato@victorino.com.br | www.victorino.com.br