Olá, pessoal!
Gostaria de ouvir a experiência de quem já está utilizando a capacidade recente que permite que um Digital Bot Flow chame outro Digital Bot Flow.
Consigo enxergar alguns benefícios, principalmente em relação à modularização e separação de responsabilidades. Por exemplo, em vez de termos um bot muito grande, podemos criar bots mais especializados, responsáveis por domínios ou partes específicas da jornada do cliente.
Porém, olhando pela perspectiva de arquitetura e desenvolvimento, neste momento alguns desafios estão me chamando mais atenção do que os benefícios.
O primeiro é a rastreabilidade.
Quando começamos a ter uma jornada como:
Inbound Message Flow
→ Digital Bot A
→ Digital Bot B
→ Digital Bot C
→ Digital Bot D
o troubleshooting pode ficar consideravelmente mais complexo. Entender onde uma variável foi alterada, onde uma intenção foi identificada, qual versão de determinado bot foi executada ou exatamente em qual ponto o cliente seguiu um caminho inesperado pode exigir navegar por diversos flows.
Minha segunda preocupação é a profundidade da jornada e a complexidade arquitetural.
Tecnicamente, permitir que um bot chame outro é bastante útil. Mas até qual profundidade devemos permitir que essa hierarquia cresça?
Em algum momento, modularização pode acabar se transformando em fragmentação.
Por exemplo:
Digital Bot A
→ Bot B
→ Bot C
→ Bot D
→ Bot E...
Mesmo que cada bot individualmente esteja bem construído, a jornada completa pode começar a ficar difícil de compreender, testar, documentar, investigar e manter.
Isso também me trouxe algumas perguntas de arquitetura:
-
Vocês estão definindo uma profundidade máxima interna para chamadas entre bots?
-
Como estão documentando as dependências entre os Digital Bot Flows?
-
Como estão tratando versionamento quando um bot depende de vários outros?
-
Como estão rastreando a jornada completa de um cliente através de múltiplos bots?
-
Estão utilizando essa funcionalidade principalmente para componentes reutilizáveis ou para construir jornadas completas compostas por vários bots?
-
Como estão tratando uma alteração em um subflow que pode impactar vários bots que dependem dele?
Particularmente, acho a capacidade poderosa, mas também vejo o risco de ambientes complexos se tornarem mais difíceis de manter caso não existam bons padrões de arquitetura e governança.
Por isso, fiquei curioso:
Quais benefícios reais vocês já encontraram utilizando a orquestração entre Digital Bot Flows?
E, principalmente:
Quais práticas ou limites arquiteturais estão adotando para evitar que a modularização se transforme em complexidade excessiva?
Gostaria muito de conhecer exemplos de outras implementações.
_______________________________________________________________________________________________________________________________________________________________________
Hi everyone,
I would like to hear how others are using the recent capability that allows a Digital Bot Flow to call another Digital Bot Flow.
I can definitely see some potential benefits, especially around modularization and separation of responsibilities. For example, instead of building one very large bot, we could have more specialized bots responsible for specific domains or parts of the customer journey.
However, from an architecture and development perspective, I currently see some challenges that concern me more than the benefits.
The first one is traceability.
When a journey becomes something like:
Inbound Message Flow
→ Digital Bot A
→ Digital Bot B
→ Digital Bot C
→ Digital Bot D
troubleshooting can become significantly more complex. Understanding where a variable changed, where an intent was detected, which version of a bot was executed, or exactly where the customer took an unexpected path may require navigating through several flows.
My second concern is journey depth and architectural complexity.
Technically, being able to call another bot is useful, but how deep should we allow these hierarchies to become?
At some point, modularization can turn into fragmentation.
For example:
Digital Bot A
→ Bot B
→ Bot C
→ Bot D
→ Bot E...
Even if each bot is individually well designed, the overall customer journey can become difficult to understand, test, document, troubleshoot, and maintain.
It also raises some architecture questions for me:
-
Do you define an internal maximum depth for bot-to-bot orchestration?
-
How are you documenting dependencies between bots?
-
How do you handle versioning when one bot depends on several other bots?
-
How are you tracing a customer journey across multiple Digital Bot Flows?
-
Are you using bot-to-bot calls mainly for reusable capabilities, or are you using them to build complete multi-bot journeys?
-
What happens when a subflow changes independently and affects multiple parent bots?
Personally, I think this capability is powerful, but I also feel that without strong architecture and governance standards it could make complex environments harder to maintain.
So I am curious:
What real benefits have you found so far with Digital Bot Flow orchestration?
And more importantly:
What architectural practices or limits are you putting in place to prevent modularization from becoming excessive complexity?
I would really like to hear examples from other implementations.
#Architect#WebMessaging------------------------------
Matheus Mendonca
------------------------------