Como criar uma condição com IA no seu fluxo: o “se” que entende linguagem natural

Fala aí, beleza? Seu if com regex procura "reembolso" na mensagem e tá tudo lindo… até o cliente escrever "quero meu dinheiro de volta" 😛

Aí a regra simplesmente não dispara, e ninguém fica sabendo

A ideia deste post é trocar essa regra rígida por uma condição com IA: um "se" que entende a intenção da frase, não só as palavras que estão nela

E, MUITO mais importante, desenhar o que o fluxo faz quando a resposta vem falsa ou ambígua, que é justamente a parte que costuma ficar esquecida

Bora ver na prática?

Por que if e regex não dão conta de linguagem natural

Pega o exemplo do reembolso

A regra literal é algo como "se a mensagem contém reembolso, manda pro financeiro"

Parece ok, né? Só que ela erra em pelo menos três situações bem comuns:

• Sinônimos: "quero meu dinheiro de volta", "dá pra estornar?", "cancela e devolve o valor" (nenhuma tem a palavra mágica)
• Negação: "não quero reembolso, quero troca" tem a palavra, então a regra dispara errado
• Frase indireta: "fui cobrado duas vezes e não reconheço essa compra" é um pedido de reembolso sem dizer reembolso

Tu até pode ir remendando a regex com mais palavras e mais exceções

Mas aí vira aquele monstro que ninguém tem coragem de mexer haha

Lógica escrita x julgamento

O problema é de natureza, não de capricho

Regex e if são lógica escrita: você descreve exatamente o padrão e a máquina confere se o texto bate

Uma condição com IA é julgamento: você descreve o que quer dizer e o modelo decide se a frase significa aquilo

Se você conhece o Ctrl+F, a regex é bem semelhante: acha a palavra, mas não sabe o que ela quer dizer

Já a condição avaliada por IA é como pedir pra um colega ler o email e te dizer "esse cliente quer o dinheiro de volta, sim ou não?"

Um bom exemplo do modelo antigo é o nó If/else do OpenAI Agent Builder: ele usa expressões CEL (Common Expression Language), ou seja, lógica escrita, não avaliação em linguagem natural

E se liga: a OpenAI está descontinuando o Agent Builder, que será desligado em 30 de novembro de 2026, com migração recomendada para o Agents SDK ou para os ChatGPT Workspace Agents

Quando o if tradicional ainda é melhor

Nem tudo precisa de IA, beleza?

O if comum continua imbatível quando:

• A regra é determinística (sempre a mesma resposta pra mesma entrada)
• O dado já vem em campo estruturado, tipo status do pedido igual a "pago"
• A comparação é numérica, tipo valor acima de um limite

Usar IA pra ler um campo que já diz "pago" é só deixar o fluxo mais lento e menos previsível 🙂

Onde montar uma condição com IA: n8n, Langdock, Claude Code e Claude API

Cada ferramenta resolve isso de um jeito, e o detalhe que mais muda entre elas é o que acontece quando nada bate

Repara que só a Claude API não tem um "ramo de sobra" pronto

Lá, o caso ambíguo existe só se tu desenhar ele no schema (já já a gente faz isso)

O que você precisa antes de começar

Antes de abrir qualquer ferramenta, separa isso aqui:

• A regra atual escrita em uma frase, tipo "o cliente pediu reembolso?"
• Exemplos reais de mensagens pra conferir o resultado: alguns claramente positivos, alguns claramente negativos e alguns ambíguos
• Uma das ferramentas da tabela que você já usa no seu fluxo
• O destino de cada ramo decidido antes: pra onde vai o verdadeiro, pra onde vai o falso e pra onde vai o ambíguo

Esse último item parece burocracia, mas é ele que evita mensagem sumindo no meio do caminho…

Passo a passo: transformando a regra em condição avaliada por IA

Agora sim, bora transformar aquele if frágil numa condição com IA de verdade

1. Reescreva a regra como pergunta ou categoria com descrição clara

O modelo não adivinha o que você tem na cabeça

No Text Classifier do n8n, cada categoria tem um nome e uma descrição, e a descrição explica ao modelo o que ela significa, o que faz MUITA diferença quando o significado não é óbvio

Então diz o que conta e o que NÃO conta:

Categoria: reembolso
Descrição: o cliente quer o dinheiro de volta (reembolso, estorno, cancelamento com devolução do valor, cobrança que ele não reconhece). NÃO conta: pedido de troca de produto, dúvida sobre prazo sem pedir o dinheiro de volta

Bateu a dúvida se dá pra escrever essa descrição em português? A lógica é parecida com a de escrever o pedido no seu idioma: o que pesa é a clareza do que você quer

Erro comum: criar a categoria só com o nome ("reembolso") e deixar o modelo inferir o resto

2. Escolha o componente

Depende de onde o seu fluxo já vive: Text Classifier no n8n, nó Condition em modo Prompt AI na Langdock, hook do tipo prompt no Claude Code ou uma chamada à API com structured output

Na Langdock, lembra que o modo Manual não usa IA, e o modelo escolhido vale só pras condições em Prompt AI

Erro comum: usar IA onde um campo estruturado resolveria (se o sistema já marca o ticket como "reembolso", um if comum dá conta)

3. Feche o formato da resposta

Pedir "responda sim ou não" e torcer pro modelo obedecer é receita pra dor de cabeça

As structured outputs da Claude API obrigam a resposta a seguir um JSON Schema, o que garante uma saída válida e fácil de processar nas etapas seguintes

Um schema enxuto, com o booleano, um marcador de ambíguo e o motivo:

{
  "type": "object",
  "properties": {
    "pediu_reembolso": { "type": "boolean" },
    "ambiguo": { "type": "boolean" },
    "motivo": { "type": "string" }
  },
  "required": ["pediu_reembolso", "ambiguo", "motivo"],
  "additionalProperties": false
}

Na API, esse schema vai em output_config.format (se tu viu output_format em exemplo antigo, é o nome anterior do parâmetro)

No Agent SDK, a opção é outputFormat (ou output_format), e o JSON Schema pode ser gerado a partir de Zod ou Pydantic

Erro comum: pedir texto livre e tentar interpretar depois com… regex 😅

4. Defina se é uma classe só ou várias por item

O Text Classifier pode aceitar várias classes verdadeiras por item ou só uma

Se precisar ajustar o comportamento, dá pra personalizar o system prompt com um template que usa o placeholder {categories}

Erro comum: deixar várias classes ligadas quando o fluxo só aceita um caminho (a mensagem "quero trocar, senão me devolve o dinheiro" cai em dois ramos ao mesmo tempo)

5. Rode os exemplos reais e leia o motivo

Passa as mensagens que você separou e compara o resultado com o que você esperava

Quando errar, lê o motivo devolvido: ele quase sempre aponta qual parte da descrição ficou vaga, e aí você ajusta o texto da categoria ou da condição

Rodar a mesma mensagem mais de uma vez também ajuda a ver se a resposta é estável, no mesmo espírito de um teste com prompts repetidos

Como tratar condição falsa ou ambígua no fluxo

Essa é a parte que separa uma automação massa de uma que perde cliente sem ninguém perceber

Porque a condição com IA não vai acertar 100% das vezes, e tudo bem, desde que o fluxo saiba o que fazer com a dúvida

1. Separe três estados: sim, não e não dá pra decidir

Isso não é invenção minha, as próprias ferramentas da Anthropic pensam assim

O hook do tipo prompt do Claude Code responde neste formato:

{"ok": false, "reason": "explicação da decisão", "impossible": false}

E o avaliador do /goal devolve um de três veredictos, cada um com um motivo curto: "Not yet met", "Met" ou "Impossible"

Dois estados não bastam: o mundo real tem o "talvez"

2. No n8n, ligue o ramo "Other"

No Text Classifier, quando não há correspondência clara, o item é descartado por padrão

Ativando "Output on Extra, Other Branch", ele vai pra um ramo extra "Other" em vez de sumir

Erro comum: esquecer que o padrão é descartar (já pensou o cliente pedindo reembolso de um jeito estranho e a mensagem simplesmente evaporando?)

3. Na Langdock, decida de forma consciente sobre o "Force Select Branch"

Desligado (o padrão), a IA pode não escolher nenhum ramo se nenhuma condição bater

Ligado, ela é obrigada a escolher pelo menos um ramo, fazendo a melhor escolha possível

Desligado faz sentido quando existe triagem humana pra pegar o que sobrou

Ligado faz sentido quando o fluxo não pode parar de jeito nenhum, mas aí você aceita que a IA vai "chutar" o melhor caminho nos casos duvidosos

4. Mande o ambíguo pra revisão humana ou pra uma pergunta de esclarecimento

O caso duvidoso vai pra uma fila de atendimento ou dispara uma resposta tipo "você quer trocar o produto ou receber o valor de volta?"

E leva junto o motivo que a IA devolveu, assim quem pega o caso já sabe onde ela travou

5. Registre o reason pra auditoria

Guarda o motivo de cada decisão, junto com a mensagem original

Quando alguém perguntar "por que esse cliente caiu no financeiro?", tu tem a resposta, e ainda ganha material pra melhorar a descrição da condição

Erro comum: tratar ambíguo como falso, o que na prática é o mesmo bug da regex, só que com mais passos haha

Exemplos de condições com IA que valem a pena

Alguns use cases onde o julgamento faz MUITO mais sentido que a regra escrita:

• Triagem de atendimento: separar reembolso, troca, reclamação e dúvida, com descrição clara de cada categoria e ramo "Other" ligado
• Aprovação de conteúdo antes de publicar: uma condição que avalia se o texto segue as regras do seu guia, com o motivo registrado quando reprova
• Roteamento de leads por intenção: quem quer comprar agora, quem está pesquisando e quem só quer suporte, cada um pro seu caminho
• Condição de conclusão no Claude Code: o comando /goal define uma condição de conclusão, e o Claude segue trabalhando até cumpri-la, com um avaliador separado (o modelo pequeno e rápido configurado) checando a condição depois de cada turno
• Hooks do tipo prompt no Claude Code: a documentação indica esse tipo pra decisões que pedem julgamento em vez de regra determinística

Se liga num detalhe do /goal: o avaliador julga a condição pelo que aparece na conversa

Ele não roda comandos nem lê arquivos por conta própria

Então "os testes passam" só funciona como condição se a saída do Claude mostrar os testes passando, beleza? Escreve a condição pensando no que dá pra demonstrar na conversa

Próximo passo: troque um if do seu fluxo hoje

Não precisa refazer a automação inteira, pega UMA regra frágil, aquela que vive quebrando com sinônimo e negação

Reescreve ela como condição com uma descrição clara do que conta e do que não conta

Força a saída estruturada, com o booleano e o motivo

E cria o ramo do ambíguo antes de qualquer outra coisa (ramo "Other" no n8n, decisão consciente sobre o "Force Select Branch" na Langdock, campo próprio no schema da API)

O que for regra determinística, campo estruturado ou valor numérico continua no if comum, que segue sendo rápido e previsível 🙂

Até o próximo post!