The client operates in healthcare administration, supporting medical scheme clients across areas including benefits and cover, claims, pre-authorisation, chronic medication, membership administration and new applications. The work formed part of a wider knowledge management and Zoho Desk implementation.
That led us to a simple operating principle: The AI does the first pass. A person stays in control. The agent would prepare the work, while the consultant remained responsible for reviewing and sending anything client-facing.
Business Challenge
Client queries often require information from several places before a consultant can respond. The relevant scheme or product may be recorded on the ticket, held against the contact record or mentioned in the conversation itself. A ticket may also contain several separate questions that need to be dealt with individually.
The knowledge behind those answers can be detailed. Benefit information may include provider requirements, co-payments, exclusions, limits and eligibility conditions. Those details need to carry through into the response. The project focused on whether an AI agent could complete this first-pass work reliably enough to support consultants. It needed to establish the client context, understand what was being asked, find the appropriate published knowledge and prepare a useful draft.
The operating boundaries were also clear. The agent would not send responses, resolve tickets or make changes to ticket ownership and priority. Clinical queries, urgent cases, complaints and disputes required defined routes back to a person.
Solution Overview
Both& configured a first-pass ticket-handling agent using Zoho Desk and Zia Agent Studio. When triggered, the agent reads the ticket, conversation history and linked contact record. It establishes the scheme and product using a fixed order of sources, then identifies each question contained in the ticket.
It searches for relevant published knowledge and uses that information to determine how the ticket should be handled. Where the available knowledge supports a response, the agent prepares an unsent draft for the consultant. It also applies the appropriate tags and adds a private internal comment.
The agent has limited write permissions. It can apply tags, create a draft reply and add a private comment. It cannot send an email, change the ticket status, change the owner or priority, or reassign the ticket.
Getting the full source into the agent
Knowledge retrieval became an important part of the build. During testing, the agent identified the correct knowledge article for a benefit question but produced an answer that left out an important condition. The standard Zoho Desk article tools were returning article metadata and a summary. The full article content, including the qualifying condition, had not been passed to the model.
Both& created a custom retrieval tool to fetch the complete article body. The agent now retrieves each candidate article in full, confirms that it is published and uses the full content when preparing its answer. This gave the agent access to conditions and exceptions that may not appear in a search summary. It also provided a clearer grounding rule for benefit information. Every benefit statement in a draft must be supported by the retrieved article, including the relevant qualifying conditions.
Implementation & Technical Complexity
The agent was developed through several rounds of testing and refinement. Early versions used broader instructions and gave the model more freedom to decide how to complete a task. Testing showed inconsistent behaviour when information was missing, a tool failed or the ticket fell outside the expected path.
The workflow became more specific as the build progressed. The final configuration uses a nine-step process. Each step defines the action to perform and, where applicable, the tool to use. The agent reads the ticket, reads the conversation history, checks the contact record, establishes the facts, passes through an initial decision gate, retrieves knowledge where appropriate, passes through a second gate, prepares the required output and completes the permitted write actions.
Ten outcome paths cover the main scenarios identified during testing:
Fully answered Partially answered More information required Knowledge gap Wrong scheme Scheme unknown Retrieval failure Acknowledgement only Complaint or dispute
Results & Impact
The project delivered a beta AI agent capable of completing a structured first pass on healthcare support tickets.
The agent can:
- read the ticket and conversation history;
- check the associated contact record;
- establish the relevant scheme and product;
- identify separate questions within the conversation;
- retrieve and read published knowledge;
- determine the appropriate handling path;
- prepare a draft response where permitted;
- tag the ticket with the outcome; and
- leave a private note for the consultant.
This gives the consultant a prepared starting point for tickets the agent can support, while cases requiring judgement or escalation remain with the service team.
Strategic Takeaways
The project produced a reusable approach to building supervised AI agents in Zoho Desk.
Testing showed that reliability improved as the workflow became more specific. The final design defines the order of operations, the tools available at each stage, the conditions that stop processing and the expected outcome when the agent cannot complete a request.
The work also showed the importance of looking beyond the model when troubleshooting AI behaviour. Tool responses, source content, permissions, triggers and deployment configuration all affected the quality and consistency of the result.
Several reusable assets came out of the project, including the agent configuration pattern, custom knowledge retrieval approach, outcome model, guardrails, testing method, troubleshooting process and rollback procedure. These provide a practical starting point for future agent use cases without requiring each implementation to begin from scratch.
