Each playbook should have one or more examples. These examples are sample conversations between an end-user and the playbook, including the dialogue and actions performed by the agent. These are effectively few-shot prompt examples for the LLM.
The console provides an interface for you to enter actions.
Multilingual agents
If your agent handles multiple languages, use each of the languages in your examples.
Example input and output summaries
In addition to input and output parameters, playbooks support receiving an input summary and emitting an output summary for exchanging information with other playbooks. Summaries are helpful for passing abstract contextual information between playbooks, while parameters are more helpful for passing structured, well-defined fields between playbooks. Parameters are the only way to exchange data between flows and playbooks.
Add relevant input summaries to examples to help the playbook adjust its actions based on those input summaries at runtime. Add output summaries that include relevant and accurate details about the example conversation to show the playbook what details are important to summarize.
Example state
At a given point in the conversation, a playbook is in one of the following states:
OK: The playbook successfully achieved its goal and control transfers to the parent playbook.CANCELLED: The user decides not to proceed with the goal assigned to the playbook and control transfers to the parent playbook. If the parent playbook is a CX flow, Dialogflow CX detects the user input intent before the flow runs.FAILED: The playbook can't proceed with the goal due to an error (for example, a tool returns a 500 error). The session ends with status fail. An EndInteraction message is added to the response.ESCALATED: The playbook decides that it can't achieve the goal and needs to escalate the situation to a human. The session ends with status escalated. An EndInteraction message is added to the response.PENDING: The conversation continues within the playbook.
You should denote the top-level example and its playbook invocations with a state that corresponds to the playbook they reference.
Selection strategy
The selection strategy setting controls whether an example is included in the prompt sent to the LLM for the playbook.
The following options are available:
- Dynamically select: The example is conditionally included based on how relevant it is for the current conversation context. You can omit the example if the prompt approaches the token limit.
- Always select: The example is always included, regardless of the conversation context. You can omit the example if the prompt approaches the token limit.
- Never select: The example isn't included in the prompt. The example has no effect on the playbook's performance. This setting is useful for temporarily excluding an example for testing.
Add action
An example provided within a playbook contains a series of actions. These actions can vary in combination, but they primarily depict the interaction between you and the playbook, along with the actions taken in between to fulfill your query or requirements.
You can add actions to an example in two ways:
- 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. 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 playbook instructions, enter user input in the Enter user input field at the bottom of the right pane. Use this option when you create or edit an example. Alternatively, use this option when you test your playbook at runtime in the Preview playbook pane on the right. To save actions to an example from the Preview playbook pane, click Save example after selecting the playbook invocation from the invocation list on the left of the Preview playbook pane.
Check the correctness of the automatically generated actions and edit them if necessary. This is especially important for playbooks with few or no examples.
The playbook supports the following types of actions.
Playbook response
Provides the playbook response to the user query.
User input
Enter the user query.
Tool use
Get additional information needed to fulfill the user's query by using a tool invocation.
This action specifies the following details:
- Tool: Name of the tool that you must invoke.
- Action: Name of the operation for the OpenAPI tool that you must invoke. For data store tools and function tools, the action name is the same as the tool name.
Tool input: Inputs to include in the tool call. These inputs are usually derived from previous conversation turns with the user.
For OpenAPI tools,
requestBodyJSON is required forPOST,PUT, andPATCHmethod types.Sample OpenAPI tool
requestBodyinput for createPet action:{ "id": 1, "name": "Luna" }For the data store tool, the sample
requestBodyshows where the query is required and other fields are optional:{ "query": "Where is my nearest store?", "filter": "country: ANY(\"United States\")", "userMetadata": { "userCity": "San Francisco", }, "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 OpenAPI tools, it can also be a string error (for example, "404 Not found").
Sample OpenAPI tool output for listPets action:
{ "pets": [ { "id": 1, "name": "Luna" }, { "id": 2, "name": "Charlie" }] }Sample data store tool output for query "Where is my nearest store?":
{ "answer": "Here's the address to your nearest store ...", "snippets": [ { "title": "San Francisco Downtown", "uri": "https://www.example.com/San_Francisco_Downtown", "text": "Address for San Francisco Downtown .." } ] }
To help ensure the playbook is fail-safe, include examples of how the playbook
responds when tool invocation fails. You can represent the
OpenAPI tool invocation
failure as an error string ("404 not found") in the tool output. For
data store tools, you can
use the fallback input to specify how to respond if there's no summarized
answer.
If you want your data store tool to include a URI in the playbook response, add examples that contain the URI you want the playbook to respond with. If this URI comes from the data store tool, then the data store tool output must contain a URI that matches the URI in the playbook response.
Examples containing tool use actions can get quite verbose and increase input token limit consumption. To use tokens efficiently, make sure that tool outputs are concise and contain information relevant to the playbook's goals. For data store tools, consider removing snippets from examples because they cause high input token consumption.
Playbook invocation
Use this action when the playbook needs to invoke another task playbook to fulfill the user query.
Specify the following details for this action:
- Playbook: Name of the playbook to be invoked.
- Playbook invocation input summary: A summary of the relevant portions of the preceding conversation that are useful to the invoked playbook.
- Input parameters: Input parameters to pass to the playbook.
- Playbook invocation output summary: A summary of what the playbook should generate upon completion of its goal.
- Output parameters: Output parameters generated by the playbook upon completion of its goal.
Playbook transition
A playbook transition action is a terminal action that shouldn't be followed by other actions, indicating that the routine playbook has decided to exit and transition to a target routine playbook. Because this action indicates that the playbook exits, add the playbook's output parameters to the example's playbook output.
Flow invocation
This action is used when the task playbook should invoke a flow.
This action should specify the following details:
- Flow: Name of the flow to be invoked.
- Flow input parameters: Input parameters to pass to the flow.
- Flow return parameters: Output parameters returned from the flow.
Flow transition
A flow transition action is a terminal action that shouldn't be followed by other actions, indicating that the routine playbook has decided to exit and transition to a target flow. Because this action indicates that the playbook exits, add the playbook's output parameters to the example's playbook output.