Padrões de workflow com LLM: encadeamento, roteamento e paralelização
Entenda encadeamento, roteamento e paralelização em fluxos com LLM, com exemplos de negócio e critérios para saber quando evitar um agente autônomo.
Quer aplicar isso na sua empresa?
Agendar conversa com o Juan →Padrões de workflow com LLM: encadeamento, roteamento e paralelização
Os padrões de workflow com LLM mais usados são o encadeamento (cada etapa alimenta a seguinte), o roteamento (a entrada é classificada e enviada ao caminho certo) e a paralelização (tarefas independentes rodam ao mesmo tempo e os resultados são combinados). Em todos eles, o código define o caminho e o modelo executa passos delimitados, o que costuma ser mais previsível e mais fácil de auditar do que um agente autônomo. Para a maioria dos processos de empresa, começar por um desses padrões é a decisão mais segura.
Principais pontos
- Workflow é um fluxo em que o caminho é definido por você em código ou em uma ferramenta de automação. Agente é quando o modelo decide sozinho os próximos passos.
- Encadeamento serve para tarefas que se decompõem em etapas fixas, com uma checagem entre elas.
- Roteamento serve para separar tipos de pedido e mandar cada um para um tratamento especializado, inclusive para uma pessoa.
- Paralelização serve para ganhar velocidade em partes independentes ou para comparar mais de uma resposta antes de decidir.
- Um agente autônomo só se justifica quando o número de passos não pode ser previsto e o erro tem custo baixo ou é reversível.
Workflow ou agente: qual é a diferença na prática?
A distinção vem da documentação da Anthropic sobre construção de agentes, que separa workflows (modelos e ferramentas orquestrados por caminhos predefinidos) de agentes (sistemas em que o modelo dirige o próprio processo e o uso de ferramentas). Essa separação é útil para quem decide, porque muda o que você precisa controlar.
Num workflow, você sabe de antemão quais etapas existem, em que ordem rodam e onde há uma pessoa revisando. Se algo der errado, o log mostra qual etapa falhou. Num agente, o número de passos varia, o gasto varia e o caminho muda de uma execução para outra. Isso pode ser exatamente o que um problema aberto exige, mas é raro em rotinas de atendimento, financeiro ou operação.
Uma regra prática, que é nossa leitura de implementação e não uma regra oficial: comece pelo menor grau de autonomia que resolve o problema e só suba um degrau quando um teste mostrar que o degrau anterior não basta. Para uma visão complementar sobre quando dividir em vários agentes, vale ler Sistema multiagente: quando um único agente de IA basta.
Encadeamento: quando cada etapa depende da anterior
No encadeamento (prompt chaining), uma tarefa é quebrada em etapas e a saída de uma chamada ao modelo vira entrada da próxima. Entre as etapas você pode colocar uma verificação simples, em código, que decide se o fluxo segue ou para.
O ganho é que cada chamada fica com uma tarefa estreita, mais fácil de instruir, testar e corrigir. O custo é mais latência, porque as etapas rodam em sequência.
Exemplos de negócio em que o encadeamento funciona bem:
- Resumo de reunião comercial: extrair decisões e pendências, depois formatar no padrão do CRM, depois validar campos obrigatórios. O tema aparece em Como atualizar o CRM com IA depois da reunião de vendas.
- Proposta comercial: levantar requisitos da conversa, montar o rascunho, checar se todos os itens obrigatórios estão presentes, enviar para revisão humana.
- Resposta a reclamação pública: resumir o histórico, redigir um rascunho, conferir tom e promessas proibidas, aprovar.
Um cuidado de projeto: coloque a checagem entre etapas em código sempre que possível. Verificar se um campo existe, se um valor está dentro de uma lista permitida ou se o texto contém uma promessa proibida não precisa de modelo. Reservar o modelo para o que exige interpretação deixa o fluxo mais barato e mais previsível.
Roteamento: classificar antes de responder
No roteamento, a primeira etapa classifica a entrada e o fluxo segue por um caminho específico. Cada caminho pode ter instruções, ferramentas, modelo e nível de permissão próprios. É o padrão mais natural para atendimento, porque mensagens de clientes misturam assuntos que não deveriam receber o mesmo tratamento.
Um roteador bem desenhado costuma ter estas características:
- Um conjunto fechado de categorias, incluindo sempre uma categoria "não sei" ou "outros" que leva a uma pessoa.
- Saída estruturada (apenas o nome da categoria), validada em código antes de seguir.
- Regras determinísticas antes do modelo, quando existem. Se a mensagem traz um número de pedido ou vem de um canal específico, talvez nem seja preciso perguntar ao modelo.
- Registro da categoria escolhida em cada execução, para medir erros de roteamento depois.
Um benefício menos óbvio é o controle de risco. Pedidos de segunda via ou de status podem ir para um caminho com ferramentas somente de leitura. Pedidos de cancelamento, reembolso ou dados pessoais podem ir direto para uma fila humana. Assim a permissão acompanha o tipo de pedido, e não a boa vontade do modelo. Para ver como isso se aplica a atendimento, o texto SAC com inteligência artificial: o que automatizar e o que manter detalha a separação.
Outro ponto: rotear também serve para custo. Perguntas simples podem ir para um modelo menor e mais barato, e casos ambíguos para um modelo mais capaz. Isso é uma hipótese a validar com seus próprios dados, não uma garantia.
Paralelização: dividir o trabalho ou comparar respostas
A documentação da Anthropic descreve duas variações de paralelização. Na primeira, a divisão (sectioning), partes independentes de uma tarefa rodam ao mesmo tempo. Na segunda, a votação (voting), a mesma tarefa roda mais de uma vez para obter respostas diferentes e aumentar a confiança no resultado.
Exemplos de divisão:
- Analisar um contrato em frentes independentes (prazos, multas, proteção de dados) e juntar os achados num relatório único.
- Processar vários documentos de um mesmo cliente ao mesmo tempo, cada um com a mesma instrução.
- Rodar uma checagem de política (conteúdo impróprio, dado sensível) em paralelo à geração da resposta, em vez de depois dela.
Exemplos de votação:
- Classificar um caso de risco com duas ou mais chamadas independentes e encaminhar para revisão humana quando divergirem.
- Revisar um trecho de código ou de texto jurídico com instruções diferentes e comparar os alertas.
Para decidir se vale, pergunte se as partes são de fato independentes. Se uma depende do resultado da outra, é encadeamento. E pergunte se o custo adicional de chamadas extras se paga: cada chamada consome tokens, e o gasto sobe de forma proporcional. O texto O que são tokens em IA e por que eles definem o custo ajuda a estimar isso.
Cenário ilustrativo: pedidos pelo WhatsApp em uma loja de peças
Imagine uma loja de peças que recebe mensagens de clientes no WhatsApp. Este é um cenário ilustrativo, sem relação com nenhuma empresa real, que combina os três padrões.
Primeiro, um roteador classifica a mensagem em uma de poucas categorias: orçamento de peça, status de pedido, troca ou garantia, e outros. Mensagens em "troca ou garantia" e "outros" vão direto para uma pessoa, com um resumo preparado.
No caminho de orçamento, um encadeamento entra em ação. A primeira etapa extrai da conversa o modelo do veículo e a peça desejada. Uma checagem em código confirma que os dois campos existem e que a peça consta no catálogo. Se faltar algo, o fluxo faz uma pergunta objetiva ao cliente. Se estiver completo, a segunda etapa consulta estoque e monta o rascunho de resposta.
Na montagem do rascunho, duas verificações rodam em paralelo: uma confere se o texto não promete prazo que o sistema não confirmou, e outra confere se não há dado pessoal desnecessário na resposta. Se qualquer uma sinalizar, o rascunho vai para revisão humana antes de ser enviado.
Nenhuma etapa decide sozinha o que fazer a seguir. O caminho é conhecido, os logs mostram cada decisão e a pessoa entra onde o risco é maior. Para ligar um fluxo assim ao WhatsApp, o guia n8n com WhatsApp Cloud API: como montar um fluxo de atendimento mostra uma base prática.
Quando evitar um agente autônomo?
Um agente autônomo faz sentido em problemas abertos, em que não dá para prever as etapas e o ambiente oferece retorno claro a cada passo. Mesmo assim, a própria Anthropic recomenda buscar a solução mais simples possível e aumentar a complexidade só quando necessário. Use esta lista como guia de decisão:
- Se você consegue desenhar o processo como um fluxograma com poucos ramos, use workflow.
- Se o erro causa dano difícil de desfazer (pagamento, cancelamento, envio de dado pessoal, contato com o cliente), mantenha aprovação humana e caminho fixo.
- Se você precisa explicar a um auditor, ao cliente ou à ANPD por que uma decisão foi tomada, prefira etapas registradas a um raciocínio livre. O texto sobre decisões automatizadas na LGPD trata do direito de revisão.
- Se o custo por execução precisa ser previsível, evite agentes sem teto de passos, tempo e gasto. Veja Agente de IA em loop infinito: limites de passos, tempo e gasto.
- Se o agente leria conteúdo externo (e-mails, páginas, anexos) e ainda poderia agir com ferramentas, o risco de prompt injection cresce. A folha de prevenção da OWASP é uma boa referência.
Em contrapartida, um agente pode valer a pena em tarefas como investigação exploratória, em que a pessoa revisa o resultado final e nenhuma ação irreversível acontece no caminho. Mesmo nesse caso, comece com ferramentas somente de leitura.
Como colocar um desses padrões em operação
O método que usamos segue quatro movimentos: mapear, limitar, pilotar e transferir. Aplicado a workflows com modelo, fica assim:
- Mapear: descreva o processo atual como ele é, com entradas, saídas, exceções e quem decide. Anote uma linha de base (como o trabalho é feito hoje) antes de qualquer automação.
- Limitar: defina quais dados o fluxo pode ver, quais ações pode executar e em que pontos uma pessoa aprova. Quando dados pessoais saem do país por causa do provedor do modelo, confira o que a LGPD exige ou considere rodar um modelo local.
- Pilotar: escolha um fluxo real, com registro de cada etapa e uma métrica de sucesso combinada de antemão. Monte um conjunto de casos de teste (as guias de avaliação da OpenAI e da Anthropic explicam como pensar nisso).
- Transferir: entregue a documentação, os logs e os critérios de revisão para a equipe, e decida em conjunto se vale expandir, ajustar ou parar.
Sobre falhas, trate o fluxo como qualquer integração: tempo limite, nova tentativa com critério e registro do erro. O artigo Erros e retentativas no n8n: fluxos de IA que não quebram cobre esse lado.
Perguntas frequentes
Qual padrão devo usar primeiro? Comece pelo encadeamento se o processo já é uma sequência de etapas, e pelo roteamento se o problema é a mistura de tipos de pedido. Em geral, os dois aparecem juntos: o roteador escolhe o caminho e cada caminho é uma cadeia curta. A paralelização entra depois, quando houver um motivo concreto de velocidade ou de confiança.
Workflow com LLM precisa de uma ferramenta específica? Não. Você pode montar com uma ferramenta de automação visual, com código em Python ou TypeScript, ou com plataformas de agentes. O que importa é que as etapas, as validações e os logs fiquem explícitos, seja qual for a ferramenta escolhida.
Paralelizar deixa o fluxo sempre mais rápido e melhor? Não necessariamente. Dividir tarefas independentes reduz o tempo de espera, mas aumenta o número de chamadas e o gasto. A votação pode elevar a confiança, mas só se as respostas forem de fato independentes e se você tiver uma regra clara para o caso de divergência.
Um workflow elimina a necessidade de revisão humana? Não. Ele torna a revisão mais focada, porque você sabe em qual etapa e por qual motivo o caso foi sinalizado. Em decisões que afetam pessoas, dinheiro ou dados pessoais, a aprovação humana continua sendo o controle mais confiável.