Há uma categoria de incidente de produção que as equipes de engenharia ainda não estão rastreando — porque ela não se ajusta a nenhum modelo postmortem existente.
O agente iniciou uma ação. A ação foi tecnicamente correta dado o contexto do agente. O contexto estava incompleto. A infraestrutura caiu em cascata. E, no momento em que ocorreu a revisão do incidente, três equipes estavam discutindo se se tratava de uma falha de agente ou de infraestrutura, porque as estruturas para pensar sobre essas duas coisas nunca estiveram conectadas.
A escala desta exposição não é mais teórica. Setenta e nove por cento das organizações têm agora alguma forma de agente de IA em produção, com 96% planejando expansão. O Gartner prevê que 33% do software empresarial incluirá IA de agente até 2028, mas alerta separadamente que 40% desses projetos serão cancelados devido a controles de risco inadequados.
O que nenhuma das estatísticas captura é o modo de falha que ocorre entre esses dois números: agentes que estão em execução, que não são cancelados e que geram silenciosamente eventos de infraestrutura que ninguém classificou como de risco.
Passei seis anos construindo sistemas de automação de infraestrutura em escala empresarial, primeiro na Cisco (plataformas líderes de ciclo de vida orientadas por IA implantadas em mais de 20 clientes corporativos globais) e depois na Splunk (projetando análise de causa raiz assistida por IA e fluxos de trabalho de observabilidade em milhares de ambientes corporativos).
Durante esse período, também registrei uma patente sobre metodologia de engenharia do caos baseada na intenção. E, apesar de tudo isso, continuei observando as organizações cometerem o mesmo erro estrutural: tratar os agentes autônomos e a engenharia do caos como disciplinas separadas. Eles não são. São a mesma disciplina e a lacuna entre elas está silenciosamente gerando a próxima onda de grandes incidentes de produção.
A decisão que os agentes ignoram
Para entender por que isso é importante, é preciso entender o que realmente está errado na forma como as empresas governam o caos hoje, antes de adicionar agentes ao quadro.
A maioria das organizações de engenharia maduras investiu em programas de engenharia do caos. Dias de jogo, controles de raio de explosão, experimentos controlados por SLO. Quando um engenheiro humano inicia um experimento de caos, a sequência tem uma propriedade crítica: um ser humano está fazendo um julgamento sobre se o sistema tem capacidade de absorver a perturbação naquele momento. Eles verificam os painéis. Eles analisam a taxa de consumo de erros do orçamento. Eles avaliam se as dependências são estáveis. É imperfeito e muitas vezes intuitivo, mas há pelo menos uma pessoa envolvida fazendo a pergunta certa antes de qualquer coisa ser executada.
Quando você introduz um agente de remediação autônomo, que pode reiniciar serviços, redirecionar o tráfego, dimensionar recursos ou modificar configurações em resposta a anomalias detectadas, essa questão desaparece. O agente vê uma anomalia. O agente realiza uma ação. A ação é um evento caótico. Nenhuma verificação da taxa de gravação do SLO. Nenhum cálculo do raio de explosão. Não há julgamento humano sobre se este é o momento certo para introduzir tensão adicional num sistema que pode já estar sob pressão de três outras direcções.
Aqui está o modo de falha específico que observei acontecer. Um agente de remediação detecta latência elevada em um microsserviço e responde reiniciando o cluster de serviço; uma ação razoável, dados seus dados de treinamento e sua visão restrita do incidente. O que o agente não sabe: Três outros serviços estão lidando com picos de tráfego. O pool de conexões compartilhadas já está com 87% de utilização. Um banco de dados dependente está executando uma reconstrução de índice em segundo plano. O reinício desencadeia uma manada trovejante contra o serviço em recuperação.
O que começou como um pico de latência que o agente foi projetado para corrigir torna-se uma cascata que o agente nunca foi projetado para modelar. O raio de ação dessa ação do agente não foi a reinicialização do serviço. Foi tudo após a reinicialização, em um estado do sistema do qual o agente não tinha uma visão completa.
Nenhum programa de engenharia do caos havia testado essa combinação específica. Ninguém no cálculo do raio de explosão incluiu o agente como ator. Porque não pensamos nos agentes como injetores de caos. Deveríamos.
De acordo com a base de dados de incidentes de IA, os incidentes relatados relacionados com IA aumentaram 21% entre 2024 e 2025. Essa contagem quase certamente subestima a exposição real, porque a maioria das organizações não tem uma classificação de incidentes que capte uma acção de agente autónomo como a causa inicial de uma cascata. O incidente é registrado como uma reinicialização de serviço, uma saturação do pool de conexões ou um evento de latência. O agente fica invisível na autópsia.
A capacidade de absorção é um recurso; a maioria dos sistemas não trata dessa maneira
O problema subjacente é que os sistemas empresariais não têm uma linguagem partilhada para capacidade de absorção – a estimativa em tempo real de quanto esforço adicional um sistema pode suportar antes de violar os seus compromissos de SLO. Os programas de engenharia do caos gerenciam-no implicitamente, por meio do julgamento humano e de limites estáticos que são acionados depois que um limite já foi ultrapassado. Os agentes não gerenciam nada.
Por meio de pesquisa primária estruturada com profissionais de engenharia de confiabilidade de site (SRE) e engenharia de plataforma em organizações como Intuit e GPTZero, venho desenvolvendo um modelo de orçamento de resiliência. A ideia central é tratar a capacidade de absorção como um recurso consumível continuamente recalculado, em vez de um limite estático que você tenta não violar.
Um orçamento de resiliência baseia-se em quatro classes de sinais ao vivo.
-
A taxa de consumo do SLO é a entrada principal, porque codifica diretamente a distância entre o comportamento atual do sistema e o comprometimento que realmente importa. Se um sistema estiver queimando seu orçamento mensal de erros a uma taxa cinco vezes maior que a esperada, o orçamento de resiliência será próximo de zero, independentemente da aparência da utilização da CPU.
-
A tendência de latência P99 é mais importante do que a latência absoluta, porque uma tendência de aumento de serviço durante quarenta minutos indica algo diferente de um serviço que permaneceu estável no mesmo valor absoluto.
-
O estado de saturação de dependência é o sinal mais comumente perdido; um experimento de caos ou uma ação de agente que pressupõe que um conjunto de conexões compartilhadas esteja disponível gratuitamente quando está em 87% produzirá modos de falha para os quais ninguém projetou.
-
Sinais comportamentais de aplicativos, taxas de conclusão de sessão, mudanças no padrão de chamada de API, degradação de conversão e estresse do sistema de superfície antes das métricas de infraestrutura, porque os usuários sentem a degradação antes que o Prometheus a relate.
O que torna isto um orçamento e não um limite é que é consumível. Cada experiência de caos baseia-se na capacidade disponível. Toda ação do agente se baseia nisso. Em organizações com múltiplas equipes onde vários experimentos e vários agentes podem atuar simultaneamente, o orçamento é compartilhado.
Sem um registro de consumo compartilhado, duas equipes executando experimentos em dependências sobrepostas produzem um raio de explosão combinado que nenhuma das equipes planejou. Adicione agentes autônomos agindo completamente fora do razão e a contabilidade entra em colapso.
Onde os modelos de linguagem ajudam e exatamente onde falham
Várias organizações de engenharia estão agora realizando experimentos usando grandes modelos de linguagem (LLMs) para gerar hipóteses de caos a partir de gráficos de dependência e corpora post-mortem de incidentes. Os resultados são direcionalmente úteis. Os modelos de linguagem revelam modos de falha plausíveis que os SREs experientes reconhecem como dignos de teste e geram hipóteses mais rapidamente do que os processos manuais, especialmente quando se trabalha a partir de um rico histórico post-mortem.
O limite é a desatualização do gráfico de dependência e é um limite rígido. Uma hipótese gerada a partir de um gráfico que não reflete a extração de serviço do mês passado, ou uma nova dependência de biblioteca compartilhada adicionada há dois sprints, proporá um experimento com suposições incorretas sobre o raio de explosão. O problema não é que o modelo cometa um erro, é que o modelo não sabe que está cometendo um erro. Será certamente incorreto sobre um limite do sistema que não existe mais e, na engenharia do caos, uma incorreção confiante na produção significa uma interrupção não planejada.
O Trustworthy AI Research Lab de Stanford descobriu que as proteções em nível de modelo por si só são insuficientes: os ataques de ajuste fino contornaram os modelos principais na maioria dos casos testados. A implicação para a geração da hipótese do caos é direta: um modelo que não consegue manter com segurança seus próprios limites de segurança não pode ser confiável para modelar com precisão o raio de explosão de uma ação que nunca viu em um gráfico de dependência que não foi verificado.
Quando a geração de hipóteses se baseia em corpora post-mortem, o problema da obsolescência diminui consideravelmente. Postmortems descrevem falhas que realmente ocorreram no sistema em um momento específico. O sinal é inerentemente validado pela realidade da produção. Este é o aplicativo de IA tratável de curto prazo neste espaço e é genuinamente útil para organizações com práticas maduras de documentação de incidentes.
O que a IA não pode fazer, e não deve ser solicitada, é tomar a decisão de execução quando os sinais são ambíguos. Esse julgamento exige consciência de coisas que estão inteiramente fora de qualquer sistema de monitoramento: implantações pendentes que mudaram o cenário de dependência há uma hora, níveis de pessoal de plantão em um fim de semana de feriado, um compromisso do cliente que torna qualquer risco adicional inaceitável até segunda-feira.
Um modelo sem acesso a esse contexto não deveria fazer essa chamada. Esta não é uma limitação temporária enquanto se aguarda um modelo mais capaz. É uma restrição estrutural do que a observabilidade da máquina pode representar, e construir uma arquitetura de agente que a ignore é construir uma que acabará por tomar uma decisão consequente com informações incompletas – e sem nenhum humano no circuito para capturá-la.
O que isto significa para a forma como as empresas governam os agentes na produção
A implicação da governação é simples de descrever e mais difícil de implementar do que parece. Cada ação de agente autônomo que afeta a infraestrutura precisa ser registrada na mesma camada de sinal ao vivo que governa os experimentos de caos. As mesmas taxas de queima de SLO, tendências de latência e estados de saturação de dependência que um engenheiro humano verificaria antes de iniciar um experimento devem determinar o que um agente tem permissão para fazer e quando. Se o orçamento de resiliência estiver abaixo de um limite mínimo definido, o agente espera ou escala. Não funciona.
As ações dos agentes também precisam ser modeladas como experimentos, e não apenas registradas como eventos. Quando um agente reinicia um serviço, a questão não é apenas se a reinicialização foi concluída com êxito. É se o raio de ação dessa ação foi proporcional à capacidade de absorção disponível e quais efeitos em cascata ela produziu nas dependências. Esses são dados de engenharia do caos. Pertence ao modelo orçamentário, alimentando a próxima decisão que o agente ou a equipe precisa tomar.
E quando os sinais são genuinamente ambíguos, quando a pontuação do orçamento não é clara, quando uma implantação recente alterou a topologia de uma forma que a janela de contexto do agente não captura, quando os estados de dependência estão em fluxo, a decisão de execução precisa passar para um ser humano. Não como uma limitação permanente à autonomia do agente, mas como um requisito de engenharia rigoroso para o estado atual da tecnologia.
Um disjuntor que entrega casos ambíguos a um ser humano não é um ponto fraco na arquitetura do agente. É o que torna a arquitetura confiável o suficiente para realmente ser executada em produção. A verificação baseada em intenção formaliza exatamente isso: definir como será o comportamento correto do agente antes da implantação e, em seguida, testar continuamente se esses limites se mantêm sob condições de sistema ativo.
As organizações que operam agentes autônomos de forma confiável e em grande escala não são aquelas com modelos mais sofisticados. Foram eles que compreenderam, antes de algo correr mal, que cada acção do agente é um evento caótico e construíram a sua camada de governação em conformidade.
A primeira etapa prática não é glamorosa: audite cada agente autônomo que atualmente está em contato com a infraestrutura, mapeie sua superfície de ação em relação aos sinais de taxa de queima do SLO em tempo real e defina condições de piso explícitas abaixo das quais o agente deve esperar ou escalar. Essa auditoria revelará agentes que atuam inteiramente fora da sua contabilidade de resiliência.
A maioria das organizações que administram agentes em grande escala hoje possui vários. Encontre-os antes da produção.
Sayali Patil passou mais de 6 anos na Cisco Systems e Splunk construindo sistemas de confiabilidade e automação que mantêm a infraestrutura de IA corporativa funcionando em escala.
Fonte ==> Cyberseo
