Agentic App Configurations¶

Use the following parameters to control your application's behavior.

General Settings: These are the core settings of the Agentic App. These settings apply to the application across all access methods (Public APIs, Playground, SDK).

Playground Settings: These settings are specific to the Playground and allow you to configure the simulation experience during testing and prototyping.

Advanced Settings: Use these to fine-tune your Agentic app with advanced configuration options.

General Settings¶

Attachment Configuration¶

This configuration is used when users upload documents during interactions as contextual data. Click on Modify Configuration to configure the following file upload restrictions.

File Limit: Maximum number of files a user can upload. This can take a maximum value of 10.
Max File Size: Maximum size of each file, up to 25 MB.
Max Tokens: Specifies the maximum combined size of all uploaded files, measured in tokens. This value can be set up to 800,000 tokens. If the total token size of all files exceeds this threshold, files may be partially processed.

Note: This limit is also constrained by the token limit of the underlying LLM. The platform uses the lower value between the specified Max Tokens and 80% of the LLM’s maximum token limit. If the specified Max Tokens exceeds the LLM’s capacity, the LLM limit takes precedence, and this value is ignored.

Learn more about Attachment Support in User Interactions.

Thought Streaming¶

This field allows updating the prompt used for Thought Streaming. Click Modify Prompt, then provide the prompt for the LLM.

Waiting Experience¶

This feature allows you to configure how users are engaged during processing delays in voice interactions. Setting up appropriate wait-time interactions helps create a smoother and more human-like experience for users while they wait. The waiting experience begins automatically when a processing delay is detected and stops once the system response or the following action is available. Enable this feature to configure.

Note

This feature only works in ASR/TTS streaming mode. It doesn't support real-time models.

Waiting Experience Configuration

Initial Delay: The time (in milliseconds) before the first message is played. This can take any value between 100 and 60,000 ms.
Interval Duration: The time gap (in milliseconds) between subsequent waiting messages.
Maximum Message Count: Maximum number of filler messages to play during a single wait period. This can take any value between 1 and 20.
Waiting Experience Style:
- Static Messages: Use predefined messages that play during wait times in the response. Use the Add Message option to include multiple messages. Messages are displayed in random order during each waiting period.
- Dynamic Messages: Use AI-generated messages to make interactions more natural and personalized. Note that using dynamic messages incurs additional LLM costs. Provide the following configurations for dynamic messages.
  - AI Model - Select an AI model optimized for the agent’s specifications to ensure accurate and efficient task handling.
  - AI Model Timeout -The maximum duration (in seconds) to wait for an AI model’s response.
  - Filler Message Prompt - Configure the prompt used by the LLM to generate custom messages to be presented during wait periods.
  - Context Window Limit - The maximum number of messages retained in the session context. Once the limit is reached, older messages are automatically removed to manage memory and context size. The AI model uses this context to generate dynamic messages.

Playground Settings¶

The following configurations are only applicable to the Playground.

Document Upload¶

Enable this option to allow users to upload documents during interactions in the Playground. These documents are used as contextual data during the conversation. When enabled, the Attachment Configuration settings are applied to the uploaded documents.

For more information, see Attachment Support in User Interactions.

Thought Streaming¶

Enable this feature to view the sequence of intermediate reasoning steps or thoughts generated by the LLM while generating a response. This helps in understanding how the model arrives at its conclusions.

Streaming¶

Enable this setting to allow real-time streaming of the response in Playground, so users can see the 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 happen. It allows administrators to configure timeouts, retries, fallback models, and fallback behaviors so that user experiences remain predictable and graceful even when model calls fail or are delayed.

All agents within the app inherit these configurations.

Model Errors¶

These configurations apply specifically 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 model call as failed. If the model doesn't respond within the configured timeout, the call is treated as failed, and the retry mechanism kicks in.

Retry Handling: Defines how the system behaves when a model call times out. There are two options to follow in this situation.

Retry with the same model: When enabled, the system will retry the request with the same AI model. Configure the maximum number of retries using the UPTO field. This can be used to handle transient provider issues or network issues, giving the primary model a few attempts before switching to a backup model.
Retry with a different model: When enabled, the system will retry the failed request with an alternate AI model after all retries with the first option have been exhausted. Select the alternate model from the drop-down, and specify the maximum number of retries for this model. To skip this step, select Do not retry with a different model. This can be used to maintain continuity if the primary model is temporarily unavailable.

Fallback Behavior: This config defines what happens when the model request fails after all retry attempts (if any) have been exhausted.

Fallback Action: Specifies whether the system should trigger an automated recovery step. It can take the following actions.
- None - No automated action is taken.
- Invoke an event: Executes the configured event. You can select Agent Handoff or the end-of-conversation event.
- Invoke a tool: Executes the selected code tool or workflow tool. Select the tool and provide the tool parameters. Administrators can provide fixed key–value pairs for the tool parameters or use memory variables to dynamically populate values at runtime. This is useful for actions such as:
  - 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: Display a custom message to the user that describes the issue and the next steps.
- Do not send a message: No message is shown.

Guardrail Errors Tab¶

Use this tab to configure handling for guardrail violations (such as safety, policy, or validation failures). Configure how the system behaves when a guardrail check fails, times out, or detects a policy breach. These settings help maintain safety while ensuring a good user experience.

Points to Note¶

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.
Proper configuration improves both safety and user experience.

Guardrail handling is evaluated in two scenarios:

Guardrail call fails or times out
Guardrail detects a policy breach

If Guardrails Call Fails¶

Configure the following to handle cases when the 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 time 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 Behaviour: Executed when the guardrail call fails even after all retries.

Fallback Action: Specifies the action to trigger as a fallback, like running a remediation workflow, logging an incident, or initiating an alert operation. Configure one of the following 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. Select the tool and provide the required tool parameters. You can 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. You can display a custom message.

If Guardrail Is Breached¶

The following fields define the behavior when the guardrail successfully evaluates the 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.

None - No additional automation.
Invoke 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¶

Use this to permanently delete the Agentic App and all associated data.

Send Feedback