---
updatedAt: 2026-01-09T16:49:55.000Z
agentTools:
projectIndex: https://ai-studio-docs.quiq.com/llms.txt
---
# Behaviors
The following behaviors are specific to AI agents.
## Assigned
**Assigned** is a special behavior that executes when a conversation is first assigned to an AI agent. This marks the beginning of the agent's session with that conversation. Flow typically doesn't return to the **Assigned** behavior during the same session (although it's possible to configure it to do this if you wish).
The **Assigned** behavior has a single rule handler where you can configure visual rules and actions, including a required location change to the next behavior in the flow:
If a conversation is unassigned from an agent (e.g. escalated to a live agent) but is later reassigned to the agent, this marks the beginning of a new session that will start from the Assigned behavior again.
## Send Message
The **Send Message** behavior enables you to send a message to the customer and optionally wait for a customer response.
The **Send Message** behavior can actually send multiple messages and even execute other action types. Its defining trait is it's ability to block for a customer response. Messages have full access to Quiq's multi-channel [Rich Messaging Support](https://knowledge.quiq.com/docs/rich-messaging-support-by-channel) support:
The text of the message can include references to various variables, including session fields. This is very useful if you want to send content generated by an LLM through a visually configured message instead of a programmatically generated one. Use a **setField** action to set the text you wish to send to a session field, then reference it as a variable in your message text:
It's also possible to send standard messages defined in the [Message Catalog](https://knowledge.quiq.com/docs/message-catalog).
#### When to use the Send Message Behavior
You've probably noticed that there are several ways to send messages from a customer agent:
* From the **Send Message** behavior
* From a visual **Send Message** action available on many behaviors
* From a programmatically generated **Send Message** action
The choice to use the **Send Message** behavior comes down to wanting to block for a customer response or wanting to elevate the important of a message onto the top-level flow graph.
### Voice Specific Options
When the **AI Agent Voice Enabled** toggle button in the [Voice Configuration](https://ai-studio-docs.quiq.com/docs/configuration-panel#voice-configuration) tab is enabled, Voice appears under the **Add Platform Specific Version** button:
When selected, you can define a range of new Voice-specific options:
1. **Text:** The message to be spoken over Voice
2. **Supplement Voice with another platform:** Whether you want to send a message on SMS, ABC, or WhatsApp to accompany your Voice message.
1. When this option is enabled, you can define a message that gets spoken over Voice, as well as a fallback message to be sent if you cannot text that user for any reason:
2. In the Default tab, you can define the message to be texted to the user:
By default, your Default message will be sent over SMS, please reach out to your account manager if you'd like help configuring a multimodal experience on Apple Messages for Business or WhatsApp.
1. **Follow with thinking sound:** A thinking sound will play until the next message you send without a thinking sound. This can be useful if you're looking up account information, or performing some other task that may take a moment.
2. **Allow messages to be interrupted by user input:** Allows the customer to interrupt while your Agent is speaking. If this is not enabled, the agent will continue speaking the message until it's finished
3. **Set response expectations:** Enables builders to define what type of customer response they will allow for a given Voice message - if this is unchecked both speech and numeric entry will be allowed:
1. **Speech Only**: Will ignore any keyboard input entered by the customer and only respond to speech. Builders can define additional extra wait time.
2. **Numeric Allowed**: Allows customers to input via keyboard or speech. Builders can define a max length, a stop character, as well as define additional wait time.
3. **Numeric Only**: Allows customers to only input via keyboard. Builders can define a max length & a stop character.
## Set Timer
The **Set Timer** behavior enables your agent to perform a timed wait for a customer message and behave differently when the customer responds first vs. when the timer expires:
If the customer responds before the timer expires, the **When the user responds** handler will execute. Otherwise, the **When the timer expires** handler will execute. Along with **Send Message** and **Call API** behaviors, **Set Timer** behaviors are another way to block on user input (i.e. enter a state of rest).
Example use cases:
* Waiting several minutes after answering a question to ask the user if it was helpful or not
* Trying to keep a high-value prospect engaged in the conversation
## Route
The **Route** behavior enables an agent to escalate a conversation to another agent or a live agent queue.
The **Route** behavior has three modalities:
| Mode | Description |
| :--------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Re-Queue | Send the conversation to another queue (typically staffed by live agents) |
| Return to Sender | Send the conversation back to wherever it was prior to getting assigned to the agent. This is helpful for 'backend' agents like post-conversation survey agents as opposed to agent that are a customer's first point of contact |
| Transfer | Transfers the conversation to another agent. For example, your business may have a general agent that determines the customer's issue and then routes to an agent specialized for handling that type of issue |
The **Route** behavior clearly demonstrates the seamless integration between agents and your contact center. When a conversation is escalated or transferred it is completely seamless to the user. All conversation and customer data is preserved because it's all the same conversation record passing through the system.
If you require complex routing logic to decide the routing target, a common pattern is to place an **Execute Logic** behavior in front of numerous **Route** behaviors. It's even possible to reflect on current staffing levels when making escalation decisions:
## Close
The **Close** behavior closes conversations - either immediately or with a delay.
| Mode | Description |
| :-------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Immediate | The conversation will be closed immediately upon reaching the behavior. Customer-scoped data obtained during the session will be propagated to any subsequent conversation, but conversation-scoped data is reset. If the customer returns, the agent will start over at the **Assigned** behavior |
| Delayed | The conversation will be flagged as Inactive and automatically closed after the configured [Close Time](https://knowledge.quiq.com/docs/timers#conversation-close-time) elapses. If a customer responds during this time, the current conversation will continue and conversation-scoped data will be maintained. The delayed close requires a **Change location** action be configured in order to determine how the conversation should be handled if the customer responds |
Note that the **Close** behavior is not the only way conversations can close while assigned to your agent. Quiq's normal inactivity and close timers apply to agents, just like they do to live agents. For example, if you ask the customer a question but they don't respond, the conversation will be automatically inactivated and then automatically closed according to your system [timer configuration](https://knowledge.quiq.com/docs/timers). This is colloquially referred to as dropoff. You don't need to explicitly handle it in your agent flows. Use the **Close** behavior when you have reason to believe the conversation is over.
## Classic Design Elements
Customer agents have full access to Quiq's classic bot design elements including NLU-based intent matching and entity extraction, as well as several behavior types that make it easy to create menu-driven bots and/or fill out forms.
**[Determine Intent](https://knowledge.quiq.com/docs/bot-behaviors#determine-intent):** easily create menu trees with optional NLU-based matching\
**[Gather Data:](https://knowledge.quiq.com/docs/bot-behaviors#gather-data)** prompt the customer to answer questions and bind the data back to fields\
**Collect Data:** Use NLU to collect data entities from the customer\
**[Classic Special Events](https://knowledge.quiq.com/docs/bot-behaviors#special-events)**