Como a Stream criou um agente de IA para investigar problemas em produção

A Stream montou um agente que faz a primeira investigação de incidentes do back-end de chat. Ele lê logs, bancos, métricas e código, posta a causa raiz com evidências no Slack e espera aprovação humana para qualquer mudança em produção. O pipeline tem quatro etapas: triagem com Claude Haiku, investigação com Claude Opus em sandbox, revisão por uma sessão nova e entrega no thread.

A segurança não depende de prompt. Como a investigação lê texto não confiável (mensagens de clientes, descrições de tickets) e alcança dados sensíveis, o risco de prompt injection é real. Por isso o ambiente impõe os limites: container isolado com cópia somente leitura do código, ferramentas read-only, credenciais dos bancos fora do sandbox, rede restrita e filtro de saída contra segredos e conteúdo literal de clientes. Só membros do time de engenharia de chat aprovam correções, que viram pull request em rascunho ou runbook executado por uma pessoa. Os testes usam 22 casos, muitos tirados de threads reais e de erros do próprio agente, rodados manualmente porque usam chamadas reais ao modelo e custam dinheiro.

A cobertura anterior do CEVIU trata de outras empresas, então não há evolução do mesmo produto. Mas o tema de avaliação se repete: em 9 de abril de 2026 e em 8 de maio de 2026, o CEVIU noticiou "Como construímos uma plataforma de avaliação real para agentes SRE autônomos em escala", em que a Datadog testa seu agente SRE de IA em incidentes passados. A Stream segue lógica parecida ao usar incidentes reais e erros antigos como casos de teste, em escala bem menor.

Para quem pensa em colocar um agente de IA em plantão, a leitura é que a confiança vem da arquitetura, não do prompt. Exigir citação de evidência, revisão com contexto limpo e permissões somente leitura torna a saída verificável e reduz o estrago de um erro. Transformar falhas do agente em casos de teste é uma prática que qualquer time consegue copiar.