MoWave One: Agentes de auditoria IA e o limite de sessão

A gente realizou recentemente uma auditoria completa de segurança e qualidade no app Lima, um workflow multiagente desenhado para nos dar insights aprofundados. A ambição era alta: oito auditores, cada um focado em uma dimensão específica, seguidos por três céticos adversariais por achado, culminando em uma fase de síntese. Essa configuração sofisticada foi pensada para varrer exaustivamente nosso codebase, garantindo que o MoWave One mantenha seus altos padrões para nossos usuários em https://getlima.app.

O Problema: Resultados Vazios de uma Auditoria Exaustiva

A execução inicial do nosso workflow de auditoria multiagente não saiu como planejado. Apesar do design intrincado, o processo inteiro atingiu um limite de taxa de sessão. Esse limite, que reseta às 06:40 horário local, efetivamente estrangulou nossos agentes. O resultado foi claro: o workflow completou, mas não retornou nenhum achado. Isso não foi porque nosso código era impecável (embora a gente se esforce para isso), mas porque os agentes não conseguiram completar suas tarefas dentro da janela de sessão permitida. Um relatório vazio de uma auditoria exaustiva é um sinal de alerta, indicando um problema sistêmico com o próprio processo de auditoria, e não um atestado de saúde para o software.

A Causa Técnica: Throttling de Agentes Não Planejado

A causa técnica subjacente foi uma restrição simples, mas esquecida: o limite de taxa de sessão. Nosso workflow multiagente, com seus 8 auditores primários e subsequentes 3 céticos adversariais por achado, gera um número significativo de sessões independentes. Embora a sessão individual de cada agente pudesse ser breve, a carga cumulativa em todos os agentes, especialmente durante a fase de céticos adversariais, onde múltiplos agentes podem ser disparados por achado inicial, rapidamente esgotou a capacidade de sessão disponível antes do reset das 06:40 horário local. O sistema, na tentativa de prevenir abuso ou carga excessiva, simplesmente parou de processar novas requisições dos nossos agentes de auditoria, levando a uma falha silenciosa onde nenhum achado pôde ser reportado.

A Correção: Auditoria Focada em Loop Único e Divulgação Honesta

Em vez de tentar re-executar o workflow multiagente completo imediatamente ou, pior, fingir que o relatório vazio significava um atestado de saúde, a gente pivotou. A gente reconheceu a limitação e decidiu por uma auditoria mais focada, de loop único. Essa estratégia de fallback mirou na superfície de maior risco: os 313 commits feitos desde nossa última auditoria completa. Isso incluiu áreas críticas como journal, finance recurrence, attachments, community, AI conversation management e plan gates.

A gente fez o deploy de um agente mais simples, de uma única passagem, focado puramente nessas mudanças recentes. Isso nos permitiu contornar o limite de sessão, reduzindo significativamente a concorrência e a contagem total de sessões. A densidade de achados dessa auditoria focada foi intencionalmente baixa. Isso era esperado, já que a maioria do nosso código novo já é projetada com padrões robustos: optimistic locking com uma coluna de versão, explicit gates, ShedLock para distributed locks, mecanismos fail-closed em superfícies públicas e sanitização rigorosa de inputs. Esses padrões são fundamentais para como a gente constrói no MoWave One, visando capturar vulnerabilidades cedo no ciclo de desenvolvimento.

Crucialmente, a gente documentou a limitação honesta dessa abordagem. A gente declarou explicitamente que a varredura exaustiva de 8 dimensões, que era o objetivo original, não pôde ser completada e precisaria ser re-executada após o reset do limite de sessão. A transparência sobre o que não foi coberto é tão importante quanto reportar o que foi.

Lições Aprendidas

A auditoria assistida por IA oferece uma alavancagem significativa para segurança e garantia de qualidade. No entanto, não é uma bala de prata e pode falhar de maneiras que exigem planejamento cuidadoso e estratégias de fallback. É essencial antecipar e planejar restrições de recursos, como limites de sessão, ao projetar workflows multiagentes complexos. Quando uma auditoria planejada não consegue atingir sua cobertura total, é vital nomear a cobertura que não foi alcançada, em vez de obscurecê-la. A honestidade sobre as limitações constrói confiança, tanto internamente quanto com nossos usuários, e garante que áreas críticas não sejam deixadas sem exame devido a um processo incompleto.