Gatilhos, filas e tratamento de erro

O módulo 1 deu o desenho: gatilho, etapas, caminho de falha e pontos de aprovação humana, tudo decidido no papel antes de qualquer ferramenta. Este módulo traduz esse desenho em três componentes técnicos que toda automação séria precisa ter, independentemente da plataforma escolhida para implementá-los.

Não é sobre uma ferramenta específica — é sobre o vocabulário e os conceitos que valem para qualquer uma delas, para você conseguir avaliar e configurar o que escolher com critério.

Gatilhos: mais restritivo é mais seguro

O gatilho é o evento que inicia o fluxo. O módulo 1 já disse que ele precisa ser detectável sem ambiguidade — este módulo acrescenta um segundo critério: quanto mais restritivo o gatilho, mais fácil é prever o que vai disparar o fluxo.

"Qualquer e-mail novo" é um gatilho amplo demais — ele vai capturar spam, respostas automáticas de outros sistemas, coisas que nunca deveriam entrar no fluxo. "E-mail novo com assunto começando em 'Pedido #'" é restritivo e previsível.

Regra prática: comece o gatilho mais restritivo do que parece necessário. É mais fácil ampliar depois de ver o fluxo funcionando do que descobrir, depois de rodar em produção, que ele estava capturando coisa que não devia.

Filas: o amortecedor entre etapas

Uma fila é onde um item espera entre uma etapa e a próxima. Parece um detalhe técnico, mas é o que evita dois problemas comuns:

• Perda de item. Sem fila, se uma etapa cair no meio do processamento, o item pode simplesmente desaparecer do fluxo sem deixar rastro. Com fila, o item continua esperando até a etapa seguinte conseguir processá-lo.
• Sobrecarga. Se muitos itens chegam de uma vez (um pico de pedidos, por exemplo), processar tudo simultaneamente pode derrubar uma etapa que depende de um serviço externo com limite de uso. A fila permite processar na velocidade que o sistema aguenta, sem perder nada — só atrasar.

Todo fluxo com mais de uma etapa deveria ter fila entre elas, mesmo que pareça desnecessário no volume atual. O custo de configurar é pequeno; o custo de não ter quando o volume cresce é alto.

Tratamento de erro: três respostas possíveis

O módulo 1 pediu para desenhar o caminho de falha. Na prática, toda etapa que pode falhar tem três respostas possíveis configuráveis, e a escolha certa depende do tipo de falha:

• Tentar de novo (retry). Serve para falhas temporárias — um serviço externo fora do ar por alguns segundos, uma instabilidade de rede. Sempre com um limite de tentativas; sem limite, um erro permanente vira um loop infinito silencioso.
• Enviar para revisão humana. Serve para falhas que exigem julgamento — um dado que não bateu com o formato esperado, uma classificação com confiança baixa (como no exemplo do módulo 1). É a mesma lógica do "humano no circuito" do curso de IA para Produtividade, aplicada dentro de uma automação.
• Parar o fluxo inteiro. Reservado para falhas que indicam algo estrutural errado — não um item ruim, mas o processo inteiro quebrado. Continuar rodando nesse caso propagaria o mesmo erro para todos os itens seguintes.

Decidir, para cada etapa, qual das três respostas se aplica é parte do desenho — não pode ser deixado para configuração padrão da ferramenta, porque o padrão raramente conhece o custo real de cada tipo de erro no seu processo específico.

Juntando os três no exemplo do módulo 1

Voltando à triagem de mensagens de clientes do módulo anterior:

• Gatilho restritivo: nova mensagem na caixa compartilhada, ignorando remetentes já marcados como automáticos.
• Fila entre classificar e rotear: garante que um pico de mensagens não sobrecarregue a etapa de classificação.
• Tratamento de erro: falha ao classificar → retry único; confiança baixa → revisão humana (não é falha técnica, é o caminho já desenhado); indisponibilidade total do classificador → parar o fluxo e alertar, em vez de rotear tudo como "outro" sem verificação.

Exercício

Pegue o processo que você desenhou no exercício do módulo 1. Para cada etapa, defina: o gatilho é restritivo o suficiente? existe fila entre as etapas? qual das três respostas de erro se aplica a cada tipo de falha possível?

O que fica

• Gatilhos mais restritivos são mais seguros — comece restritivo, amplie depois de validar.
• Filas evitam perda de item e sobrecarga entre etapas; valem mesmo em baixo volume.
• Toda etapa que pode falhar precisa de uma resposta definida: retry (falha temporária), revisão humana (exige julgamento) ou parar o fluxo (falha estrutural).
• A escolha da resposta de erro não deve ficar no padrão da ferramenta — depende do custo real de cada tipo de falha no seu processo.