Existe uma tentação muito comum em projetos de inteligência artificial: jogar tudo para um LLM.
O usuário perguntou? Manda para o modelo.
Quer classificar intenção? Manda para o modelo.
Quer responder FAQ? Manda para o modelo.
Quer decidir o próximo passo? Manda para o modelo.
Quer consultar política interna? Manda para o modelo.
No começo, isso parece moderno. Na prática, pode ser desperdício de custo, risco de inconsistência e falta de arquitetura.
Nem toda pergunta precisa de um modelo generativo poderoso. Nem toda intenção precisa de raciocínio aberto. Nem toda resposta precisa ser criada do zero. Às vezes, o melhor desenho é mais simples: entender a intenção do usuário e rotear para o componente certo.
Foi por isso que a disponibilidade do Orchestration Workflow no Microsoft Foundry classic, em janeiro de 2026, me chamou atenção. A Microsoft registrou que o recurso passou a ser suportado no Foundry classic, com uma interface redesenhada para integrar projetos de Conversational Language Understanding, o CLU, e Custom Question Answering, o CQA. A ideia é permitir orquestrar utterances de usuários entre múltiplas aplicações conversacionais dentro de um workflow unificado, usando roteamento baseado em intenção para direcionar cada consulta ao projeto mais adequado. (learn.microsoft.com)
Esse é um tema menos barulhento do que “agentes autônomos”, “modelos multimodais” ou “Deep Research”. Mas, em produção, ele é extremamente importante.
Porque arquitetura conversacional madura não é aquela que usa o modelo mais poderoso em tudo. É aquela que sabe escolher o caminho certo para cada pergunta.
O erro de usar LLM como roteador universal
Um LLM consegue fazer muita coisa. Esse é justamente o problema.
Quando uma tecnologia consegue responder, classificar, resumir, explicar, traduzir e raciocinar, é fácil cair no vício de usar o mesmo modelo para tudo. Mas só porque ele consegue fazer, não significa que ele seja a melhor opção para cada tarefa.
Se o usuário pergunta “qual é o horário de funcionamento?”, talvez a melhor resposta esteja em uma base de FAQ.
Se o usuário pergunta “quero trocar meu endereço”, talvez seja uma intenção transacional.
Se ele pergunta “me explique a diferença entre dois produtos”, talvez um LLM ajude.
Se ele pergunta “qual é a política oficial de reembolso?”, talvez você precise de resposta controlada e fonte confiável.
Colocar tudo no mesmo fluxo generativo é simples, mas não necessariamente correto.
O que o Orchestration Workflow reforça é uma ideia clássica de arquitetura: antes de responder, entenda para onde a pergunta deve ir.
O que é Orchestration Workflow
Orchestration Workflow é uma capacidade do Azure AI Language em Foundry Tools que permite criar modelos de orquestração para integrar projetos de CLU e Custom Question Answering. A documentação descreve que o serviço facilita a criação de modelos que conectam CLU e CQA, permitindo que desenvolvedores etiquetem utterances, treinem modelos, avaliem performance e façam deploy. (learn.microsoft.com)
Em português direto: ele ajuda a decidir qual componente deve responder a uma determinada mensagem do usuário.
Um projeto de CLU pode identificar intenção.
Um projeto de CQA pode responder perguntas frequentes com maior controle.
O workflow de orquestração conecta essas partes.
O resultado é uma aplicação conversacional mais organizada.
Isso não substitui LLM. Também não compete com agentes. Ele resolve uma camada anterior: roteamento.
E roteamento bom reduz bagunça.
CLU e CQA: papéis diferentes
Para entender o valor do Orchestration Workflow, é preciso separar bem os papéis.
CLU, ou Conversational Language Understanding, é útil para entender intenção e extrair entidades em conversas. Ele ajuda a identificar o que o usuário quer. A pergunta pode ser “quero cancelar meu pedido”, “preciso alterar meu cadastro” ou “qual produto combina comigo?”. O CLU tenta classificar essa intenção.
CQA, ou Custom Question Answering, é útil quando você tem perguntas e respostas mais controladas, baseadas em conhecimento aprovado. Em vez de gerar uma resposta livre, ele busca uma resposta adequada em uma base preparada.
O Orchestration Workflow entra como uma camada que decide: esta mensagem deve ir para qual projeto? Para qual domínio? Para qual fluxo?
A própria atualização de janeiro de 2026 fala em integração entre CLU e CQA e roteamento baseado em intenção para direcionar consultas ao projeto correto, melhorando precisão e reduzindo complexidade de desenvolvimento. (learn.microsoft.com)
Esse ponto é importante: em muitos casos, você melhora a solução não colocando mais IA generativa, mas colocando mais estrutura.
O que muda com isso dentro do Microsoft Foundry
O fato de essas capacidades estarem dentro do Microsoft Foundry é relevante porque o Foundry está se consolidando como o lugar onde a Microsoft organiza modelos, agentes, ferramentas e workloads de IA.
Em janeiro de 2026, a Microsoft também registrou que as capacidades de Azure AI Language estavam totalmente disponíveis no Foundry classic, incluindo autoria, testes, gerenciamento de projetos, treinamento e deploy integrados na plataforma. (learn.microsoft.com)
Isso aponta para uma direção clara: tirar workloads de linguagem de experiências fragmentadas e aproximá-los da plataforma Foundry.
Para quem constrói aplicações de IA, isso facilita uma visão mais integrada. Você pode ter agentes, modelos generativos, ferramentas de linguagem, roteamento de intenção, respostas controladas e fluxos de avaliação dentro de uma mesma estratégia de plataforma.
Mas, de novo, a ferramenta não resolve sozinha a arquitetura. Ela apenas permite um desenho melhor.
Quando usar Orchestration Workflow
Eu usaria Orchestration Workflow quando a aplicação tem múltiplos tipos de intenção e nem todas deveriam ser tratadas pelo mesmo componente.
Por exemplo:
Atendimento interno com dúvidas de RH, TI e financeiro.
Assistente de loja com perguntas sobre produto, troca, garantia e promoção.
Portal de suporte com FAQ, abertura de chamado e consulta de status.
Bot corporativo que roteia solicitações para áreas diferentes.
Aplicação educacional que separa dúvida conceitual, exercício e suporte técnico.
Assistente de cliente que precisa distinguir pergunta simples de solicitação transacional.
Nesses casos, jogar tudo em um LLM pode até funcionar, mas o custo e a imprevisibilidade aumentam. O roteamento cria um desenho mais claro.
O usuário perguntou algo que está na base de FAQ? Vai para CQA.
O usuário expressou uma intenção transacional? Vai para o fluxo correto.
O usuário trouxe uma pergunta aberta e complexa? Aí talvez um LLM ou agente faça sentido.
Essa separação é arquitetura.
Quando não usar
Eu não usaria Orchestration Workflow para qualquer conversa simples. Se sua aplicação só tem um domínio, poucas perguntas e não precisa de múltiplos destinos, talvez seja excesso.
Também não usaria como substituto de um agente quando o problema exige raciocínio multi-step, uso de ferramentas, planejamento, pesquisa, execução e memória operacional.
Orchestration Workflow é excelente para rotear intenções entre aplicações conversacionais. Mas ele não é uma solução universal para todo tipo de IA.
Esse é um ponto recorrente em arquitetura: tecnologia boa usada no problema errado vira complexidade desnecessária.
Um exemplo prático: assistente interno de uma empresa
Imagine uma empresa criando um assistente interno para colaboradores.
Esse assistente recebe perguntas como:
“Como faço para pedir férias?”
“Meu notebook está lento.”
“Qual é a política de reembolso?”
“Preciso abrir um chamado de acesso.”
“Como funciona o benefício de alimentação?”
“Quero atualizar meus dados cadastrais.”
“Explique a diferença entre os planos de saúde.”
“Meu Teams não está funcionando.”
Se tudo for para um LLM, ele pode tentar responder qualquer coisa. Mas a aplicação pode ficar inconsistente. Algumas perguntas exigem resposta oficial. Outras exigem abertura de chamado. Outras exigem encaminhamento para RH. Outras exigem diagnóstico técnico.
Um desenho melhor seria:
Entrada do usuário
↓
Orchestration Workflow
↓
Intenção RH → CLU RH ou CQA RH
Intenção TI → CLU TI ou fluxo de suporte
Intenção Financeiro → CQA Financeiro
Intenção aberta ou complexa → Agente/LLM com fonte controlada
Intenção sensível → Escalonamento humanoEsse fluxo reduz o risco de uma IA generativa tentar resolver tudo sozinha.
Como eu desenharia a primeira versão
Eu começaria simples.
Primeiro, listaria os domínios principais:
RH
TI
Financeiro
Comercial
Jurídico
Suporte GeralDepois, listaria intenções dentro de cada domínio:
RH:
- consultar política de férias
- entender benefícios
- atualizar dados cadastrais
- solicitar documento
TI:
- abrir chamado
- reportar problema de acesso
- solicitar equipamento
- consultar guia de configuração
Financeiro:
- política de reembolso
- prazo de pagamento
- solicitação de nota fiscalDepois, decidiria qual tecnologia responde melhor cada intenção.
Nem tudo vai para LLM.
Perguntas frequentes oficiais → CQA
Classificação de intenção → CLU
Solicitação transacional → workflow/aplicação interna
Dúvida aberta → LLM com grounding
Tema sensível → humanoEssa tabela é a base da arquitetura.
Tutorial conceitual: matriz de roteamento
Antes de criar qualquer projeto no Foundry, eu montaria uma matriz de roteamento.
User utterance:
"Como faço para pedir reembolso?"
Detected domain:
Financeiro
Detected intent:
Consultar política de reembolso
Destination:
Custom Question Answering - Financeiro
Response type:
Resposta oficial com link para política interna
Human escalation:
Não, exceto se houver caso excepcionalOutro exemplo:
User utterance:
"Meu acesso ao sistema de vendas foi bloqueado."
Detected domain:
TI
Detected intent:
Problema de acesso
Destination:
Fluxo de abertura de chamado
Response type:
Coletar dados mínimos e abrir solicitação
Human escalation:
Sim, se envolver usuário privilegiado ou sistema críticoMais um:
User utterance:
"Qual plano de saúde é melhor para mim?"
Detected domain:
RH
Detected intent:
Comparar benefícios
Destination:
LLM com fontes oficiais + aviso de validação humana
Response type:
Explicação comparativa baseada nas políticas aprovadas
Human escalation:
Sim, se houver recomendação individual sensívelPerceba que o roteamento não decide apenas tecnologia. Ele decide risco, formato de resposta e necessidade de escalação.
O papel do LLM nesse desenho
O LLM continua importante. Só deixa de ser usado como martelo para tudo.
Eu usaria LLM em três cenários principais.
Primeiro, quando a pergunta exige explicação, síntese ou comparação.
Segundo, quando o usuário traz linguagem muito aberta e o fluxo determinístico não resolve.
Terceiro, quando o agente precisa usar ferramentas, contexto e raciocínio em múltiplas etapas.
Mas eu não usaria LLM para respostas oficiais simples se CQA resolve melhor.
Não usaria LLM para classificação de intenção se CLU está treinado para isso.
Não usaria LLM para decisão sensível sem revisão.
Não usaria LLM para inventar resposta onde deveria haver política aprovada.
Essa é a maturidade: usar LLM onde ele realmente agrega.
Por que isso reduz custo
Uma aplicação que envia tudo para modelo generativo tende a gastar mais do que precisa.
Se uma parte relevante das perguntas pode ser roteada para CQA ou fluxos determinísticos, você reduz chamadas desnecessárias ao modelo. Além disso, melhora previsibilidade.
Custo em IA não é só token. É também custo de erro, retrabalho, revisão e suporte.
Uma resposta errada sobre uma política interna pode gerar chamado.
Uma intenção mal classificada pode mandar usuário para fluxo errado.
Uma resposta generativa onde deveria haver resposta oficial pode causar ruído.
Roteamento bom reduz custo direto e indireto.
Por que isso melhora precisão
A própria atualização de janeiro da Microsoft fala que o roteamento baseado em intenção direciona consultas ao projeto CLU ou CQA apropriado, melhorando a precisão da resposta e reduzindo complexidade de desenvolvimento. (learn.microsoft.com)
Isso faz sentido.
Quando cada domínio tem seu próprio projeto, sua própria base e seu próprio escopo, a resposta tende a ficar mais controlada.
Em vez de um sistema genérico tentando entender tudo, você cria especialização.
Mas cuidado: especialização demais também pode gerar complexidade. O segredo é começar com poucos domínios e crescer conforme o volume real de perguntas justificar.
Como treinar com dados reais
Um erro comum em CLU é treinar intenções com frases artificiais demais.
O time escreve exemplos perfeitos:
“Gostaria de consultar minha política de férias.”
“Desejo solicitar alteração cadastral.”
“Preciso de informações sobre reembolso.”
Só que o usuário real escreve assim:
“como vejo minhas férias?”
“quero mudar meu endereço”
“onde mando recibo?”
“meu acesso caiu”
“não consigo entrar no sistema”
“quem resolve notebook travando?”
O modelo precisa aprender a linguagem real.
Eu começaria coletando exemplos reais de chamados, e-mails, chats internos e perguntas frequentes. Depois limparia dados sensíveis, agruparia por intenção e criaria um conjunto de treinamento mais representativo.
Não adianta treinar IA conversacional com linguagem que ninguém usa.
Como evitar excesso de intenções
Outro erro comum é criar intenção demais.
No começo, o time tenta mapear tudo:
consultar férias;
consultar férias vencidas;
consultar férias futuras;
alterar férias;
cancelar férias;
pedir férias;
ver saldo de férias.
Talvez tudo isso possa começar como uma intenção maior chamada “férias”, com entidades ou perguntas complementares para refinar.
Intenções demais geram confusão. Intenções parecidas demais geram erro de classificação.
Eu prefiro começar com menos intenções e expandir conforme os dados reais mostram necessidade.
Arquitetura boa começa simples e cresce com evidência.
O papel do Exact Question Answering
Em janeiro de 2026, a Microsoft também registrou o Azure Language Exact Question Answering agent, voltado a entregar respostas consistentes para perguntas frequentes de negócio. Além disso, citou novos templates como Intent routing e Exact question answering, úteis para roteamento determinístico de intenção e respostas precisas com supervisão humana. (learn.microsoft.com)
Esse ponto é muito relevante.
Nem toda resposta deve ser criativa. Algumas respostas precisam ser consistentes.
Se a pergunta é sobre política, prazo, processo, regra interna ou documentação oficial, consistência é mais importante que criatividade.
Nesse caso, Exact Question Answering faz muito sentido. Ele pode entregar respostas previsíveis para perguntas de alto valor, especialmente quando o negócio não quer variação generativa.
É o tipo de recurso que parece menos impressionante, mas resolve problema real.
Um exemplo no varejo
Vamos trazer para um cenário de varejo.
Imagine um assistente para vendedores em lojas físicas. Ele recebe perguntas como:
“Qual celular tem melhor bateria?”
“Como funciona a garantia?”
“Tem troca em sete dias?”
“Qual promoção está valendo hoje?”
“O cliente quer parcelar, qual condição?”
“Esse produto é compatível com tal acessório?”
“Como argumento contra concorrente?”
Nem tudo deveria ser tratado igual.
Garantia e troca precisam de resposta oficial.
Promoção precisa de fonte atualizada.
Condição comercial precisa de regra.
Comparação de produto pode usar LLM com base controlada.
Argumentação de venda pode usar modelo generativo, mas com limites.
Um bom roteamento poderia separar:
Política de garantia → CQA oficial
Promoção vigente → fonte comercial atualizada
Comparação de produto → LLM com catálogo
Objeção de venda → agente de apoio comercial
Condição sensível → escalonamento para gestorEsse desenho evita que a IA prometa algo que a operação não pode cumprir.
O que medir
Depois de colocar um fluxo desses no ar, eu mediria:
Taxa de classificação correta.
Taxa de fallback.
Perguntas sem resposta.
Intenções confundidas.
Tempo médio de resposta.
Custo por tipo de consulta.
Taxa de escalonamento humano.
Satisfação do usuário.
Correções manuais feitas pelo time.
Sem métrica, a aplicação parece funcionar até alguém provar o contrário.
O mais importante é olhar para as perguntas que caíram no fallback. Elas mostram onde a arquitetura precisa evoluir.
Como lidar com fallback
Fallback é inevitável.
O usuário vai perguntar algo fora do escopo. Vai escrever errado. Vai misturar assuntos. Vai pedir algo sensível. Vai tentar forçar uma resposta.
O fallback não deve ser uma frase genérica tipo “não entendi”. Ele deve ser uma parte pensada da experiência.
Um bom fallback pode:
pedir esclarecimento;
oferecer opções;
redirecionar para humano;
abrir chamado;
registrar nova intenção candidata;
sugerir perguntas suportadas.
Fallback é fonte de aprendizado. Se muita pergunta cai no fallback, seu modelo de intenções está incompleto ou mal treinado.
Como isso se conecta com agentes
Orchestration Workflow não substitui agentes. Ele pode ser uma camada antes deles.
Um desenho interessante seria:
Perguntas simples vão para CQA.
Intenções transacionais vão para workflows.
Perguntas ambíguas passam por CLU.
Demandas complexas vão para agente.
Demandas sensíveis vão para humano.
Isso evita que o agente receba tudo. O agente passa a tratar o que realmente exige raciocínio, ferramentas ou múltiplas etapas.
Essa é uma arquitetura mais eficiente.
Em vez de construir um agente gigante que tenta resolver tudo, você cria uma malha de decisão em que cada componente faz o que faz melhor.
O erro de pensar que determinístico é ultrapassado
Existe um preconceito estranho no mercado: se não usa LLM para tudo, parece antigo.
Eu discordo completamente.
Sistemas determinísticos continuam sendo essenciais. Respostas controladas continuam sendo essenciais. Regras de negócio continuam sendo essenciais. Roteamento de intenção continua sendo essencial.
A IA generativa não elimina engenharia tradicional. Ela adiciona uma nova camada.
A maturidade está em combinar o determinístico com o probabilístico.
Quando preciso de criatividade, síntese ou raciocínio aberto, uso modelo generativo.
Quando preciso de controle, consistência e regra clara, uso componentes mais determinísticos.
Quando preciso decidir caminho, uso roteamento.
Quando preciso executar, uso workflow.
Quando há risco, coloco humano no processo.
Isso é arquitetura híbrida.
O que eu faria em produção
Antes de colocar Orchestration Workflow em produção, eu faria:
Mapa de domínios.
Mapa de intenções.
Bases de CQA aprovadas.
Exemplos reais de utterances.
Critérios de fallback.
Política de escalonamento.
Medição de acurácia.
Teste com usuários reais.
Revisão de respostas oficiais.
Monitoramento contínuo.
E principalmente: começaria pequeno.
Não tentaria mapear toda a empresa na primeira versão. Escolheria dois ou três domínios com alto volume de perguntas e baixo risco inicial.
Por exemplo:
RH básico.
TI básico.
FAQ comercial.
Depois expandiria com base nos dados reais.
Minha leitura sobre janeiro de 2026
Janeiro de 2026 foi importante porque reforçou um movimento de consolidação do Azure AI Language dentro do Microsoft Foundry.
A disponibilidade do Orchestration Workflow no Foundry classic, a integração entre CLU e CQA, os templates de intent routing e exact question answering, e a disponibilidade completa das capacidades de Azure AI Language no Foundry mostram uma direção clara: a Microsoft está trazendo workloads clássicos de linguagem para dentro da estratégia Foundry. (learn.microsoft.com)
Para mim, isso é relevante porque nem toda aplicação de IA precisa começar em agente ou LLM. Muitas precisam começar em linguagem, intenção e roteamento.
Essa camada é menos glamourosa, mas extremamente útil.
Conclusão
Orchestration Workflow no Microsoft Foundry é um lembrete importante: arquitetura de IA não é usar o modelo mais poderoso em tudo.
Às vezes, a melhor decisão é entender a intenção e mandar a pergunta para o lugar certo.
CLU ajuda a entender o que o usuário quer.
CQA ajuda a responder perguntas controladas.
Orchestration Workflow ajuda a conectar esses mundos.
LLMs e agentes entram quando o problema exige raciocínio, síntese, ferramentas ou fluxos mais complexos.
Essa combinação é mais madura do que jogar tudo para um modelo generativo e esperar que ele resolva.
No fim, uma boa aplicação conversacional não é aquela que responde qualquer coisa de qualquer jeito. É aquela que entende o caminho certo para cada pergunta.
E esse é o valor do Orchestration Workflow: transformar conversa em roteamento inteligente, com mais controle, mais precisão e menos improviso.
Porque, em produção, a pergunta não é só “qual resposta a IA vai dar?”. A pergunta é: “qual componente deveria responder isso?”
Essa diferença separa uma demo de uma arquitetura.
Referências técnicas usadas como base: documentação oficial da Microsoft sobre novidades do Azure AI Language em Foundry Tools em janeiro de 2026, incluindo Orchestration Workflow no Microsoft Foundry classic, integração entre CLU e CQA, Azure AI Language totalmente disponível no Foundry classic, Exact Question Answering agent e templates de intent routing.
Seja o primeiro a comentar