Advanced Usage Patterns
Modeling Intent Evaluations
In the previous sections, the various situations where an intent evaluation cycle is executed are discussed in detail (e.g. a new chat message, a new document, etc.)
However, there can be many situations where the intents should be evaluated that don't fit into that category. It could be as simple as triggering it after completing a user task for example, upon receival of an event, when an external service is called, etc.
To do so, the Trigger intent evaluation task can be used for that exact purpose.
This task is available both in CMMN and BPMN and has two non-standard properties:
- Case Instance ID: a reference to the case instance that has an orchestrator agent that will do the intent evaluation. Required for BPMN, optional for CMMN. If not set in CMMN, it will take the current case instance.
- AI Instruction: extra instructions that will be passed into the underlying prompts. This instruction is quite instrumental in setting the right context. For example, for the default operations, the instruction is something like `we just received the following chat message xyz' or 'document with name abc and type def' has has been uploaded. This instruction is an expression, so runtime variables can be used to make it concrete.
Passed Variables
By default, all runtime case instance variables are passed into the underlying operations to provide context for AI services.
In many situations, this is unwanted, as it
- could pass sensitive information to a third party AI service
- expands the token consumption (more costs and potentially hitting the token limit)
To configure which variables are passed into the prompts, the default variable mapping using the allowed/blocked pattern can be configured on the orchestrator agent section of the case plan model:
Previous Exchanges - Memory Size
An orchestrator agent has a setting Number of previous exchanges
, which effectively refers to how many previous exchanges (e.g. previous chat messages) will be passed into the AI services when handling a new request. The more history - often called memory in AI contexts - is passed, the more nuanced the response might become. Of course, the flip side of this is that each passed in previous exchange will consume tokens, leading to highers costs and potentially hitting the token limit of some AI services.
Additional Instructions for Runtime Variables
Variable are passed into the the operations of the orchestrator agent to provide more context. Often, it can be useful to add additional information about these variables, to give more specific context for the variables. This can be done through a data dictionary model that is linked to the case instance.
In the screenshot below, the 'Description (AI)' field, if set, will be passed into the underlying prompts.
Usage of Agent Invocations in Forms and Pages
Agents can also be used in forms and pages, by using the AI Agent Button component.
For example, in the following screenshot a very simple usage is shown where a weather utility agent gets the first text field as output, and binds it to the 3th text field:
This AI Agent Button component currently supports Utility, Knowledge Assistant and External agent type support.