Genesys Cloud - Main

Hi folks,

I am currently experimenting with Agentic Virtual Agents (AVA) and had a question about passing data back to Architect at the end of a session.

For example, let's say we want the AVA to determine an ai_intent variable by the end of the interaction. The final value could be one of:

• Sales

• Support

• Escalation

Based on this final intent, we'd like our Genesys Architect flow to route the conversation accordingly.

From my understanding, the AVA would need to call a tool to return this value. However, I'm struggling to understand how this would work when the value cannot be determined until the conversation is complete and the entire conversation needs to be analyzed before populating the variable.

1. If the intent is only determined at the end of the conversation, how can the AVA update the value before returning control to Architect? Even if this requires a dedicated tool (essentially a Data Action), how would that Data Action determine the value? My understanding is that Data Actions don't have access to the conversation transcript to analyze it and infer the final intent.

2. Another approach I was considering was passing variables into the AVA using Start Context and retrieving them using End Context. However, how can I get the AVA itself to modify or update the value of a context variable during the conversation so that the final value is returned to Architect at the end of the session?

Has anyone implemented a similar pattern, or is there a recommended best practice for returning a conversation-derived variable from an AVA back to Architect for post-conversation routing?

Hello Ramsha, 

Hi, thank you so much for the explanation. 

I haven't experimented with the AVAs much yet but from what I understand from your message, you're saying the only variables the AVAs can (natively) pass out are results from Data Actions or values that were passed in? That seems like a flaw.

Can they keep variables in their "memory" while the AVA is running, but just not pass them out? Like, could you just create a tool which stores the in-memory variable to a row in a Data Table, then retrieve that from the Architect flow (and then run a Data Action to delete that row)?

On your memory question: yes, the AVA reasons over the full conversation in-context, it just has no writable variable it exposes on its own

The workaround I discovered for my use case above is that End Context can pass out a tool's input, not just its output, and a tool input can be inferred by the LLM/LAM at call-time based on the whole conversation.

Here's what I am testing:

1. Create a tool and a Data Action since tool requires one (The Data Action itself doesn't need to do anything meaningful, in my case it just makes a throwaway call so it "executes successfully.") e.g: Set AI Intent, with an input field ai_intent.
2. In the tool instructions, tell the agent to call it once, as the final step, and to determine ai_intent (Sales / Support / Escalation) from the entire conversation.
3. The LLM composes the value at the moment it calls the tool, there's no variable being "updated," the tool call is where the value is populated.
4. In End Context, select that tool's Input field (not the output).
5. Read it in Architect and branch your routing.

One real limitation to flag: this only works if the tool actually gets called. If the user abandons the chat or it ends before the agent fires the tool, ai_intent is never set and Architect gets nothing

Still ironing out one error on my side around the Data Action's output handling, but the value does flow through. What are your thoughts on this approach?

------------------------------
Ramsha Shaikh
Engineer, AI
------------------------------

Use a Genesys Cloud Functions Data Action. It literally does nothing but capture what you tell it to. Create a JSON file or have AI do it, that is what i did.

ChatGPT or Claude can give you the instructions. I use this to capture input utterance that I can export. You can have the AI capture the utterance or transform it.

Thank you for the suggestion, I will try and implement this!

The best practice for returning a variable like ai_intent from the AVA back to Architect is to use the AVA's own "End Context" configuration. This lets you pass internal variables (set during the conversation) back to your Architect flow when the session ends. So, the AVA analyzes the whole interaction internally to figure out the final intent (Sales, Support, or Escalation), and at the end, it exposes that variable in the "End Context." In Architect, that variable will show up as an output from the "Call Agentic Virtual Agent" action, allowing you to route the conversation to the right queue, all without needing any external tools or Data Actions to analyze the transcript after the conversation is over.

Hi, by AVA's own "End Context" configuration. Are you referring to the "Exit Reasons"?

Based on the community discussions, your understanding is correct. The AVA itself cannot directly populate an end context variable from the conversation alone. However, you can achieve this using a tool that acts as a bridge, combined with Genesys APIs to get the transcript for analysis .

Here is a recommended pattern to implement your solution.

The Recommended Pattern: Tool + API

The key is to use a "dummy" tool, which can be a Genesys Cloud Function or a custom Data Action . This tool's sole purpose is to allow the AVA to send a value back to the Architect flow via the End Context. The final value of your ai_intent variable must be set as the output of this tool .

To make this work, you'll need to create a specific type of tool that acts as a post-conversation analyzer . Here's how to build it.

Step-by-Step Implementation

1. Create a Specialized Analyzer Tool: This tool will be called by the AVA at the very end of the conversation. Its job is to perform the final intent analysis.

   • Build a Data Action/Function: This tool will need to make an API call to get the transcript of the interaction . For a conversation, you can use the /api/v2/speechandtextanalytics/conversations/{conversationId}/communications/{communicationId}/transcripturl endpoint . Keep in mind that accessing this data might require specific OAuth permissions . This tool will then run its logic to determine the final intent based on the retrieved transcript.

   • Provide the Conversation ID as Input: The tool needs the conversationId as an input variable. This is easily passed from the Architect flow via the Start Context .

2. Call the Tool from the AVA: In your AVA's "Exit" behavior or as the final step in its conversation, you will call your custom tool. The AVA will pass the conversationId to it.

3. Configure the End Context: The output of your custom tool (the final ai_intent value) must be mapped to an End Context variable . This is configured in your AVA's settings.

4. Retrieve the Value in Architect: Back in your Genesys Architect flow, after the "Call Agentic Virtual Agent" action, you will have access to the End Context variables you set up. You can then use this ai_intent value in a decision block to route the interaction to the correct queue (e.g., Sales, Support, Escalation) .

Summary of the Architecture

This approach addresses the core challenge: the AVA is not analyzing the conversation to update a variable directly. Instead, it uses a tool that has the capability to perform this complex analysis at the precise moment it's needed.