Olá Kleber,
Acrescentando um ponto especificamente pela perspectiva do Architect.
Em implementações maiores de WhatsApp, normalmente prefiro manter o Inbound Message Flow como a camada de orquestração. Ou seja, o Message Flow fica responsável pela jornada de negócio mais ampla - regras de entrada, decisões de roteamento, contexto, tratamento de erros e definição de qual Digital Bot Flow deve ser executado - enquanto cada Digital Bot Flow fica focado em uma capacidade conversacional ou domínio de negócio mais específico.
Essa abordagem ajuda bastante a manter a arquitetura modular e evita a construção de um único bot muito grande, concentrando muitos intents, regras e responsabilidades.
Outro ponto importante são os limites e comportamentos dos Digital Bot Flows. Os bots possuem limites de execução relacionados, por exemplo, à quantidade de actions e turnos da conversa. Além disso, quando utilizamos múltiplos bots, cada um mantém suas próprias configurações e limites. NLU e Knowledge também pertencem ao escopo de cada bot e não são compartilhados automaticamente.
Temos também uma mudança recente bastante interessante: desde a release de 6 de julho de 2026, o Genesys Cloud passou a permitir oficialmente que um Digital Bot Flow chame outro Digital Bot Flow.
É uma funcionalidade muito útil e que abre novas possibilidades para arquiteturas modulares de bots. Porém, particularmente, eu utilizaria esse recurso com bastante cuidado.
Antes de adotar Digital Bot Flows encadeados de forma mais ampla, recomendo testar muito bem toda a cadeia da conversa e ficar atento às dependências entre os flows, variáveis de entrada e saída, escopo de NLU e Knowledge, tratamento de erros, monitoração e limites da plataforma.
É fácil começarmos com algo como:
Inbound Message Flow → Digital Bot A → Digital Bot B → Digital Bot C
Mas, conforme essa hierarquia cresce, o troubleshooting e o entendimento completo da jornada do cliente também podem ficar consideravelmente mais complexos.
Por isso, mesmo com a nova possibilidade de bot chamar bot, em muitos cenários minha preferência continua sendo:
Inbound Message Flow como orquestrador → Digital Bot Flows especializados.
Eu utilizaria chamadas diretas entre Digital Bot Flows quando existir um benefício arquitetural claro, e não simplesmente porque agora a plataforma permite fazer isso.
__________________________________________________________________________________________________________________________________________________________________
Hi Kleber,
Adding one point specifically from the Architect perspective.
For larger WhatsApp implementations, I usually prefer to keep the Inbound Message Flow as the orchestration layer. In other words, the Message Flow owns the broader business journey - entry rules, routing decisions, context, error handling and which Digital Bot Flow should be executed - while each Digital Bot Flow focuses on a more specific conversational capability or business domain.
This approach has worked well for keeping the architecture modular and also helps avoid building one very large bot with too many intents, rules and responsibilities.
Another important consideration is the platform limits and behavior of Digital Bot Flows. For example, bots have runtime limits around actions and conversation turns, and when multiple bots are involved each bot maintains its own configuration and limits. NLU and Knowledge are also scoped to each bot and are not automatically shared.
There is also an interesting recent change here: since the July 6, 2026 release, Genesys Cloud officially allows a Digital Bot Flow to call another Digital Bot Flow.
This is a very useful capability and opens new possibilities for modular bot architectures. However, personally, I would use it carefully.
Before adopting nested Digital Bot Flows extensively, I would strongly recommend testing the complete conversation chain and paying close attention to flow dependencies, input/output variables, NLU and Knowledge scope, error handling, monitoring and platform limits.
It can be tempting to create something like:
Inbound Message Flow → Digital Bot A → Digital Bot B → Digital Bot C
But as the hierarchy grows, troubleshooting and understanding the complete customer journey can become significantly more complex.
For that reason, even with the new bot-to-bot capability, my preference in many scenarios is still:
Inbound Message Flow as the orchestrator → specialized Digital Bot Flows.
I would use direct Digital Bot Flow-to-Digital Bot Flow calls when there is a clear architectural benefit rather than simply because the platform now allows it.
------------------------------
Matheus Mendonca
------------------------------