Hi everyone, coming back to this thread with a bit more hands-on experience.
Since my last post, I've been involved in building and auditing several AVAs in production and UAT, across different segments (retail, financial services, healthcare and airline logistics). I'd like to share some practical lessons, especially around the question that came up a few times here: what should live in AVA and what should stay in Architect?
1. The AVA vs Architect boundary
The rule that has worked well for us:
• Architect: routing, queues, compliance rules, hard validations, retries, fallback and handoff. Everything deterministic and auditable stays here. Routing and directing the customer to the right queue/skill is Architect's responsibility. The AVA identifies the intent and outcome, but the routing decision itself belongs to the flow.
• AVA: the conversational layer. Intent understanding, context collection, deciding which tool to call and in what order, and explaining results in natural language.
One anti-pattern we've found repeatedly in audits: deterministic orchestration written in natural language inside the AVA's instructions ("if X, then do Y, otherwise Z" as prose). This creates unstable behavior. If the logic is deterministic, it belongs in Architect or in a function. The AVA should receive the resolved result, not re-implement the rule in a prompt.
2. Guidelines are not Guardrails
Reinforcing what Lineu said, with field data: in the audits we've run, one of the most recurring findings is guardrails being used as guidelines (and vice versa). Guardrails are hard blocks for security/compliance; guidelines are behavioral guidance. Mixing them causes false blocks and inconsistent responses. Also, watch out on agent import/export: custom guardrails populated in the JSON can cause version errors on import, so it's worth re-adding them through the UI afterwards.
3. Tool contracts are where the bugs live
Most of the "strange" behaviors we investigated weren't in the main prompt, but in the tool contracts:
• Describe every field, input and output. An undescribed field means the model invents its own interpretation.
• Align enums and values between what the API returns and what the instructions expect. Enum mismatches are silent bugs.
• Instruct comparisons explicitly. Real example: an API returned a future scheduling date and the AVA told the customer the credit "had already been made". The fix was in the tool's output instruction: forcing an explicit comparison with today's date, including the equality case. LLMs don't do date arithmetic reliably without direct instruction.
• Large lists: when an API returns many items (modules, symptoms, time slots), you can control pagination through instructions (for example, present at most 5 at a time) without touching the function.
4. Where AVA really shines: the customer who doesn't know what to ask for
The case that most convinced me of the agentic value: technical support ticket creation, where the user describes the problem subjectively ("the system froze when I tried to issue the document") and the AVA has to translate that into system, then module, then symptom by chaining API calls, explaining each option to the user in plain language, and only then opening the incident in the ITSM. A traditional bot would require huge menu trees and still fail, because the customer doesn't know the internal taxonomy. (Shane, this is exactly an IT service desk use case on a digital channel, and it works very well.)
In one of the retail projects, this approach reached ~84% retention, versus ~30% for the traditional bot it replaced.
5. Knowledge base: sometimes the problem isn't the prompt
When the AVA uses a KB and "can't find" the articles, the instinct is to tweak the prompt, but in most cases the problem is in the base itself: insufficient training phrases, or phrases colliding across similar articles. Practical lessons: around 20 to 25 alternative phrases per article, and be careful with clusters of very similar articles (for example, the same subject split by internal process stage), because generic phrases collide and the search returns the wrong article. KB curation is ongoing work, not setup.
6. Handoff and context with Architect
Answering @Swati Shrivastava's question: yes, AVA exchanges context with the Architect flow. On the way in, you pass simple variables (authenticated status, data already collected via API before the agent starts); on the way out, the AVA returns its outcome to the flow, and Architect makes the routing decision. Queue, skill and priority stay in the flow, not in the agent. Best practices we've adopted:
• API lookups that always happen (balance, customer record) run before the AVA, in Architect, and come in as context. This reduces latency and tool calls.
• Clear, counted escalation triggers: for example, transfer to a human after N failed searches or N unsuccessful attempts.
• What travels in the handoff: detected intent, authentication status, collected data, last API result and escalation reason.
7. Measure business outcomes, not just containment
Retention and transfer rate are the starting point. What has actually convinced clients is a business metrics framework: volume resolved before/after, post-interaction satisfaction, and indicators outside Genesys (in healthcare, for example: completed bookings and no-show reduction). This also matters because the pricing model is per conversation reaching the agent, so the business case needs to close on outcomes, not just automation.
In short: AVA doesn't remove the need for good design. It changes where the design happens. It moves from the flow tree into persona, tool contracts, knowledge curation and governance. And the winning architecture is hybrid: AVA owns the conversation, Architect owns control.
Happy to go deeper on any of these scenarios!
------------------------------
Mateus Nunes
CX Manager at Solve4ME
mateus.nunes@solve4me.com.brBrazil
------------------------------