A VentureBeat publicou um diagnostico desconfortavel: organizacoes que tem agentes IA em producao tambem estao gerando uma nova classe de incidente que o sistema de postmortem nao captura. Tratam agentes autonomos e chaos engineering como disciplinas separadas, e essa lacuna esta produzindo a proxima onda de cascatas em producao. Segundo dados que a reportagem cita, 79% das organizacoes ja tem alguma forma de agente IA em producao, e 96% planejam expandir.

O caso classico da cascata

O exemplo central que a VentureBeat usa: agente de remediacao detecta latencia elevada num microservico e responde reiniciando o cluster. O que o agente nao sabe e que outros servicos estao em pico de trafego e que o pool de conexoes compartilhado ja esta a 87% de utilizacao. O restart dispara thundering herd contra o servico em recuperacao.

Depois do incidente, o postmortem registra “restart de servico durante pico” ou “saturacao de connection pool”. O agente fica invisivel. Ninguem treina o postmortem pra perguntar “que decisao autonoma disparou esse restart?”.

Os numeros que dimensionam o problema

A Gartner preve que 33% dos softwares corporativos terao IA agentica embutida ate 2028 — mas tambem preve que 40% desses projetos serao cancelados por controles de risco inadequados.

Na pratica, isso vira o cenario que a VentureBeat descreve: empresa coloca agente em producao porque ele resolve problema mensuravel, agente comeca a causar problema diferente, e o time de operacoes nao tem ferramental pra correlacionar causa.

Por que classificacao de incidente atual nao funciona

Ferramentas de observabilidade hoje sao desenhadas pra acoes humanas e processos automatizados deterministicos. PagerDuty, Datadog, ServiceNow esperam que toda mudanca venha de um ticket, um deploy, um runbook. Quando um agente toma uma decisao autonoma, ela nao aparece com esse rotulo.

A consequencia e dupla. Primeiro, o time de resposta nao identifica o agente como causa raiz. Segundo, sem identificacao, o postmortem nao gera acao corretiva sobre o agente, e o mesmo padrao se repete.

O que chaos engineering tradicional faz e o que precisa virar

Chaos engineering tradicional injeta falha de infra: derruba um node, satura uma rede, mata um pod. O time de SRE observa como o sistema responde. O modelo pressupoe que os atores no sistema sao deterministicos.

Agente IA quebra essa premissa. O agente toma decisao baseada em estado parcial, com prompt que muda ao longo do tempo, com modelo que pode ser atualizado sem warning. Chaos engineering pra agente exige injetar perturbacao no estado que o agente observa, nao so na infra que ele atua.

O caminho pratico pra time de plataforma

Pra time que ja tem agente em producao, o primeiro passo recomendavel e adicionar identificacao explicita de origem em todo log de mudanca de estado. Sem isso, nao da pra correlacionar incidente a comportamento de agente.

O segundo passo e revisar runbooks de postmortem pra incluir a pergunta “alguma acao autonoma de agente contribuiu pra esse incidente?”. Se a resposta for sim, o incidente entra em fila de revisao de comportamento de agente, nao so de infra.

Onde a promessa de agente em prod ainda precisa ser provada

A grande maioria das empresas que rodam agente em prod ainda mede sucesso por taxa de acerto e por automacao percentual de tarefa. Quase nenhuma mede taxa de incidente atribuivel a comportamento de agente. Ate isso virar parte do dashboard padrao, agente vai continuar virando “restart de servico” no postmortem, e o problema vai escalar silenciosamente.

Reportado originalmente por VentureBeat em 2026-05-25.