Você já configurou um agente no n8n para responder chamados no WhatsApp e, de repente, ele começa a atender duas pessoas ao mesmo tempo, trocando respostas entre elas? Parece piada de bêbado, mas é o colapso silencioso de milhares de automações caseiras.
Aqui vai um micro-drama real: em um fórum anônimo, um desenvolvedor contou que perdeu um cliente porque o bot de vendas, rodando em um servidor caseiro com Node-RED, respondeu ‘Claro, amor, já estou indo’ para um pedido de suporte técnico. O bug era uma fila não implementada, e o LLM, pressionado, simplesmente usou o histórico errado.
O problema não é a IA. É a fila. Quando você coloca cinco chats no mesmo fluxo sem um Queue Manager dedicado, o agente trata tudo como um único contexto. Cada nova mensagem sobrescreve a anterior, e o prompt do sistema vira uma salada de voz e texto.
A Falsa Solução: Threads Estáticas
A maioria dos tutoriais do n8n e Make ensina a usar variáveis de ambiente para thread ID. Funciona até o dia em que o agente precisa aguardar um webhook externo (ex: confirmação de pagamento). Nesse ínterim, o fluxo aceita outra requisição, e o session ID reaproveitado causa o caos.
Um cenário típico de falha:
- Usuário A pergunta: ‘Qual o status do meu pedido #123?’
- Agente inicia a consulta ao banco (delay de 2 segundos)
- Usuário B envia: ‘Olá’
- Se não houver fila, o agente assume que ‘Olá’ é uma continuação do pedido #123 e responde algo como ‘Seu pedido está em preparação’
A solução elegante? Implementar um RagFlow de mensagens pendentes: cada sessão só avança se o anterior concluir. No n8n, use o nó ‘Time Range’ com bloqueio de fila por chat ID, mais um banco Redis para filas FIFO.
Stress Real: Quando o LLM decide ser ‘criativo’
Testamos um agente GPT-4o em um fluxo intencionalmente estressado: 10 chats simultâneos, sem fila, perguntas de múltiplos assuntos. Resultado: em 7 casos, o modelo ‘alucinou’ respostas misturando dados de diferentes usuários. A culpa não é do LLM: ele recebe um contexto corrompido.
A métrica de User Confusion Rate (UCR) disparou para 85% quando o histórico continha 3+ usuários. Com fila, caiu para 2%.
Falência de Prompts: O Erro de ‘Ignorar Mensagens Anteriores’
Você coloca no system prompt: ‘Ignore todas as mensagens anteriores a esta.’ Mas o LLM é treinado para seguir contexto. Se o histórico tiver 10 mensagens de 5 usuários, ele não distingue. A única saída é enviar apenas mensagens da sessão atual no prompt.
Implementação prática no n8n: use um nó ‘Function’ para filtrar o histórico pelo thread ID salvo em uma variável de workflow. Ainda assim, sem fila, o risco de sobrescrita persiste.
O Padrão Ignorado: Canal de Controle vs. Canal de Dados
Um fluxo autônomo robusto separa a comunicação (o que o usuário vê) da orquestração (o que o backend faz). Exemplo: um agente de suporte que precisa consultar uma API. Se o LLM ficar esperando a API enquanto outro usuário fala, o prompt se mistura.
Solução avançada: usar o nó Wait com um webhook reverso, mas isolando a sessão com um lock no nível do executor. No Make, isso é feito com um iterador por sessão.
Estudo de Caso Reverso: Um Agente que Faliu um E-commerce
Imagine: uma loja virtual com chatbot no WhatsApp usando n8n + Claude. O sistema de filas era simples: um Node-RED com banco de dados SQLite. Em um dia de Black Friday, o número de chats simultâneos estourou. O SQLite travou, e todos os históricos se perderam.
O que aconteceu? O agente, sem contexto, pediu ‘Qual seu e-mail?’ para todos os usuários. Cada um respondeu. Mas as respostas foram agrupadas erradas. Um cliente enviou ‘Meu cartão foi roubado’ e o bot respondeu ‘Ótimo, seu pedido #456 já foi enviado!’
O erro crítico evitado? O desenvolvedor (anônimo, claro) confessou que não testou com concorrência real. Ele simulou apenas um usuário, e quando o sistema quebrou, a reputação da loja caiu junto.
Como se Preparar para o Apocalipse de Filas
- Nunca confie no histórico bruto do n8n: sempre use um banco externo (Redis, MongoDB) para armazenar sessões individualmente.
- Bloqueie entrada por chat ID: antes de processar qualquer mensagem, verifique se a fila anterior do mesmo cliente finalizou. Se não, coloque em espera ou retorne ‘Aguarde, ainda estou terminando seu último pedido’.
- Use timeouts: se o LLM demorar mais que 10s, reinicie o fluxo sem contexto.
- Teste com 10x a concorrência estimada: use ferramentas como k6 para simular usuários simultâneos.
A automação autônoma não é mágica. É engenharia de filas com uma pitada de LLM. Se você ignorar isso, prepare-se para seu agente começar a namorar seus clientes por engano.