A Bot is the connection between Nimbus and the AI service that drives a Virtual User. The Bot holds the reference to the service, the agent technology and — for customer-provided services — the endpoint and credentials.
INC Preview Feature
This feature is in PREVIEW and may not yet be available to all customers. Functionality, scope and design may change considerably.
✅Please note that Bots only work in conjunction with Virtual Users, so the same preconditions apply.
INC AI and Virtual User Preconditions
PRECONDITIONS: AI Features, Bots and Virtual Users
Admin Consent: AI Features
✅ Nimbus Tenant Admin consent is required to enable the use of AI features. This is done in the Data Privacy Tenant Settings. AI use will require your Tenant data (e.g. caller information) to be processed by external services
💡Good to know - shared setup effort: Once consent is granted, both Admin Roles “Tenant Admins” and “OU Admins” are able to create various AI Configuration items in the Nimbus Admin Portal. This also includes:
- Access to Service Distribution Settings, e.g. to test workflows with your configured Virtual Users.
- Steer feature visibility via Companion Service Settings (e.g. when activities are supposed to happen unobtrusive in the background).
Virtual User Licensing
✅Nimbus License Management:
-
Contact Center Enterprise Routing service licenses are required to use AI-driven Virtual User functionality.
⮑With the license applied, corresponding Service Features (e.g. workflow activities, configuration tabs) are enabled. -
Individual Virtual User license requirement: Same as regular Nimbus users, each Virtual User requires a separate license. This license can be applied individually in the Virtual User configuration - or in bulk - via Admin > Licensing view.
⮑The license enables usage of the “Add Virtual User” Workflow Activity, without it the activity will be skipped over. For additional Virtual User licenses on your service, get in touch with your Customer Success representative.
Virtual User Bot Configuration
Virtual Users rely on Nimbus Configuration items:
✅ ALL: Virtual Users require Bots to be configured. Your bot choice also determines the underlying AI LLM into which the Nimbus Virtual User integrates. Your bot typ and profile should therefore be chosen with the intended use case in mind.
INC Language model comparison matrix
| Defined in Bots | Defined in Virtual Users | |
|
Type Nimbus managed or BYO |
Agent Type Underlying LLM |
Virtual User Profile Pre-built configurations to fulfill a certain use case |
| Nimbus AI Service | Azure OpenAI1 |
|
|
Custom AI Service
|
|
|
| M365 Copilot Direct Line 3.0 |
|
|
Notes
1 Due to Microsoft Azure AI foundry availability in limited regions, data processed by a Nimbus Virtual User “GPT”-Realtime" integration might temporality leave due to failover scenarios:
- Nimbus Cluster DE01, DE02, CH01, CH02, UK01, EU01, AU01 computation will be primarily performed in Sweden Central region.
- Nimbus Cluster US01 computation will be primarily performed in the US East region.
✅SPECIFIC AI services / Agent technologies (e.g. Microsoft Copilot) may require additional configuration items such as:
- Bot Response Templates, to map bot answers back into Nimbus workflow parameters.
- Speech Recognizers (Transcribers) to convert the Customer voice into text for the bot to process.
🔎For more details and specific configuration steps, refer to our AI Use Cases category and the specific Use Cases and pages linked above.
Configuring Bots
A Bot is described by two co-dependent fields: a Bot / Service Type (who hosts the AI) and an Agent Type (which underlying model or channel the bot uses). The Profile (Intent Analyzer / AI Workflow / Open Profile) is selected on the Virtual User, not on the Bot.
The Bot configuration in Nimbus is built to be as flexible as possible, so common concepts can be re-used. Each Bot configuration consists of the following properties:
| Property | Description | Shown for |
|---|---|---|
| Name | Name of the Bot, as it appears in Nimbus lists and selections. | All Types |
| Organization Unit | Determines where the Bot will be available for selection within Nimbus UIs. | |
| Type |
Decides who hosts the AI. Two values:
☝️ This choice gates the rest of the form: Custom AI Service unlocks Endpoint, Authentication Type and API Key; Nimbus AI Service hides them. The choice also filters the available Agent Type options. |
|
| Agent Type |
Co-dependent on Type. Selects the underlying agent that handles the conversation: For Type = Nimbus AI Service → Azure OpenAI (default)
🔎The Agent Type later determines and filters the Profile / Prompt Preset dropdown on the Virtual Users configuration page. |
|
| Endpoint | The endpoint of the API the bot should use. | ✅With type Custom AI Services selected |
| Authentication Type | Authentication method used to call the endpoint. Today only API Key is available (or unset). Hidden for Nimbus AI Service. | |
| API Key | The API key for your external API access. Required when Authentication Type is set to API Key. Stored securely; never echoed back to the UI after save. |
🔎Note: Shared bot resource utilization
💡A single Bot resource (and underlying API) can be shared across all Virtual Users that reference it. A single Bot can therefore serve multiple Virtual User configurations (e.g. one for Intent Analyzer, one for AI Workflow).
☝️Note that a bot is subject to licensing and rate limits of the underlying AI-service. When utilized by many services, rate limits may be exceeded quickly and a bot may cease operation.
Choosing a Bot type
The Type × Agent Type combination decides which Profile options become available on a Virtual User that references this Bot:
INC Language model comparison matrix
| Defined in Bots | Defined in Virtual Users | |
|
Type Nimbus managed or BYO |
Agent Type Underlying LLM |
Virtual User Profile Pre-built configurations to fulfill a certain use case |
| Nimbus AI Service | Azure OpenAI1 |
|
|
Custom AI Service
|
|
|
| M365 Copilot Direct Line 3.0 |
|
|
Notes
1 Due to Microsoft Azure AI foundry availability in limited regions, data processed by a Nimbus Virtual User “GPT”-Realtime" integration might temporality leave due to failover scenarios:
- Nimbus Cluster DE01, DE02, CH01, CH02, UK01, EU01, AU01 computation will be primarily performed in Sweden Central region.
- Nimbus Cluster US01 computation will be primarily performed in the US East region.
Bot Authentication configuration
✅ The following fields are shown only when your selected Type is a Custom AI service, e.g.:
- Azure OpenAI
- M365 CoPilot Direct Line 3.0
… either requiring an API Key and Endpoint (see below).
💡 Also note:
- Nimbus native AI services do not require further API configuration. The corresponding fields are not shown, you can directly “Create” your bot.
- External APIs require a sign-up and configuration outside of Nimbus. For more details refer to:
| Field | Description | ||||
|---|---|---|---|---|---|
| Authentication Type | API Key (current default) | ||||
| API Key |
The API key for your external API access. 💡The bot uses the authentication to leverage API features. Specific permissions are granted in the 3rd-party UI. |
||||
| Endpoint |
The Endpoint of the API your bot should use. 💡This is the API address where the bot can send Request and get Responses. This depends on what you want the bot to do (e.g., send a message, get weather data, etc.). M365 CoPilot Direct Line 3.0🔎 Documentation: MSFT Key Concepts in Direct Line 3.0 API Copilot EndpointsCopilot - Direct Line API Endpoints
1 ☝A request might fail if you use the global base URI for a regional bot, as some requests could go beyond geographical boundaries. The URLs are maintained by Microsoft and retrieved from the Learn | Direct Line documentation. We advise to test performance and stability. 🧠Don't forget: Note down the endpoint for later use, e.g. for the Bots configuration of your Nimbus Virtual Users. INC Azure Billing Cognitive ServicesDisclaimer: Support for Azure Billing & Cognitive Services☝ The usage of Microsoft Azure AI Services for Speech1 and AI2 will cause additional costs outside your Nimbus subscription, which are exclusively determined by Microsoft. Please note:
1 Azure Speech Services: https://azure.microsoft.com/en-us/pricing/details/cognitive-services/speech-services/ 2 Generative AI Services (Copilot Studio): Azure OpenAIOpenAI EndpointsCustomers have to set up their own model within Azure foundry. This providers Target URI (Endpoint) and API Key. |
Known Limitations
INC AI and Virtual User Limitations
General note on AI-driven interactions
AI driven replies are not deterministic and depend highly on what the Customer is saying. For example, if the Customer is saying “I have trouble with my internet” it is not necessarily given that the Bot will associate “Router, Modem” as your workflow routing exit, unless specifically handled in your Virtual User integration. In this specific example, AI instructions should also cover alternative wordings like “Router, Internet”, to be handled in topics accordingly.
🔎Refer to our Best Practices - Virtual Users in Nimbus for some considerations and risks when using Virtual Users instead of Human interaction.
General Virtual User limitations
The current Nimbus implementation with AI-driven bots underlies the following limitations:
- Supported Modalities: Virtual Users (Bots) are currently available for Audio/Video modality tasks.
- Virtual User Reporting: Sessions involving Virtual Users are not reflected as dedicated User Session. Virtual User session reporting is planned for a later point this year.
Microsoft Copilot Limitations
- Expect processing delays: Processing AI answers takes a few seconds for voice-to-text-transcription, followed by AI processing and then the same transcription back into a voiced response. Luware is trying to minimize the delay on Nimbus call infrastructure, but the dependency on external APIs will always incur this delay. The Customer will hear silence during this processing and no audio feedback / silence detection.
-
Ensure you have no ambiguity in your topics. For instance, the word “
Service” may be too generic if you want to transfer to different services. Rather usehealthcare|medical|emergencyas identifiers or use more complex Regular Expressions to identify replies.
Nimbus AI Services - Profile: Intent Analyzer
🔎By design (not a limitation or reportable issue):
- The Nimbus Intent analyzer Bot runs on pre-defined prompts. Any usage outside of the descriptions specified under Use Case - Setting up a Nimbus Virtual User for Intent Analysis is not supported.
-
Fallback handling: If a workflow uses exits with multiple parameters, e.g. to collect
customer nameandinvoice number, and only one parameter can be retrieved, the fallback exit is taken.
Nimbus / Custom AI Services - Profile: AI Workflow
🔎By design (not a limitation or reportable issue):
- Failed condition: If either a Web Request connection or MCP server connection fails, the “Failed” workflow activity exit will be taken immediately. Also applies for any other Nimbus-internal or technical error.
- Fallback condition: Any “Fallback” parameters will be updated with the response generated by the AI when a case cannot be handled.
☝️Current limitations, coming with a later update:
- For this profile there currently are no custom exits in the “Add Virtual User” Conversation Handling Activity. You only have Success, Fallback, Failed, Idle timeout.
- There is currently no support for custom Parameters in “Add Virtual User” Conversation Handling Activity.
Custom AI Services - Profile: Open Profile
☝️Current limitations, coming with a later update:
- The use of Extensions Tools (either Web Request or MCP Server) is currently mandatory in this profile. 💡This will be improved in a future update to allow for no tools to be used.
- For this profile there currently there are no custom exits in the “Add Virtual User” Conversation Handling Activity. You only have Success, Fallback, Failed, Idle timeout.
- There is currently no support for custom Parameters in “Add Virtual User” Conversation Handling Activity.