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,

Quando os fluxos de trabalho de agente falham, os desenvolvedores geralmente presumem que o problema está nas habilidades de raciocínio do modelo subjacente.

Em 19 de maio, 633 versões maliciosas de pacotes npm passaram na verificação de proveniência do Sigstore. Eles foram apagados pelo sistema porque

FLEX aprimora o design de fachadas, apoia o trabalho de mídia no varejo e fornece insights sobre perdas A Sensormatic Solutions, portfólio global

A Dun & Bradstreet passou mais de 180 anos construindo um banco de dados comercial abrangente. Seu Gráfico Comercial, que abrange 642 milhões

Resolve AI, the production-operations startup backed by Greylock and Lightspeed Venture Partners, today announced a sweeping expansion of its platform that introduces always-on

A rápida transição da IA ​​generativa de chatbots baseados em texto para mídia de alta fidelidade – abrangendo imagens, vídeo, 3D espacial e

Redis construiu seu nome como a camada de cache que evitava que os aplicativos da web entrassem em colapso sob carga. O problema