Genesys Cloud - Main

 View Only

Sign Up

  • 1.  Agentic Virtual Agents

    Posted 04-01-2026 13:09

    Hi Everyone,

    Is it possible to chain multiple AVA's such that one AVA can kick off another one if the customer asks for multiple actions to be taken.  If not, is there way to do it or is this on the roadmap?

    Thanks


    #AIConfiguration

    ------------------------------
    Kashaf Chaudhry
    Customer Success Director
    ------------------------------


  • 2.  RE: Agentic Virtual Agents
    Best Answer

    Posted 04-01-2026 13:14

    Genesys doesn't currently support a formal AVA-to-AVA chaining feature. Instead, AVAs are used within bot flows, with Architect calling AI Guides during execution.

    There are two options:

    The recommended approach is one AVA managing the entire request, using reasoning and actions across systems.

    Or

    If separation is needed, Architect handles orchestration between flows, but this is flow-level routing-not AVA-to-AVA chaining.

    Bottom line: Multi-step experiences are supported, but not as direct AVA chaining. Best practice is a single AVA per conversation goal, with Architect and data actions coordinating backend steps.



    ------------------------------
    Qasim Chaudhry
    Professional Services Director
    ------------------------------

    Original Message


  • 3.  RE: Agentic Virtual Agents

    Posted 04-02-2026 03:08

    Hi have a question that's kinda related to this. 

    Hypothetically speaking, say you have a queue with Agents on it, and through the interaction, they hand off a caller to an AVA that's on another queue.  Will the AVA be able to resume the call with the information (existing call transcript) stored against the interaction, or would the caller need to re-explain their issue.

    It's probably not a great use case, but say a Sales business answers the call with a Human Agent, they do all the selling and to complete the sales order, they hand it off to an AVA to complete the part of the sale where you capture information etc.  Could that AVA take every thing that's been discussed with the Human and finalise the sale with the caller.  This could mean the initial sales staff could jump back on queue to talk to another customer whilst the AVA processes the orders.



    ------------------------------
    Robert Niblock
    Contact Centre Technology Analyst
    ------------------------------

    Original Message


  • 4.  RE: Agentic Virtual Agents

    Posted 04-02-2026 04:08

    From my experience with it in the LA. You would need to feed the agent the information from the human interaction via starting context. 



    ------------------------------
    Savino Ricci
    Senior Technical Consultant
    ------------------------------

    Original Message


  • 5.  RE: Agentic Virtual Agents

    Posted 18 days ago

    Good afternoon all.

    I am finding it hard or close to impossible for AVA to capture information that was not used as part of a Tool/Data Action within AVA.

    For example, to complete tasks that are outside of AVA's primary function, AVA has to escalate to a Live Agent. I was hoping to pass on additional bits of information for the Live Agent and avoid the need for them to ask the caller the question again. Like the last question raised by the caller, which is not captured in a system variable like Session.LastCollectionUtterance.

    Additional observations

    • There is no capability within AVA to declare variables to store information captured and to be passed out of AVA into Architect Flows.
      • The capturing of information was easily accomplished within Call Guides where variables could be declared, ideally the same capability could be made available within AVA in the near future.
    • I have also found (so far in my testing) ID verification within AVA is a hit and miss.
      • The best path forward for now would be to validate before the customer gets to AVA.
    • Using the Data Action within AVA to send out Agentless Email and SMS is straightforward and if you don't care on how the information appears when received by the end-user. 
      • Is there a best practice guide on telling AVA how to format the outbound email/SMS Body? It's been a trial-and-error process to have the information nicely laid out and presentable. Unfortunately, the same outcome is not guaranteed when the same configuration is used in a second AVA deployment.
    • When using AVA with Voice, how do we go about modifying the speech cadence for AVA?


    ------------------------------
    Bernard
    CALLSCAN AUSTRALIA PTY. LTD.
    ------------------------------

    Original Message


  • 6.  RE: Agentic Virtual Agents

    Posted 17 days ago

    To bring the data from Architect flow to AVA - Use start_context variables to input the data.

    To extract the data out of AVA - Though there is no direct way of defining variables within AVA to capture the data that is generated while in conversation, one can still leverage the capability of tools (Data Actions) to call API to set the data needed as participant data in the conversation or use some external API to store the data externally. Then this data can be used within Architect flow or for any other process.



    ------------------------------
    Jyoti Sharma
    Senior Design Consultant
    ------------------------------

    Original Message


  • 7.  RE: Agentic Virtual Agents

    Posted 17 days ago

    Good morning Jyoti.

    Yes, I am aware I could make use of a Data Action to capture the data. However, the underlying premise of AVA, not only was it to provide a more natural conversational experience, but it was also meant to make building and configuring much easier. 

    Creating and utilising Data Actions just to capture bits of data is not something I would consider making it easier.

    Consider if you have a Data Action to capture 5 bits of information and now with new business requirements you need to capture another 1 or more new bits of data. You would have to create a new Data Action and adding the new attributes in the Input Contract, which we know is simple, but then to add it to AVA it is not so simple and straightforward. Alternatively, we could create 1 new Data Action for the 1 or more attributes and add that in as new into AVA.

    Using a Data Action to capture and store bits of information is workable but from a design and function perspective, not so much.



    ------------------------------
    Bernard
    CALLSCAN AUSTRALIA PTY. LTD.
    ------------------------------

    Original Message


  • 8.  RE: Agentic Virtual Agents

    Posted 17 days ago

    I agree with Qasim that today the orchestration model is much more Architect-driven than true AVA-to-AVA chaining.

    What I've been seeing in practice is that the "single AVA per business outcome" approach tends to work much better operationally, mainly because once you start splitting responsibilities across multiple AVAs, some challenges appear quickly:

    • conversational context continuity

    • variable persistence

    • transcript/state sharing

    • tool orchestration ownership

    • escalation consistency

    • observability/debugging

    Robert's scenario is actually a very interesting real-world use case and highlights one of the current architectural gaps.

    Today, AVA does not behave like a fully persistent conversational memory layer across independent AVA instances. So if a human agent transfers the interaction to another AVA/domain, you usually need to explicitly pass context through:

    • start_context

    • participant data

    • tool outputs

    • external state storage

    • Architect orchestration

    Otherwise, the second AVA may lose important conversational/business context and force the customer to repeat information.

    I also agree with Bernard's point that relying excessively on Data Actions purely for conversational memory persistence can become operationally heavy very fast, especially at scale. Technically workable, but not always elegant from a solution architecture perspective.

    Personally, I think one of the biggest future evolutions for AVA will likely be around:

    • native conversational memory/state handling

    • variable declaration inside AVA

    • easier context persistence

    • reusable orchestration between reasoning domains/tools

    because once customers move from simple FAQ use cases into true multi-step agentic orchestration, these limitations become much more visible.



    ------------------------------
    Gabriel Garcia
    NA
    ------------------------------

    Original Message


Related Content