---
sourceDocument: Zurich Conversational Interfaces
sourceDocumentLink: https://www.servicenow.com/docs/r/zurich/conversational-interfaces

 Release :

    - zurich

ft:locale :

    - en-US

ft:publication_title :

    - Zurich Conversational Interfaces

ft:clusterId :

    - convint

bundleId :

    - convint

workflow :

    - Platform


---

# LLM description and instruction guidelines for Virtual Agent topics

# LLM description and instruction guidelines for Virtual Agent topics {#ariaid-title1}

Release version: Zurich  
Updated July 31, 2025  
![](https://www.servicenow.com/docs/portal-asset/ico-clock) 4 minutes to read
Summarize  
![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) Summarized using AI  
This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.  

## Summary of LLM description and instruction guidelines for Virtual Agent topics

ServiceNow customers creating large language model (LLM) topics for Virtual Agent can use text-based descriptions and instructions to guide how the LLM discovers and responds to topics.
The Assistant Designer Asset library provides fields to enter these descriptions and instructions, enabling precise control over topic matching and response behavior.
Show full answer Show less  

## Descriptions

Descriptions are mandatory for topics and play a critical role in topic discovery. Detailed and specific descriptions improve the accuracy of topic matching by clearly defining the topic's purpose and context. Unlike keyword-based NLU utterances or generic search descriptions, LLM descriptions should focus on logical clarity to guide the LLM effectively.

## Instructions

Instructions are provided in the Detail description field of LLM user input controls. They tell the LLM how to respond, including specifying tone, managing small talk, and dynamic greetings. Instructions also help with entity detection and slot-filling by defining expected input values and operational context.

## General Guidelines

* Use clear, direct, and imperative language beginning with action verbs to instruct the LLM effectively.
* Avoid answering questions with questions to prevent confusion in conversations.
* Exclude references to third parties and pronouns to reduce misidentification of users by the LLM.
* Provide detailed, logical, and chain-of-thought instructions to improve response quality.
* Iteratively test and refine instructions to optimize LLM behavior.
* Do not use NLU utterances or Google search-style descriptions as LLM descriptions because they do not guide the LLM logically.

## Practical Examples

Strong descriptions specify possible user queries and scenarios, such as asking for holiday lists by year or specific holidays, whereas weak descriptions are generic and less actionable.

For input controls, unique and descriptive node names help the LLM correctly map user inputs to the intended operation or entity. Detailed instructions specifying mapped values enable the LLM to extract correct entities and fill slots accurately.

## Key Outcomes

* Improved topic discovery through detailed, logical descriptions tailored to the task context.
* Enhanced LLM response accuracy and relevance via clear, actionable instructions.
* Reduced user confusion and improved conversation flow by following best practices in instruction design.
* More precise entity extraction and slot-filling through unique node naming and value mapping.  
When you create large language model (LLM) topics, you provide instructions that determine the behavior of the LLM and a description that determines how the topic is discovered by the LLM.

## Overview of LLM description and instruction guidelines {#va-llm-instruction-guidelines__section_nhr_1qz_kbc}

Topic authors can use plain text wording to tell the LLM how to discover an LLM topic, as well as tell the LLM how to respond. The Assistant Designer Asset library interface provides text fields that let you provide both.  

Descriptions
:   Topics require a description when you create them. The description is used for topic discovery, so the more detailed and specific the topic description is, the more likely it will be to find a good match.

Instructions
:   When you add LLM user input controls to your conversation flow, you can provide instructions to the LLM in the Detail description field, which tells the LLM how to respond. You can use this field to
    define tone, employ small talk, or provide a dynamic greeting. Your instructions can also function as entity detection.

## General guidelines {#va-llm-instruction-guidelines__section_jfj_q5z_kbc}

When constructing an LLM description or instruction, consider these basic guidelines.

* Lead with action verbs. Use the imperative form or direct commands.
* Users should avoid answering a question with a question.For example, if the LLM asks What is your question?, the user response <kbd class="ph userinput">Who is on call today?</kbd> can confuse the LLM.
  Instead, the user should enter <kbd class="ph userinput">Tell me who is on call today.</kbd>

* Avoid references to third parties or pronouns. Removing the subject or any identifiers generally prevents the LLM from personifying or otherwise misidentifying the end user.
* Your words instruct the logic that your bot will use. Detailed, chain-of-thought instructions work well for this.
* Continually test and refine your instructions. Creating strong LLM instructions is an iterative process.
{#va-llm-instruction-guidelines__ul_tcg_mvz_kbc}

## Don't use NLU utterances as LLM descriptions {#va-llm-instruction-guidelines__section_tsd_t4x_hcc}

NLU utterances are more dependent on keywords and their phrasing, but LLM descriptions work very differently. The problem with NLU utterances in descriptions is that they don't provide instructions for the LLM. Google search
descriptions won't work well with LLMs, either. When writing descriptions, you need to be specific about the purpose of the topic and the context of the task being performed in that topic. Keywords aren't necessarily helpful, but
logic is.

## Example topic descriptions {#va-llm-instruction-guidelines__section_whc_bxz_kbc}

The following examples describe weak and strong topic descriptions. Stronger topic descriptions result in more accurate topic discovery.  
{#va-llm-instruction-guidelines__table_whq_kyz_kbc__entry__2}

| Strength | Description |
|-|-|
| Weak description | This topic is about a holiday calendar for employees in a company. |
| Strong description | This topic is about a holiday calendar for employees in a company. Users can ask for the holiday list or company holiday for a specific year, specific date, inquire about a specific holiday, or ask if they have a day off for a particular holiday. The topic also covers the availability of a holiday calendar and specific holidays like Freedom Day and wellbeing Day. |
[Table 1. Company holiday calendar topic descriptions]

{#va-llm-instruction-guidelines__table_whq_kyz_kbc}  
{#va-llm-instruction-guidelines__table_u4g_jzz_kbc__entry__2}

| Strength | Description |
|-|-|
| Weak description | This topic is related to the management and administration of Active Directory, a directory service provided by Microsoft. |
| Strong description | This topic is related to the management and administration of Active Directory, a directory service provided by Microsoft. It involves making changes to the Active Directory, such as creating, modifying, or deleting directories and processes. The topic also includes tasks performed by administrators, such as managing user accounts, groups, and permissions within the Active Directory environment. |
[Table 2. Active Directory password change topic descriptions]

{#va-llm-instruction-guidelines__table_u4g_jzz_kbc}

## Example input control instructions {#va-llm-instruction-guidelines__section_hzp_hzz_kbc}

The Node name field should be unique and explain the operation the user is trying to perform, so that the LLM can identify entities and slot-fill properly. For example, if there are two defined input nodes
named <kbd class="ph userinput">AD Operation Type</kbd> and <kbd class="ph userinput">AD Operation</kbd>, there is a chance the LLM could identify the entity and map it to the wrong input node variable. Renaming the nodes to differentiate the two is
best. For example, <kbd class="ph userinput">AD Operation for Password Reset</kbd> and <kbd class="ph userinput">AD Operation for Locked Credentials and Change Password</kbd> are stronger, more unique node names.

The Detail description field for the node should have clear instructions for the possible values that the LLM should extract from the user wherever it is applicable. For example, if the node will perform an
Active Directory operation, then you should be specific about which operations are allowed in the Additional instructions for LLM area. Then the LLM will use the value mapping to identify the entity and fill
the slots.

The following example describes weak and strong input node instructions. The better instructions result improved outcomes.  
{#va-llm-instruction-guidelines__table_n21_pb1_lbc__entry__2}

| Strength | Detail description |
|-|-|
| Weak instruction | Collect AD Operation Type |
| Strong instruction | Collect AD Operation Type Additional instructions for LLM: For this input, these are mapped values, : {"reset":\["reset","locked","unable to sign in","expiry", "expired", "expire"\],"change":\["change"\]}. The key needs to be extracted if the user input contains the values associated with the keys. |
[Table 3. Collect Active Directory operation type input control instructions]

{#va-llm-instruction-guidelines__table_n21_pb1_lbc} Figure 1. Strong detail description example of LLM input node

