Genesys Cloud - Developer Community!

Hello everyone,

I'm currently studying the Genesys Agentic Virtual Agent / AVA capabilities and would like to better understand how teams are using it in real customer experience scenarios.

For those who have already implemented or tested AVA:

What are the main use cases where AVA brought value compared to a traditional bot or Architect flow?

I'm especially interested in understanding:

• How AVA is being used in voice or digital channels
• How it handles customer intent recognition and context
• How it integrates with Architect, Data Actions or external APIs
• Best practices for bot-to-agent handoff
• Any limitations, challenges or lessons learned during implementation

If anyone has a real-world example, architecture approach or recommendation, I'd really appreciate it.

Thanks!

Oi Alex, que tema interessante! Posso compartilhar um pouco do que já estudei sobre o AVA.

A grande diferença em relação a um bot tradicional ou fluxo no Architect é que o AVA não segue um script rígido. Ele usa um modelo chamado APT-1, que foi treinado especificamente para tomar ações, não só gerar respostas. Isso faz com que ele consiga raciocinar sobre o contexto da conversa e decidir o próximo passo de forma mais autônoma, sem precisar de um fluxo desenhado para cada cenário.

Em termos de canais, ele funciona tanto em voz quanto em digital, como chat e mensageria. A configuração toda fica centralizada no AI Studio, onde você define o comportamento do agente, conecta ferramentas externas via Data Actions ou MCP servers, vincula bases de conhecimento e configura as regras de segurança e compliance.

Uma coisa que achei interessante é que as integrações reaproveitam as Data Actions que você já tem configuradas no Genesys, só adicionando uma camada de inteligência em cima. E como tudo é configurado em texto simples, sem código, o esforço de criação é bem menor comparado a fluxos tradicionais.

No handoff para o agente humano, o AVA passa todo o histórico da conversa, o que foi feito, o que foi consultado e até sugestões de próximos passos. Então o agente entra já contextualizado, sem precisar pedir para o cliente repetir tudo.

Um ponto de atenção que aprendi: existe uma diferença importante entre guidelines e guardrails dentro da configuração. Guidelines são orientações de comportamento, tom, empatia. Já os guardrails são bloqueios duros, usados só para segurança e compliance. Misturar os dois pode gerar comportamentos inesperados.

Espero que ajude, qualquer dúvida é só perguntar!

------------------------------
Lineu Romão
------------------------------

Obrigado por compartilhar Lineu! Vou me buscar ter mais conhecimento no assunto.

Hi @Alex Sander Felicio.🤓

------------------------------
Leonardo Vieira

Telecom Specialist
------------------------------

Hi everyone,

Great topic. I'm also studying AVA capabilities and, from what I've seen so far, the biggest value compared to a traditional bot or Architect flow is the flexibility to handle more natural, less linear conversations.

In traditional flows, we usually need to design many paths, intents, fallback scenarios and validations upfront. With AVA, the experience can become more conversational, especially when the customer does not follow the exact expected journey or provides multiple pieces of information in the same message.

Some use cases where I believe AVA can bring strong value are:

• Customer support journeys with many variations, where the intent is not always clear at the beginning

• Order status, billing, card, account or service requests that require context collection before calling APIs

• Digital channels where customers tend to write in a more open-ended way

• Voice journeys where AVA can help reduce rigid menu structures and create a more natural interaction

From an architecture perspective, I see AVA working very well when combined with Architect, Data Actions and external APIs. Architect can still orchestrate the main journey, routing logic and handoff rules, while AVA handles the conversational layer, intent understanding and information gathering.

For bot-to-agent handoff, I think some best practices are:

• Define clear escalation triggers

• Send the conversation context and collected information to the agent

• Avoid making the customer repeat what was already provided

• Use queues, skills or priority logic based on the identified intent

• Keep fallback paths simple and transparent

One important lesson is that AVA does not remove the need for good design. It still requires clear use cases, good knowledge/content structure, API readiness, testing, governance and continuous tuning.

I'd also be very interested in seeing more real-world examples, especially around voice, API orchestration and handoff design.

Hello everyone,

I'm currently studying the Genesys Agentic Virtual Agent / AVA capabilities and would like to better understand how teams are applying it in real customer experience scenarios.

From a technical perspective, I'm especially interested in understanding where AVA is bringing more value when compared to a traditional bot or a more deterministic Architect flow. For example, scenarios where the customer journey is less linear, where the intent is not always explicit, or where the virtual agent needs to interpret context, ask follow-up questions, retrieve information, and decide the next best step.

I'd be interested in hearing how AVA is being used across voice and digital channels, particularly in journeys such as service requests, troubleshooting, sales support, authentication, status inquiries, scheduling, or knowledge-based assistance.

I'm also trying to better understand how teams are designing the architecture around AVA. For example, how AVA is integrated with Architect flows, Data Actions, customer systems, CRMs, knowledge bases, or external APIs. Another point I'm looking into is how customer context is maintained during the conversation and how intent recognition behaves when the user changes topics or provides incomplete information.

One area that is very relevant to me is the bot-to-agent handoff. I'd like to understand best practices around when to transfer, what context should be passed to the agent, how summaries or conversation history are handled, and how to avoid poor handoff experiences where the customer needs to repeat information.

For those who have already implemented or tested AVA, I'd really appreciate any practical feedback around lessons learned, limitations, implementation challenges, governance, prompt/configuration strategy, API integration patterns, or recommendations for starting with a first use case.

Any real-world example, architecture approach, or implementation insight

Hi Alex,

From what I have seen, AVA brings the most value when the customer journey is not strictly linear. Traditional Architect flows are great for deterministic menus, validations and routing rules, but AVA is stronger when the customer can explain the problem in natural language and the bot needs to reason through context, retrieve information, and decide the next step.

Some good use cases are:

• Order/status tracking with follow-up questions
• Appointment scheduling or rescheduling
• Billing explanation and payment guidance
• Technical support triage
• Travel/booking changes
• FAQ + transactional flows, where the bot may need both knowledge and API data

A common architecture would be:

Customer channel → Voice/Digital Bot Flow enabled with Virtual Agent → Agentic Virtual Agent / AI Guide → Tools/Data Actions → External APIs → return context to Architect → resolve or transfer to agent.

Genesys allows AVA/AI Guides to be connected into Architect bot or digital bot flows, and the flow can mix agentic behavior with traditional flow logic using Call Guide / Agentic Virtual Agent actions. Tools work similarly to data actions, allowing the agent to retrieve real-time data or perform transactions through external APIs.

For voice, one important lesson is to manage response latency. Since LLM-based processing can take a few seconds, using a voice processing prompt helps avoid silence while the customer waits.

For context handling, I would recommend passing only useful and well-described variables from Architect to AVA, such as customer name, authenticated status, phone number, account type, current intent, or previous selections. Genesys documentation also notes that start/end context can be exchanged with Architect, but context variables should be simple/primitive data.

For bot-to-agent handoff, the best practice is to transfer with:

• Detected intent
• Customer summary
• Authentication status
• Data already collected
• Last API/tool result
• Reason for escalation
• Correct queue based on intent/context

I would avoid using AVA for everything. For high-risk, highly regulated or very deterministic processes, Architect logic is still useful. A hybrid approach usually works best: AVA for natural conversation, knowledge retrieval and flexible triage; Architect for routing, compliance, validations, retries and fallback logic.

Main lessons learned:

• Start with a narrow use case, not a full "general support agent"
• Define clear guardrails and escalation rules
• Keep API/tool schemas simple
• Test no-match, timeout and API failure scenarios
• Monitor containment, transfer rate, recognition failures and errors using the Virtual Agent performance dashboard
• Always design a safe path to a human agent

In short, AVA is most valuable when used as an intelligent orchestration layer, not just as a replacement for menus. The best results usually come from combining AVA + Architect + Data Actions + human handoff in a controlled hybrid design.

Excelente discussão, Alex.

Pelo que tenho acompanhado, o AVA parece ser uma evolução interessante para cenários em que os clientes não seguem jornadas tão estruturadas. Enquanto os fluxos tradicionais no Architect oferecem maior previsibilidade e controle, o AVA pode trazer ganhos na compreensão de contexto e na condução de conversas mais dinâmicas.

Na minha visão, um dos pontos mais importantes para avaliar é como a solução se comporta em processos que exigem integrações, regras de negócio e transferências para atendimento humano, já que esses costumam ser os cenários mais comuns em operações de CX.

Vou acompanhar os comentários, pois também tenho interesse em conhecer casos reais de implementação e entender quais benefícios foram percebidos na prática.

Great topic, Alex! This is a very interesting discussion, especially as AVA starts to open new possibilities beyond traditional bots and Architect flows. Understanding real use cases, integration approaches, handoff strategies, and lessons learned from implementations can really help teams explore AVA in a more practical and effective way. Looking forward to seeing the insights shared here.

Hi!

I'm currently exploring AVA and see strong potential for customer self-service use cases like FAQs, order status, appointment scheduling, and account-related requests.

What stands out to me is its ability to understand customer goals and context, plan the next steps, and work in a more natural way than traditional scripted bots, while still fitting into Architect flows and integrating with Data Actions or external systems when needed.

I'm also interested in how teams are using it across voice and digital channels, and how they are handling handoff to live agents when a human needs to take over.

Thanks!