Skills
What is a Skill?
You have lots of skills. Maybe you can sing or play the piano. Perhaps you know how to sew or throw a pot. You definitely can read and converse.
Most AI chatbots, however, really only have one skill. They know how to answer questions. In most cases, a chatbot answers questions by finding relevant content — typically on a website — and uses LLM to generate an appropriate response.
We say that the difference between an AI chatbot and an AI assistant is that the former has one skill while the latter has many skills. And, ideally, that range of skills is extensible — meaning that you should be able to teach the assistants you offer your web visitors to handle a range of tasks.
To put you in the right frame of mind, think about other things that you expect visitors to want while on your website. They may want to leave you a message or sign up for a webinar. Or maybe they want to purchase some of your products. They may be customers who are having trouble and need support. The list is endless. By endowing your assistants with skills, you are helping your visitors get a better experience by addressing their needs.
This document is going to teach you how to teach your assistants the skills you want them to have.
A Working Example: webinar-signup
Let’s start at the end and work our way back to the beginning. An example will help you better understand skills and how to create them. Afterward, we’ll go deeper on each part of the process.
Let’s suppose that you are hosting 4 upcoming webinars. You would like web visitors to sign up for one or more of these without having to talk to you. The problem is that these webinars are changing all the time. It’s too expensive to keep updating your website. And people don’t really like filling in forms. So let’s teach your AI assistant a new skill for this.
In your Navu portal, go to the Skills page. Click + to add a new skill. Choose “No Template” and fill it in as follows:
Name: webinar-signup
Applicability: This is applicable when the user asks about upcoming events or webinars or is responding to your follow-up questions.
Enablement: preview-only
Primary Instructions:
Ask the user which of the following webinars they are interested in:
October 15: Product deep dive
December 1: Customer party
Then ask the user for their full name and email address. Use the identify-visitor tool to report this new contact. Use the send-email tool to send an email to [enter email here] with the subject line “Webinar Signup”.
Tell the user to expect a confirmation via email within a couple of days.
Tools: identify-visitor, send-email
Be sure to replace that [enter email here] so you’ll receive the notification.
That’s it. Go to the Sidebar page and let’s test this new skill. In the sidebar, say, “Do you have any upcoming events?” and see what happens. Your AI assistant is going to ask you some questions. Then it will tell you that you’ve been signed up. Check your inbox and you’ll see the notification from the assistant telling you that someone on your website has signed up for a webinar, along with relevant details. It will even include a link back to the full conversation in case you need it.
Go to the Questions page. You should see a sequence of items corresponding to your testing. At the top of each question you’ll see a “Skill” field telling you which skill was used for that item.
If you see something about the behavior that you didn’t like, update the instructions accordingly and iterate until it’s perfect.
When you’re ready, change Enablement to ENABLED and this will make it available to all of your web visitors. Wow. That was simple!
Now read on so that you will understand how this works and what else you can do with this capability.
Applicability: Skill Selection
Your Navu assistants are built using AI best practices, which means using “chain of thought”. The best AI implementations break down large problems into smaller ones. In this case, imagine a two-step process for handling a user’s message. First, we figure out which skill is needed to handle the message within the context of the overall conversation. The second step is to use that skill to generate a response and take actions accordingly.
When you populate the Applicability for a skill, you are explaining to an AI when your skill is relevant. You don’t have to worry too much about any other skills that may be defined. You just need to make sure that it is clear from the context that your skill is or is not applicable. In the webinar-signup example above, we set the applicability to, “This is applicable when the user asks about upcoming events or webinars or is responding to your follow-up questions.” That first step in the process will look at the user’s latest message as well as all the whole conversation leading up to it and will look for a skill that is applicable.
In the Skills page in your portal, you will find that you are able to drag skills in the left-hand column up and down to reorder the list. That’s important, because that first step will look through the list for the first skill that is applicable. You might wonder why it isn’t the best match, rather than the first match. That’s by design. Sometimes you’ll find that you have one skill that handles a very narrow, specific situation, and then you have another skill that handles a broader set of situations. By putting the skills in the order you want, you can avoid having to make applicability descriptions more complex by trying to “carve out” special cases. Put the most specific skills before the more general ones.
Enablement
The enablement of a skill determines who will have that skill available to them when using their assistant. When you first create a skill, it will default to “preview only”. This means that only those who are previewing your sidebar will have access to this skill. So this is an easy way to ensure that others won’t start getting a skill before you “publish” it.
When you are happy with your new skill, you can publish it to all visitors by changing enablement to “enabled”.
Perhaps you have a skill that you want to unpublish. You can set enablement to “disabled”. Then no one will have that skill — even those who are previewing.
The last option is “audience specific”. For more details, see Advanced Settings > Audiences below.
Primary Instructions
The heart of the skill is in the instructions. As you’ll see in the webinar-signup example, these instructions are in natural language. Just think about how you would explain this skill to another person and that is very close to what you’ll want to use here.
In general, we recommend that you start with a simple set of instructions and build on them until you get the full behavior that you want. Suppose that in your testing, you don’t like how the AI explained to the visitor what to expect for confirmation. Return to the instructions and add something that requests a change in that behavior. Quickly, you’ll learn what works and what doesn’t.
Pro Tip: Be careful that the whole point of using an AI is that you are teaching it a skill and you want it to be able to adapt to the situation. As you get more and more specific in your instructions, you may be tying the hands of the AI to deal with some situations. For example, if you tell the AI the exact language to use in the final step, you may find that this handles the normal case well but could create weird responses in other cases that the AI will otherwise handle well on its own.
Pro Tip: In the webinar-signup example, you are listing a bunch of webinars to choose from. Think about what will be most convenient for visitors. In our example, we used a numbered list to suggest to the AI that it may be convenient for the visitor to make their selection by number rather than having to type a name.
Tools
A skill is pretty limited without any tools. It will only be able to response based on the conversation, your instructions, and what the LLM model knows inherently. Sometimes for very specific cases (such as how to answer a pricing question) that might be enough. But to do anything “interesting”, you’ll need one or more tools.
We’ll talk a lot more about tools later. For now, recognize that for each skill you will select which of the tools will be available when using that skill.
If you add a tool into your skill, you will probably want to explicitly refer to it in your instructions. In the webinar-signup skill, you’ll see that the instructions say to, “Use the send-email skill to send a notification email to…” Your instructions explain to the AI when to use a tool and how to use it. Generally speaking, you don’t have to know too much about exactly how a tool works. It provides its own extra instructions to the AI for that. For more sophisticated tools, you may need to read its documentation to know how to instruct the AI on how to use it.
Advanced Skill Settings
Most of the time, you will not need any advanced settings for your skills. But there are exceptions. Use them wisely.
Response Format Instructions
The Primary Instructions for the skill teaches the AI what it should do and how it should respond. In some cases, especially those where the skill will show the visitor a bunch of information, you may want to control the formatting of that response. For example, you might want to show the visitor a table or you’ll want to use a numbered list. Or you’ll want to make the response very concise or verbose. In these situations, you can add instructions in this field to explain what you want.
Audiences
This is for special cases where you want a skill to be available only to a certain subset of your website visitors and when you set Enablement to Audience-Specific.
This is built on top of Navu’s Audiences feature. In the Audiences tab, you can define a new audience and target a specific set of visitors. Then you can return to your skill and add that audience into the list of audiences.
For example, suppose you only want to offer webinar signups to those from North America. Or you only want those who arrive via a certain ad campaign to have it. Audience targeting is beyond the scope here, but you can learn about that elsewhere.
More Settings: Allow Prior Identity
In the webinar-signup example, the instructions indicated that we should ask the user for their name and email address. Navu has been tracking this visitor throughout their journey. It’s entirely possible that that user has previously provided their identity. Perhaps they filled in a Contact form on the website. Or in an earlier AI conversation they provided identity. It may be annoying to ask the visitor to repeat this information.
If you turn on Allow Prior Identity, then the AI will be informed of the user’s identity information that was previously collected if possible. In that case, you may want to adjust your instructions to say, for example, “If you don’t already know the user’s name and email address, ask for them.”
Why don’t we always tell the AI about this identity information if we have it? The webinar-signup is one of those cases where it might actually be preferable to ask the user for their identity, even if Navu had previously captured that in some other way. This avoids any confusion over which identity will be used for the sign-up.
More Settings: Use Advanced Reasoning
If you have a very complex set of instructions that perhaps demands a lot of reasoning by the AI, you can turn on this setting. This will allow the AI to take longer to “think” about the conversation and the instructions. So the responses will be slower, but may be able to deal with more complexity. You can decide whether that trade-off is worth it.
Tools
What Are Tools For?
Without tools, imagine that the AI is in a box. You can feed the visitor’s message into the box. The only thing the AI can do is to give you back a message to return to the visitor. That greatly limits what it can do. The LLM model itself has a lot of fundamental knowledge built in. But without a tool, the only thing it can use is that knowledge plus whatever instructions you give it.
Tools change all of that. Imagine that when you slide the visitor’s message into the box, the AI can reach out on the other side of the box and do more when trying to decide how to respond to the visitor. Navu has defined a set of built-in tools that any skill can use. Then you can take that further by creating your own tools.
Using Tools
Each tool has a name and a description. When you click on the Tools selection button in a skill, you’ll see a dialog listing the available tools. Click on them to toggle them on/off for this skill. That’s all that’s required. The skill is able to use the tools you have enabled, and cannot use any of the others. You might ask why we don’t make all tools automatically available to all skills. There’s a good reason. It’s because you may really not want a certain tool to be used except in situations where you need them. Even if your instructions do not ask the AI to use a tool, it will know what tools it has available and might choose to use them anyway. Better for you to be explicit about which ones you want.
You may see some tools listed that are disabled. That can happen when the tool depends on additional configuration or integrations and can’t work until those are provided. An example of this is the query-database tool. It will only be available after you have uploaded data and described it in a way that will allow the AI to use it. Another example is a post-slack tool which depends on you integrating Navu into your Slack instance.
Built-In Tools
Navu includes a number of “built-in” tools that are available to everyone. These are mostly all-purpose tools that come in handy to connect your AI to the real world.
file-search
The file-search tool is a critical tool. The most basic skill is answer-question, which is the skill that handles everything that isn’t handled by any other skill. It depends on the file-search tool to find the content needed to answer the visitor’s question.
The file-search tool uses a vector database to efficiently search for content that matches a text query (or multiple queries) provided to it. This is built on top of the Navu index of your website content, plus any other content that you’ve chosen to add to your index. The answer-question skill formulates queries based on the visitor’s question, uses file-search to find relevant content, and then formulates an answer.
This tool is available for use in other skills as well. For example, you might define a skill that handles questions about case studies. Suppose that you ask the visitor what kind of case study they want, and you formulate an appropriate search query. Then you use the file-search tool to find relevant content on your website. And you use that content to answer their question.
fetch-page
Sometimes you want a skill that takes advantage of certain specific content that you have on your website. You don’t need to search for it. You know exactly where it is. That’s what the fetch-page tool is for. Note, however, that the fetch-page tool only operates on content that is in your site’s Navu index. If you need something else, you can add it into the index first.
For example, suppose you want a skill that will answer pricing questions but you only want it to use information that you’ve already composed on your pricing page. You don’t want the general-purpose answer-question skill to use a bunch of irrelevant content in your blog or something. So add a skill with instructions that include, “Use the fetch-page tool to get the contents from https://mycorp.com/pricing and then formulate an answer accordingly.”
navigate-browser
Suppose that a visitor says, “Take me to the pricing page”. You could do a search to find the pricing page, and then give them a link to that page. But wouldn’t it be better to simply navigate their browser to the pricing page? This navigate-browser tool knows how to send a command to the browser to actually navigate to a URL.
In fact, Navu provides a built-in skill called the “go-to” skill that does exactly that. So you don’t need to replicate that. But you might come up with other cases where you’d like to navigate the browser. For example, suppose you ask the user a series of questions and determine that they need some specific piece of content. Your skill can include the navigate-browser tool and you can include an instruction that says something like, “… then use the navigate-browser tool to move to https://mycorp.com/special-page.”
send-email
In the webinar-signup example, we used the send-email tool to send a notification email to an internal address that will handle the signups. This tool is designed for that purpose — to send emails to your own team. It is NOT designed to send emails to visitors or others. These emails are sent from Navu so you don’t want us to send email to your customers directly. (To send email to your customers, you most likely want to use your CRM or another tool for that purpose, and you may need a custom tool to accomplish that.)
The send-email tool allows you to specify a recipient, a subject line and a body. The body of the email will also include a link back to the conversation in the Navu portal — which is often useful to provide context to the recipient, assuming they have access to Navu.
post-slack
If you have integrated Navu with your Slack, then you can use the post-slack tool to post a message into one of your slack channels. You can choose which channel (defaulting to the same channel where Navu posts other notifications). And you can ask the AI to compose an appropriate message according to your instructions.
This tool is unavailable until you integrate Navu with Slack.
identify-visitor
Navu is tracking web visitors. It monitors when they fill in forms. The Navu sidebar has a Contact form. There are many ways that Navu may become aware of a visitor’s identity. Another way that that might happen is because the visitor specifically tells the AI his or her identity information. The webinar-signup skill is a perfect example of that.
The identify-visitor tool is used to associate identity information with the current visitor. When this tool is used, that identity information is used much the same way as when a user fills in the Contact form. The visitor journey will report this new information. And if Navu is integrated with a CRM like HubSpot, that information will be reported to it as well.
You might wonder why this tool is needed. Why not simply always grab the visitor identity provided during the conversation and record it? There are two reasons. First, you can imagine conversations where identity information is exchanged, but it isn’t about the current visitor but, rather, about someone else. If the AI gets that wrong, it could cause embarrassing results. Better to be explicit when you understand that the identity information warrants collection. Second, by the nature of the skill, it is conceivable that the AI might get identity information in a way that isn’t obvious within the conversation. For example, suppose that the skill asks the user for a piece of information like an ID number. It uses another tool to look up that ID number to get identity information and then it can use the identify-visitor tool to report that identity information — which was never explicitly mentioned by the visitor.
query-database
The file-search tool is used to query the website content for information that can be used to formulate answers. Sometimes, though, the information needed is data-centric rather than text. While you might associate a “database” with a big backend system containing gigabytes of structured data, you might also recognize that data can also be more modest — such as a spreadsheet containing a list of upcoming events, or a parts catalog, or any number of things. You may have many different datasets containing various kinds of information.
Dealing with databases can be complex. Our goal is to make things as simple as possible. We created the query-database tool with that in mind. When developing a skill, we don’t want someone to have to understand complex query languages or complex data relationships. Happily, LLMs are very good at formulating complex queries based on natural language instructions — as long as they have a good description of the available data.
Let’s look at an example. Suppose you have a spreadsheet containing hundreds of rental properties that you manage. Each row in the spreadsheet is for one property. The columns contain specific information about that property such as location, size, availability, price, bedrooms, features, etc. You’d like a skill for your web visitors to allow them to find properties in a conversational way. Let’s assume that someone has already uploaded your spreadsheet and described this data. Your skill can probably be very simple. The instructions might not need much more than something like, “Analyze the user’s question and formulate one or more queries into the properties collection to answer it if possible. Once you have the necessary information, formulate an appropriate response.” Wow. That’s pretty simple.
After uploading your spreadsheet to Navu, in order to describe your data, you’ll go to Settings > Sidebar > Guide > Tools > Database Tool Sources. You’ll add one source for each uploaded spreadsheet. In each one, you’ll give it a “collection” name and then you’ll populate its Schema, explaining what the dataset contains and what each row and column represents. Navu will do the rest.
For more details, see the Data-Oriented Skills section below.
Custom Tools: REST APIs
Recall that a tool allows the AI to reach out to the “real world”. One way to do that is through so-called “REST” APIs. These are simple APIs that are invoked across the internet. Navu makes it possible to create new tools that are built on top of these REST APIs. For each new tool, you need to know the URL and you need to describe what to send to it, and what you’ll get back from it.
Full details on creating and testing REST APIs is beyond the scope of this document. Please get in touch when you’re ready to dive in.
Custom Tools: Zapier Catch Hooks
Another way to create a custom tool is to take advantage of Zapier, which is an open platform for connecting different systems together. One system fires a “trigger”. Within Zapier, you can define what happens when that trigger is fired.
Navu allows you to create tools that will fire Zapier triggers or what they call “inbound webhooks”. This is unidirectional. Your tool can send a trigger containing data to an inbound webhook. But because of the nature of how Zapier works, you cannot get any data back. So these tools are best for pushing data into other systems. For example, suppose that instead of sending an email notification about that webinar signup, you have an internal automated system for this, and you just need to push the signup information into Zapier, and hook that up to your existing system.
To define a Zapier-based tool, you just need the URL of the trigger (inbound webhook). And if you want to send data to it, you need to describe each field in that data. In the webinar-signup example, perhaps that is firstname, lastname, email address, and event name. This is done in Settings > Sidebar > Guide > Tools > Zapier Catch Hooks.
Data-Oriented Skills
Most AI chatbots are trained on text-based content, such as the webpages on a website, PDF files, etc. When asked a question, a text-oriented search is done to find the content most relevant to that question and then the AI formulates a response using that selected content. This works extremely well in most cases to synthesize good answers.
What does not work with this approach are questions whose answers lie in highly structured data.
Let’s start with an example. Suppose you are a vacation rental service. You have a spreadsheet containing 10000 rental properties, one row for each. The columns contain the city, state, country, number of bedrooms, weekly rental rate, whether pets are allowed, whether there is a pool, availability, and so on. Let’s suppose that you want to allow web visitors to have their AI assistant help them find listings that interest them. Imagine that the visitor might ask, “Do you have any listings available in North Carolina?” The AI might answer, “Yes. We have 242. Can you describe more about what you’re looking for?” The visitor says, “Yeah. I want something with at least 4 bedrooms and a pool. And we have a dog.”
So let’s start with a skill:
Name: property-finder
Applicability: This is applicable when the user is asking to find property listings.
Primary Instructions: Ask the user to provide some information about what they are looking for. Use the query-database tool and formulate appropriate queries to find the appropriate listings. If the list is long, ask the user for more details to narrow down the results.
Could it be that simple? Yes! But in order for the AI to be able to deal with this broad set of instructions, it will need to have a good understanding of what all of that spreadsheet data means. That’s where the Database Schema comes in.
So let’s finish this example by describing the data in that spreadsheet. In Settings > Sidebar > Guide > Tools > Database Tool Sources, you’ll define a new dataset for that spreadsheet.
Name: listings
Dataset Description: “This contains comprehensive information about all of the available property listings.”
Record description: “Each record represents one property listing”
Data Fields/Columns:
- ID: (string) The unique identifier for this property listing (primary key)
- Address 1: (string) The street address of the listing. Never share this information with users.
- City: (string) The town or city in which the property is located
- State: (string) The state, possibly abbreviated, in which the property is located such as California or CA.
- Country: (string) The country in which the property is located such as USA, France, etc.
- Weekly Rate: (number) The rental rate per week in US dollars (indexed)
- Bedrooms: (number) The number of bedrooms (indexed)
- Bathrooms: (number) The number of bathrooms (indexed)
- Pool: (boolean) Does the property have a pool?
- Pets Allowed: (boolean)Are pets allowed?
- Ocean view? (boolean) Is there an unobstructed view of the ocean?
Compound keys:
- Country + State + City: location
With this data description, that skill should do a pretty good job at answering a wide range of questions that a visitor might ask. That’s because the AI is good at formulating database queries when it understands how the data relates to the questions being asked. And that means that you don’t need to be a database expert to use it.
Uploading Data
In order to use these capabilities, the most important thing is the data itself. As it stands today, you must provide your data to Navu personnel in order to get it “installed” in your site. That will soon change as you’ll be able to upload it directly from within your portal, or point to where your data is located elsewhere.
Your data can be stored in a variety of forms. If you have a spreadsheet, you will typically want to export a CSV file containing the specific data you want to use in Navu. If you have a SQL database, you can also export CSV data from it. If you dataset is extremely large (more than 50MB) talk to us about the best way to proceed.
Describing Data
Once we have your data installed, you can then go ahead and describe that data as shown in the product listing example above. That is done in your Navu portal at Settings > Sidebar > Guide > Tools > Database Tool Sources.
You are able to have multiple datasets. You might have different datasets that are independent and get used for different skills. For example, you might have one dataset that represents all of your upcoming events, and another that is a list of all of your local resellers. In some cases, you may have related datasets. For example, you might have a list of resellers in one dataset, and a list of reseller contacts. Each contact may have a field that indicates which reseller they are associated with. In these cases, you need to explain that relationship so that the AI will know how to combine information between datasets. When this is the case, in any field that links two datasets together, you will add a “Table Correspondence” that effectively says, “The value in this field corresponds to the value appearing in the X field in the Y dataset.” You should add these correspondences in both directions. There can be lots of links among fields in different datasets.
Try to fully describe each field in each dataset. These descriptions are essential to the AI being able to associate that information with the questions that visitors may be asking. Sometimes the meaning of a field will be obvious to you, but remember that the AI might not have the same understanding that you do of your business.
The AI is extremely good at formulating appropriate database queries. But in large datasets it is also important that these queries will be efficient. That depends on having good indexes in your data. In most cases, each dataset will have a “primary key” — the field that has a unique value distinguishing it from all other records. That might be some kind of ID or perhaps a unique name or something else. It isn’t required that every dataset have a primary key, but when that is available you should identify it — especially when it can be used to link fields between datasets. In addition to primary keys, you may want to add indexes for other fields in your datasets. That will be the case when you think the AI might want to create a query that will depend on efficiently searching for records based on that field’s value. For example, let’s suppose that a visitor says, “I am looking for something between $3000 and $4000 per week.” That suggests an index on the price field.
Compound keys are for the special cases where you think it is likely that a query will involve multiple fields. In the property listing example, we have a compound key for country+state+city. Typically these are listed in order of specificity. So when someone says, “I’m looking for listings in North Carolina”, the AI will know that North Carolina is in the United States and it can do a query that focuses in on a small subset of all listings.
If you’re in doubt about how to use indexes, just ask us. We’re happy to help. If your data is coming from a SQL database, you can probably find out the list of indexes in that database as a good starting point. If you have a small dataset, you normally won’t need to worry much about indexes at all.
Using Your Data
Once you have uploaded and described your data, you’ll see that when editing skills, the query-database tool will be available. Add it and you’re ready to go.
In the instructions for your skill(s) that will use this data, it is best to be as specific as you can about which data you want to be used and how to use it. For example, suppose you have two datasets — one for events and the other for property listings. When you enable the query-database tool, all of that data is accessible by the AI. But if your skill is for responding to requests for listings, your instructions should explain that. For example, “Use the query-database tool and the information in the listings dataset. Formulate appropriate queries based on the question and use the results to formulate an appropriate response or follow-up question.” This tells the AI to focus on the listings dataset.
