Contexto
Eu trabalhava em uma plataforma de checkout e pagamentos onde as mesmas perguntas operacionais voltavam toda semana: esse meio de pagamento está falhando para o lojista X, esse pedido realmente falhou, esse comportamento vem de uma feature flag. As respostas existiam, mas estavam espalhadas por ferramentas com modelos de autenticação e linguagens de consulta diferentes: observabilidade (Sentry, Grafana, Prometheus, Loki), analytics de produto (Mixpanel), feature flags (GrowthBook), rastreamento de issues (Linear), Slack e um conjunto de runbooks operacionais.
Engenheiros passavam parte do dia funcionando como um buscador entre seis dashboards.
Problema
- Perguntas operacionais de baixa complexidade consumiam tempo de engenharia que era para produto.
- Responder exigia saber em qual ferramenta olhar e como consultá-la.
- Várias fontes guardam dados pessoais, então a automação tinha que ser segura por construção, não segura por política.
- As respostas tinham que ser defensáveis: resposta a incidente é tão boa quanto a evidência por trás dela.
Minha responsabilidade
Desenvolvi o ADA: o serviço do agente, as integrações com as ferramentas e o modelo de permissões que decide o que o agente pode ler.
O que eu implementei
- Um serviço de agente em TypeScript/Node.js, hospedado na Vercel, usando LLMs via Amazon Bedrock (Claude).
- Integrações com ferramentas: Slack, Sentry, Grafana, Prometheus, Loki, Mixpanel, Linear e GrowthBook, uma mistura de ferramentas próprias e de ferramentas expostas via MCP.
- Um modelo de acesso somente leitura: o agente pode inspecionar estado, nunca alterá-lo.
- Autenticação com OIDC/OAuth mais permissões granulares por ferramenta, para o alcance do agente ser explícito em vez de implícito.
- Proteção de dados pessoais sobre o que cada ferramenta pode devolver.
- Análise de feature flags, transformando "essa flag é a responsável?" em uma pergunta respondida com dados.
- Investigação automática de incidentes: correlacionando sinais entre ferramentas antes de um humano começar a cavar.
- Uma base de conhecimento de runbooks operacionais que o agente consulta em vez de improvisar procedimento.
- Um digest diário de hypercare por lojista, entregue de forma agendada, para os problemas aparecerem antes de alguém abrir um chamado.
Como funciona
Uma solicitação chega pelo Slack. O agente planeja quais ferramentas chamar, chama por meio da camada autenticada de ferramentas e compõe a resposta a partir da evidência retornada. Como as ferramentas são somente leitura e com escopo definido, a pior consequência de uma escolha ruim é uma consulta inútil, não uma alteração em produção. O mesmo serviço é reutilizado por um job agendado que gera o digest diário por lojista.
Decisões de design e trade-offs
- Somente leitura, de propósito. O agente não pode agir em produção. Trade-off: ele não corrige nada automaticamente, então um humano ainda executa a correção. Aceitei um ciclo mais lento em troca de uma automação que nunca pode causar um incidente.
- Integrar as ferramentas que os times já usam em vez de construir um novo repositório de dados de observabilidade. Trade-off: herdamos os limites de taxa, a linguagem de consulta e as peculiaridades de autenticação de cada fornecedor, e o frescor das informações do agente depende dessas ferramentas.
- Permissões granulares em vez de uma credencial ampla. Trade-off: mais configuração e mais peças móveis, mas uma ferramenta mal usada ou vazada não consegue ler tudo.
- Runbooks como conhecimento explícito em vez de confiar que o modelo lembra o procedimento. Trade-off: os runbooks precisam de manutenção, ou o agente vai seguir com confiança um processo desatualizado.
Resultado
Cerca de 70% menos chamados de suporte chegando ao time de desenvolvimento depois que o ADA passou a responder perguntas operacionais e a fazer a triagem inicial de incidentes.
O que aprendi
- No design de agentes, a superfície restrita (o que uma ferramenta pode fazer) importa mais que o prompt.
- Somente leitura e menor privilégio são decisões de engenharia, não políticas: precisam estar codificadas na camada de integração.
- Um agente só é útil quando as ferramentas devolvem evidência real; caso contrário ele produz texto plausível com o qual ninguém consegue agir.