Designing AI Agents

New AI Agent types

As previously mentioned, our AI Agents were initially built to be used in the Customer Support space, but with our new focus in the Fintech space, they needed to be able to conduct product sales based on our customers' needs. The structure and the way the Customer Support Agents worked didn’t match the requirements for product sales, and their reactive nature couldn’t provide the services required from a campaign, such as actively pursuing customers. Through research and user interviews, we decided to start with 4 use cases for the Fintech space for the new AI agents to be able to cover (i.e., debt collection and product adoption). These use cases became new Agent types that users could now choose during the creation process. But why divide them into types and not have one AI Agent cover all use cases? Having separate types depending on the use case will help them specialize in the context of the environment they will work in beforehand. In other words, the user won’t need to explain to the Agent what his primary purpose is, so the data and effort required from the user are significantly reduced.

More automation

More automation. Smarter interactions. Less manual work. We followed these three principles in the design process and applied them while creating the new information architecture. Our main goal was to move on from the time-consuming, manual inputs and offer a smarter system to assist the user with minimal input. We added sections like the Agent’s Knowledge, an option to autogenerate the content of a field (for example, the Product Benefits) by just adding a relative URL and even generating content from data of previously filled sections. We extended this feature by allowing the user to get better suggestions from our LLM for his manual inputs (like a small sentence). Of course, everything can be edited later so that the user has full control.

Guidelines & Agent goal

With our goal in mind, we wanted to approach the AI Agent creation process differently to increase usability, especially for new users, since the current approach didn't yield very good results due to its complexity and lack of a simple process flow. With the latest, improved version of our LLM we had the opportunity to approach the process outside the box: what if the data could be autogenerated instead of manually creating flows? In previous iterations, users had to create a series of dialog flows that would cover each scenario, create intents and entities that would give more context to the AI, connect a collection of data sources, and much more. What if, instead, users could just instruct the Virtual Agent to achieve a goal, and the means for it to accomplish it would come from already existing data? This was the vision for the Agent’s “Goal” and “Guidelines”.

Navigation/ Information Architecture (IA)

In the previous UI, the navigation in the AI Agent page was created around the dialogs. For those unfamiliar with this concept, dialogs are small, independent components that define the flow of the conversation based on specific triggers. For example, when a user sends a greeting message (trigger), users can define the specific answer the Virtual Agent will give by creating a dialog. This meant that every navigation item was based on a supporting feature or component of the dialog system and wasn't organized with a linear flow in mind, which didn't help users know the right steps needed to complete the Agent creation process. In the new iteration, the dialogs take second place and become one of the last optional steps necessary for completing the creation process. For the new navigation, we grouped all the features necessary for a step or a process or with a similar function together under a category. With this approach, we concluded with 5 navigation elements in comparison to the 8 we had before. The biggest UI change was the transition from a horizontal navigation to a vertical sidebar and the nesting of specific features and pages inside the last two tabs.