Examples

Each agent should have one or more examples. These examples are sample conversations between an end-user and the agent app, including the dialogue and actions performed by the agent app. These are effectively few-shot prompt examples for the LLM.

The console provides an interface for you to enter actions.

Multilingual agent apps

If you want your agent app to handle multiple languages, your examples should use each of the languages.

Example input summary and output summary

In addition to input and output parameters, agents support receiving an input summary and emitting an output summary for exchanging information with other agents. Summaries are helpful for passing abstract contextual information between agents, while parameters are more helpful for passing structured, well defined fields between agents. Parameters are the only way to exchange data between flows and agents.

Add relevant input summaries to examples to condition the agent to adjust its actions based on the input summaries at runtime. Add output summaries including relevant, accurate details about the example conversation to show the agent what details are important to summarize.

Example state

At a given point in the conversation, an agent will be in one of the following states:

OK: The agent successfully achieved its goal and control will now transfer to the parent agent.
CANCELLED: The user decided not to proceed with the goal assigned to the agent. The control will now transfer to the parent agent. If the parent agent is a CX flow, intent of the user input will be detected before the flow runs.
FAILED: The agent cannot proceed with the goal due to some error (e.g. tool returns 500 error). The session will end with status fail. An EndInteraction message will be added to the response.
ESCALATED: The agent decided that it cannot achieve the goal and needs to escalate the situation to a human. The session will end with status escalated. An EndInteraction message will be added to the response.
PENDING: The conversation is still continuing within the agent.

The top-level example and its agent invocations should be denoted with a state which corresponds to the agent they are referencing.

Selection strategy

Selection strategy controls whether or not each example is included in the agent's prompt.

DEFAULT: the example may be omitted if the prompt nears the token limit.
STATIC: the example is always included.
NEVER: the example is never included in the prompt. The example will have no effect whatsoever on the agent's performance.

Add action

An example provided within an agent consists of a series of actions. These actions may vary in their combinations, but they primarily depict the interaction between the user and the agent, along with the actions taken in between to fulfill the user's query or requirements.

There are two ways to add actions to an example:

To add an action manually, click the + button at the bottom of the right pane or the Add action button when you hold the pointer over existing actions. You can use these options when you create a new example by clicking the + Example option or when you edit an existing example.
To generate actions automatically based on the existing agent instructions, enter a user input in the Enter user input field at the bottom of the right pane. You can use this option when you create or edit an example. Alternatively, you can use this option when you test your agent at runtime in the Preview agent pane on the right. To save actions to an example from the Preview agent pane, click Save example after selecting the agent invocation from the invocation list on the left of the Preview agent pane.

Make sure to check the automatically generated actions correctness and edit them if necessary. This is especially important for the agents with few or no examples.

The following types of actions are supported by the agent:

Agent response

The agent response to the user query.

User input

The user query.

Tool use

This is a tool invocation to get additional information needed to fulfill the user's query. This action should specify the following details:

Tool: Name of the tool that should be invoked.
Action: Name of the operation for the OpenAPI tool that should be invoked. For data store tools and function tool, the action name is the same as the tool name.
Tool input: Inputs to be included in the tool call. These are usually derived from the previous conversation turns with the user.

For Open API tools, requestBody JSON is required for POST, PUT and PATCH method types.

Sample Open API tool requestBody input for createPet action:
```
{
  "id": 1,
  "name": "Luna"
}
```
For data store tool, the sample requestBody where the query is required and other fields are optional.
```
{
  "query": "Where is my nearest store?",
  "filter": "country: ANY(\"United States\")",
  "userMetadata": {
    "userCity": "San Fransisco",
  },
  "fallback": "We don't have any stores in your area."
}
```

Tool output: The response of the tool invocation. This is a valid JSON response from the tool to the given input. For Open API tools, it can also be a string error (for example, "404 Not found").

Sample Open API tool output for listPets action:

{
  "pets": [
    {
      "id": 1,
      "name": "Luna"
    },
    {
      "id": 2,
      "name": "Charlie"
    }]
}

Sample Data store tool output:

{
  "answer": "Here's the address to your nearest store ...",
  "snippets": [
    {
      "title": "San Fransisco Downtown",
      "uri": "https://www.example.com/San_Fransisco_Downtown",
      "text": "Address for San Fransisco Downtown .."
    }
  ]
}

To ensure the agent is fail-safe, also include examples of how the agent should respond when tool invocation fails. Open API tool invocation failure can be represented as an error string ("404 not found") in the tool output. For data store tools the fallback input can be used to specify how to respond if there is no summarized answer.

If you want your data store tool to include URI in the agent response, add examples which contain the URI you want the agent to respond with. If this URI is coming from the data store tool, then the data store tool output should contain a URI which matches the URI in the agent response. Note fallback cannot be used in this scenario because it will disable the capability of the LLM agent to rephrase the data store tool answer to include URIs in agent response.

Examples containing tool use actions can get quite verbose and contribute to increased input token limit consumption. To ensure efficient use of tokens, ensure that tool outputs are concise and contain information relevant to the agents goals. For data store tools, consider removing snippets from examples as they can contribute to high input token consumption.

Agent invocation

This action is used when the agent should invoke another agent to fulfill the user query. This action should specify the following details:

Agent: Name of the agent to be invoked.
Agent invocation input summary: A summary of the relevant portions of the preceding conversation useful to the agent being invoked.
Input parameters: Input parameters to pass to the agent
Agent invocation output summary: A summary of what the agent should generate upon completion of its goal.
Output parameters: Output parameters generated by the agent upon completion of its goal.

Instructions

Parameters