Orquestração e raciocínio: os 7 padrões que controlam o fluxo de um agente

No post anterior, vimos os 4 grupos de padrões de IA agêntica. Agora entramos no primeiro deles: como um agente decide o que fazer, em que ordem e com quem dividir o trabalho. São 7 padrões. Cada um resolve um problema específico de controle de fluxo. Juntos, formam a base sobre a qual todos os outros grupos (memória, resiliência, produção) se apoiam.

Prompt chaining (encadeamento de prompts): dividir para conquistar

Se a IA tentar resolver tudo em uma tacada só, com um prompt único e complexo,  sobrecarregaria o modelo. Por exemplo, imagine o seguinte comando: “Analise este relatório, resuma os achados, identifique tendências com base nos dados e redija um e-mail com essas informações para a alta gestão”. Fatalmente o modelo falharia. Ele resumiria bem, mas erraria a extração de dados ou esqueceria parte do comando.

O encadeamento de prompts quebra isso em etapas sequenciais, onde a saída de uma vira entrada da próxima:

• Analise o relatório
  • Com base na análise, resuma o que for relevante
    • Com base no resumo, identifique tendências
      • Com base no resumo e na tendência, redija o email.

Cada etapa fica mais restrita e mais fácil de acertar. A confiabilidade da cadeia depende de um detalhe técnico: a especificação do formato de saída estruturado (JSON, por exemplo) entre as etapas, pois uma saída ambígua numa etapa quebra a entrada da próxima. Se você utiliza uma ferramenta de IA generativa como ChatGPT, Gemini ou Claude, isso é transparente. Entretanto, se você utiliza ferramentas como n8n, Make ou Dify, isso torna-se extremamente importante. Na verdade, é essencial. A pior coisa é você ter que ficar adicionando um monte de nós de conversão de formato porque uma IA responde em texto, outra em JSON, outra em CSV…

Routing (Roteamento): decisão condicional no fluxo

Prompt chaining é linear e determinístico. Nem todo problema é assim. Imagine um robô atendendo um cliente no Serviço de Atendimento ao Cliente (SAC) da empresa. Ele precisa decidir se a pergunta é sobre o status do pedido, informações do produto ou suporte técnico, e cada caminho leva a uma ferramenta ou a um subagente diferente.

O roteamento resolve isso por meio de lógica condicional: o próprio modelo classifica a intenção da entrada e a arquitetura direciona o fluxo de acordo. Existem algumas formas de implementar roteamento.

Routing via LLM

Se você não sabe o que é LLM, dê uma olhadinha nesse texto: “Tokens, RAG, LLM, SLM, VLM, LRM, COT… A sopa de letrinhas sobre inteligência artificial”. Nesse tipo de roteamento, o próprio modelo recebe a entrada, processa e tenta categorizar qual rota a IA deve seguir, e devolve apenas uma categoria, por exemplo: “Status de Pedido”, “Informação de Produto” ou “Suporte Técnico”. O sistema lê essa saída e direciona o fluxo de acordo. É o mais flexível para lidar com entradas ambíguas, mas depende de uma chamada ao modelo em tempo real, o que custa tempo, tokens e dinheiro a cada decisão.

Embedding Routing (roteamento embutido)

A entrada vira um vetor numérico (embedding), que é comparado, por similaridade semântica, com vetores que representam cada rota possível. A entrada vai pra rota mais parecida. É bom pra roteamento semântico: pega o significado da frase, não só palavras-chave exatas. É o mesmo princípio de comparação vetorial usado no RAG.

Roteamento baseado em regras

O bom, velho e conhecido if-else (se-então), baseado em palavras-chave ou em padrões extraídos da entrada. Mais rápido e determinístico do que os dois anteriores, mas menos flexível: não lida bem com entradas novas ou nuances que a regra não previu.

Roteamento via modelo de machine learning.

Um classificador treinado especificamente para essa tarefa de roteamento, com um conjunto de dados rotulados. A diferença-chave em relação ao routing via LLM: aqui a decisão não vem de um modelo generativo rodando um prompt na hora. A lógica já está codificada nos pesos do modelo treinado. LLMs podem até ajudar a gerar dados sintéticos para treinar esse classificador, mas não participam da decisão em tempo real.

Parallelization (Paralelismo): o que não depende de nada, roda junto

Se partes de uma tarefa não dependem umas das outras do resultado, rodá-las em sequência é desperdício de tempo. Um agente de pesquisa que busca em três fontes diferentes não precisa esperar a fonte A terminar para começar a fonte B.

O paralelismo identifica essas partes independentes e as executa concorrentemente, reduzindo significativamente o tempo total quando há chamadas a APIs ou a bancos de dados com latência. Frameworks como LangGraph e Google ADK dão suporte nativo a isso: você define os nós ou agentes que podem rodar em paralelo, e a orquestração cuida da sincronização quando os resultados precisam ser combinados novamente.

Um exemplo prático seria um agente de planejamento de viagens. Ele pode fazer em paralelo: 

• consultar preço de passagem aérea,
• Consultar a disponibilidade de hotel,
• Listar e classificar eventos locais e recomendações de restaurante 

Depois que a IA tiver todas essas informações, ela chama o orquestrador para montar o roteiro completo bem mais rápido.

Reflection (Reflexão): o agente que revisa o próprio trabalho

A saída da primeira tentativa nem sempre é a melhor. A reflexão introduz um loop de autoavaliação. 

1. o agente produz algo
2. Examina o resultado (ou processo) contra critérios de qualidade
3. Usa essa crítica para gerar uma versão melhor.

A implementação mais robusta separa isso em dois papéis: um agente Produtor, que gera o conteúdo, e um agente Crítico, com persona e instruções diferentes, cujo único trabalho é encontrar falhas no que o Produtor entregou. Essa separação evita o viés de um agente avaliar o próprio trabalho com os mesmos pressupostos que utilizou para criá-lo. O feedback do Crítico volta pro Produtor, que gera uma nova versão. É o mesmo modelo Generator-Critic que aparece no código, na escrita e na verificação de fatos.

Exemplo prático: um agente que escreve código-fonte gera um método, executa testes ou análises estáticas, identifica erros ou ineficiências e reescreve com base no que encontra.

Tool use: sair da caixa do modelo

Faça uma pergunta simples à sua ferramenta de IA: “Qual é a temperatura hoje no Rio de Janeiro?”. Não há como o modelo dela ter sido treinado com dados sobre a temperatura atual de uma cidade. Aí teríamos um problema: como dar uma resposta se o módulo da ferramenta nunca treinou com os dados para te dar uma resposta. O Tool use (uso de ferramentas), às vezes chamado de function calling (chamada de funções), permite ao agente consultar uma API de clima, uma base de dados ou executar código sempre que a tarefa exige informação ou ação que o modelo não tem de cabeça.

O fluxo típico: o modelo recebe a descrição das ferramentas disponíveis, decide se precisa de alguma pra responder, gera uma chamada estruturada com os parâmetros extraídos do pedido do usuário, a camada de orquestração executa essa chamada de verdade e o resultado volta para o modelo, que formula a resposta final. Vale notar que “tool” aqui é um conceito amplo: pode ser uma função tradicional, um endpoint de API ou até uma instrução direcionada a outro agente especializado.

Exemplo prático: um agente de assistência pessoal recebe “manda um e-mail pro João Jesus Jardim sobre a reunião de amanhã”. O agente olha a sua agenda no Google Agenda para ver a reunião , acessa o seu Google Contatos para encontrar o endereço de e-mail do JJJ e vai até o  MailSend para disparar o e-mail.

Planning (Planejamento): quando o “como” precisa ser descoberto

Alguns problemas têm um caminho conhecido de antemão. Outros não. Planning entra quando o agente recebe um objetivo de alto nível e precisa descobrir sozinho a sequência de passos pra chegar lá, ajustando o plano se as condições mudarem no meio do caminho. Isso é muito comum em ferramentas de Vibe Coding.

A decisão entre usar um agente de planejamento ou um agente de execução simples se resume a uma pergunta: o “como” já é conhecido ou precisa ser descoberto em tempo real? Onboarding de funcionário, navegação de robô e geração de relatório complexo em fases são exemplos em que o planejamento dinâmico compensa o custo extra de arquitetura. O exemplo mais comum é quando você fala para a ferramenta: “Crie um cadastro dos meus clientes”. É uma baita tarefa que ele deverá pensar antes de executar:

• Qual a estrutura de banco de dados
• Como será a interface com o cliente
• Quais as regras de preenchimento
• Como os dados irão da tela para o banco de dados
• …

Multi-agent collaboration (Colaboração multiagente): especialização em vez de generalismo

Um agente monolítico enfrenta um limite quando a tarefa abrange domínios muito distintos. A colaboração multiagente decompõe o problema e distribui cada parte pro agente com a ferramenta ou o conhecimento certo: um agente de pesquisa, um de análise de dados, um de síntese, por exemplo.

A colaboração pode assumir formas diferentes: passagem de responsabilidade sequencial (um agente termina e passa pro próximo), processamento paralelo, debate até consenso, estrutura hierárquica com um agente gerente delegando pra agentes especialistas, ou o modelo crítico-revisor que vimos em Reflection, agora com grupos de agentes inteiros em cada papel. A parte crítica que faz esse padrão funcionar não é só dividir o trabalho: é o protocolo de comunicação entre os agentes, que precisa de uma estrutura compartilhada pra trocar dados e coordenar ações sem perder a coerência do resultado final.

Exemplo prático: no suporte ao cliente, um agente de primeira linha atende à demanda inicial e escala para um especialista de faturamento apenas quando a necessidade exige, em um handoff sequencial baseado na natureza do problema.

Como esses 7 padrões se combinam

Na prática, raramente um sistema usa apenas um desses padrões isoladamente. Um agente de atendimento pode usar routing para classificar a intenção, tool use para consultar o pedido no banco de dados, e reflection pra revisar a resposta antes de enviar. Já um agente de pesquisa pode usar planning pra montar a estratégia, parallelization pra buscar em várias fontes ao mesmo tempo e multi-agent collaboration pra dividir a pesquisa e a síntese entre agentes diferentes.

O próximo grupo da série será sobre o estado e o aprendizado. É sobre o que acontece quando esses fluxos precisam se lembrar do que já ocorreu.

Pronto pra dar o próximo passo?

Entender como orquestrar esses padrões é a diferença entre um protótipo interessante e um sistema que aguenta produção. É exatamente esse tipo de decisão de arquitetura que o treinamento Product AI da K21 ajuda a estruturar.

• Product AI: para aprender a gerir a criação e evolução de produtos com a IA.
• Dominando o Claude
• Inteligência Artificial na Prática: criando um produto do zero a produção em menos de 3 dias.
• Design Thinking + IA