App configurations control behavior across all access methods, customize the Playground experience, and provide advanced options such as error handling.
General Settings
General settings apply across all access methods: Public APIs, Playground, and SDK.
Attachment Configuration
Controls file upload behavior when users share documents during interactions.
Click Modify Configuration to set the following:
| Field | Description |
|---|
| File Limit | Maximum number of files a user can upload. Maximum: 10. |
| Max File Size | Maximum size per file. Maximum: 25 MB. |
| Max Tokens | Maximum combined token size of all uploaded files. Maximum: 800,000 tokens. The Platform uses the lower of this value and 80% of the LLM’s token limit. If this value exceeds the LLM’s capacity, the LLM limit takes precedence. |
See Attachment Support in User Interactions.
Thought Streaming
Allows you to customize the prompt used for thought streaming. Click Modify Prompt and enter the prompt for the LLM.
Waiting Experience
Configures user engagement during processing delays in voice interactions. When enabled, filler messages play automatically while the system processes a response and stop when output is ready.
This feature only works in ASR/TTS streaming mode. Real-time models are not supported.
Click Modify Configuration to set the following:
| Field | Description |
|---|
| Initial Delay | Time (in milliseconds) before the first message plays. Range: 100–60,000 ms. |
| Interval Duration | Time gap (in milliseconds) between subsequent messages. |
| Maximum Message Count | Maximum number of filler messages per wait period. Range: 1–20. |
| Waiting Experience Style | Static Messages — Predefined messages played in random order. Add multiple messages using Add Message. Dynamic Messages — AI-generated messages for a more natural experience (additional LLM costs apply). |
Dynamic Messages configuration:
| Field | Description |
|---|
| AI Model | Model used to generate filler messages. |
| AI Model Timeout | Maximum wait time (in seconds) for the model to respond. |
| Filler Message Prompt | Prompt used by the LLM to generate messages. |
| Context Window Limit | Number of messages retained in session context for generating dynamic messages. |
Playground Settings
The following settings apply only to the Playground.
| Setting | Description |
|---|
| Document Upload | Allows users to upload documents in the Playground. Attachment Configuration settings apply. See Attachment Support in User Interactions. |
| Thought Streaming | Displays the LLM’s intermediate reasoning steps as it generates a response. |
| Streaming | Streams the response in real time so users see output as it’s generated. |
Advanced Settings
Error Handling
Agent Platform provides an error-handling framework that defines how the system responds when an agent’s underlying AI model requests fail or guardrail violations occur. Administrators can configure timeouts, retries, fallback models, and fallback behaviors to ensure predictable and graceful user experiences even when model calls fail or are delayed.
All agents within the app inherit these configurations.
Model Errors
These configurations apply to agent model invocation failures such as timeouts, provider errors, or transient network issues.
Model Call Timeout
Defines the maximum time (in seconds) the system waits for a model response before marking the call as failed. If the model does not respond within the configured timeout, the call is treated as failed and the retry mechanism is triggered.
Retry Handling
Defines how the system behaves when a model call times out. Two options are available:
| Option | Description |
|---|
| Retry with the same model | Retries the request with the same AI model. Use the UPTO field to configure the maximum number of retries. Useful for handling transient provider or network issues. |
| Retry with a different model | Retries the failed request with an alternate AI model after all same-model retries are exhausted. Select the alternate model from the dropdown and specify the maximum retry count. Select Do not retry with a different model to skip this step. |
Fallback Behavior
Defines what happens when the model request fails after all retry attempts have been exhausted.
Fallback Action
Specifies whether the system should trigger an automated recovery step. Available actions:
- None — No automated action is taken.
- Invoke an event — Executes a configured event. Options: Agent Handoff or the End of Conversation event.
- Invoke a tool — Executes a selected code tool or workflow tool. Provide the tool parameters using either fixed key–value pairs or memory variables for dynamic runtime values.
Common use cases for invoking a tool:
- Triggering a notification or email
- Logging failure details
- Initiating a fallback recovery workflow
- Informing support systems when repeated model calls fail
Fallback Message
Controls the message shown to end users when all retry attempts fail:
- Send Message — Displays a custom message describing the issue and next steps.
- Do not send a message — No message is shown.
Guardrail Errors
Use this section to configure handling for guardrail violations such as safety, policy, or validation failures. These settings define how the system behaves when a guardrail check fails, times out, or detects a policy breach.
Key points:
- Guardrail failure and guardrail breach are handled separately.
- Retry settings apply only to guardrail call failures, not breaches.
- Fallback actions run after retries are exhausted.
Guardrail handling is evaluated in two scenarios:
- The guardrail call fails or times out
- The guardrail detects a policy breach
If Guardrail Call Fails
Timeout Configuration
Specifies how long (in seconds) the system waits for the guardrail response before marking the call as failed. If the guardrail responds within this period, normal execution continues; otherwise, retry handling begins.
Retry Handling
Defines how the system retries when a guardrail call fails or times out. The system retries the guardrail call up to the configured count.
- If a retry succeeds, normal flow resumes.
- If all retries fail, fallback behavior executes.
Fallback Behavior
Executed when the guardrail call fails after all retries.
Fallback Action — Specifies the action to trigger, such as running a remediation workflow, logging an incident, or initiating an alert. Available actions:
- None — No additional action is taken.
- Invoke an event — Executes Agent Handoff or End of Conversation event.
- Invoke a tool — Executes a configured tool. Assign static values to parameters or provide dynamic values using memory variables.
Fallback Message — Controls the message displayed to users after a guardrail call fails. A custom message can be configured.
If Guardrail Is Breached
Defines behavior when the guardrail successfully evaluates a request and detects a policy violation.
Breach Handling
Triggered when user input or model output violates configured safety or policy rules.
Fallback Action — Specifies the automated step to execute when a breach is detected, such as compliance logging, security alerts, or running moderation workflows. Available actions:
- None — No additional automation.
- Invoke an event or tool — Executes a defined failure event or workflow tool.
Fallback Message — Defines the message shown to the user when a guardrail breach occurs.
Delete Agentic App
Permanently deletes the Agentic App and all associated data. This action cannot be undone.