Bots

Connecting to external AI services to act as Virtual User in Nimbus

Bots in Nimbus are leveraging external AI services to act as Virtual User in Nimbus. A bot can fulfill specific tasks, such as:

  • Answering specific customer questions
  • Handling customer requests and service transfer tasks
  • Looking up specific data for customer verification or identification

The type of your bot determines the underlying LLM and comes with specific advantages and limitations. More information on this can be found below.

 

Configuring Bots

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:

Field Description
Name Name of the Bot, as it appears in Nimbus lists and selections.
Organization Unit

Determines where the Bot will be available for selection within Nimbus UIs. 

Note: Shared bot resource utilization

💡Sharing your bot: You can design a bot as “general purpose”, making its configuration widely available on a high-level OU. This allows multiple services and their their Virtual Users to re-use this bot configuration and underlying APIs.


☝ Before sharing, keep in mind:

  • Each service that accesses this bot and associated APIs may cause additional cost depending on the model chosen1 
  • Configuration changes to a (generally) shared bot may impact your existing services immediately. → Check the “Used in Virtual User” column in the bot listing to identify affected services.
  • Keep in mind that wide-purpose bot access to resources and capabilities may also result in too much data being disclosed to the customer (e.g. by changed capabilities, instructions, topic covered, attached sources, permissions, etc.). 
  • The actual bot instructions, web requests and MCP Server capabilities orchestrated within the Nimbus Virtual User configuration. Keep in mind to explicitly give 
 
Type1

The type of your Bot. Directly affects the underlying API, LLM and capabilities. Refer to the following table for details:

INC Language model comparison matrix

Type Primary Use Case Limitations Integration Effort
Nimbus AI Services – Audio Intent Analyzer Low latency, conversational AI, real-time audio stream. The bot is communicating directly with the user. Used to detect the intent of a caller and to return the selection done for intelligent routing and IVR replacement.
  • Specialized for providing intent analysis. 
  • Uses Nimbus-native AI Model with fixed-purpose instruction set.
  • Limited parameter sets for data storage.

Low – Easy to use, configuration effort stays within Nimbus. Parametrization is done in workflows as part of the “Virtual User” activity.

 

🔎 See: Use Case - Setting up a Nimbus  Virtual User for Intent Analysis 

Nimbus AI Services - AI Workflow Low latency, conversational AI, real-time audio stream. Used as speech‑in / speech‑out conversational AI with interactions specific to data requests from external systems (e.g. banking or insurance services, ticketing platforms and CRM systems).
  • Flexible, but depends on external system uptime and responsiveness for seamless customer interaction.
  • Requires purpose-driven prompt knowledge and context for all parameters to handle conversation effectively.

Medium - Requires knowledge to handle Web Requests and MCP servers. 

Customers can use Nimbus-native AI models, but must ensure that the web requests and required data is sufficiently covered with the AI prompts.

 

🔎 See: Use Case - Integrating Nimbus Virtual User with external systems 

M365 Copilot – Direct Line 3.0 Enterprise voice interactions with Microsoft 365 Copilot, enabling conversation storage, transcription and intent detection of spoken conversations. Grounded in O365 work data.
  • For generalized use (e.g. data lookup, topics handling) and customer intent detection.
  • Higher latency due to Speech-to-Text and Text-to-Speech generation.
  • Subject to Microsoft licensing and service capacity limits.

Medium – Requires Microsoft 365 and Copilot ecosystem knowledge. Requires configuration within Nimbus, plus integration with Azure Copilot Studio API to handle topics.


🔎 See: Use Case - Setting up a Nimbus Virtual User using Copilot 

Azure OpenAI – Audio GPT Realtime1 Low latency, conversational AI, real-time audio stream. Used as speech‑in / speech‑out conversational AI. Allows admins “bring their own” LLMs and data instances to implement intent analysis.
  • Flexible, but requires customers to bring their own bot configuration.
  • Needs custom client and backend integration, with regional availability determined by Microsoft1.
  • Limited to intent analysis purposes for now, a new bot type will be introduced for wider range of use cases

High –  Requires configuration within Nimbus also requires customers to bring their own LLM and 3rd party integrations.

 

🔎 See: Use Case - Setting up a Nimbus Virtual User using OpenAI GPT Realtime 

Comparison: Types of Bots for Nimbus Virtual Users

Notes

1 Due to Microsoft Azure AI Foundry GPT-Realtime availability in limited regions, data processed by Nimbus Virtual User GPT-Realtime integration will temporarily leave your regional boundary: 

  • DE01, DE02, CH01, CH02, UK01, EU01, AU01 computation will be primarily performed in Sweden Central region.
  • US01 cluster computation will be primarily performed in the US East region.
 

 

✅ The following fields are shown only when your selected Bot Type is a non-Nimbus native AI service, e.g.:

  • Azure OpenAI - Audio GPT Realtime
  • M365 CoPilot Direct Line 3.0

… either requiring an API Key and Endpoint. 

💡 Also note: 

 
Field Description
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

Copilot Endpoints

Copilot - Direct Line API Endpoints

General1 https://directline.Botframework.com/v3/directline/conversations 
Europe https://europe.directline.botframework.com/v3/directline/conversations/ 
Microsoft Copilot Directline API Authentication 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.

 
 
 

OpenAI Audio GPT Realtime

If you bring your own Audio GPT model, please note that currently only “Azure OpenAI Realtime” is supported by Nimbus. → See documentation below.

OpenAI Endpoints

Customers have to set up their own model within Azure foundry. This providers Target URI (Endpoint) and API Key.

 
 

INC Azure Billing Cognitive Services

Disclaimer: Support for Azure Billing & Cognitive Services 

☝ The usage of Microsoft Azure AI Services for Speech1 and AI will cause additional costs outside your Nimbus subscription, which are exclusively determined by Microsoft.

Please note: 

  • Nimbus Support does not cover pricing discussions or make recommendations on Microsoft Azure Services. → Please inform yourself via the references below on pricing models.
  • Nimbus Support can not provide any technical help, insights or solutions on Azure Cognitive Service related technical problems.

1 Azure Speech Services: https://azure.microsoft.com/en-us/pricing/details/cognitive-services/speech-services/

2 Generative AI Services (Copilot Studio):

 

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.
  • Outbound Call via Workflow: Virtual Users are supported in Outbound Call with Workflows. While all Virtual Users are planned to be fully supported by Outbound Workflows, a prior “Announcement” workflow element is required before the “Add Virtual User” to give the AI sufficient spin-up time. Nimbus preview program users can already test their scenarios. As testing and development on Bots compatibility is still ongoing, not all features may work as intended yet.
 
 

Microsoft Copilot Limitations

  • Expect processing delays: Processing AI answers takes a few seconds for voice-to-text-transcription, followed by AI processing and a 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 a 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 use healthcare|medical|emergency as identifiers or use more complex Regular Expressions to identify replies.
 
 

Nimbus AI Services -  Audio Intent Analyzer

🔎By design (not a limitation or reportable issue): 

  • Fallback handling: If a workflow uses exits with multiple parameters, e.g. to collect customer name and invoice number, and only one parameter can be retrieved, the fallback exit is taken.
 
 

Nimbus AI Services - AI Workflow

☝First Web Requests implementation - planned to be improved: 

  • The “Description” field in the Web Requests itself is used to explain to the AI what the web request does. 
  • The Web Request itself can be identified via name, using the "Flow Description" field located in the Virtual Users > Extensions > Web Request section.

🔎By design (not a limitation or reportable issue):

  • Fallback handling: If a workflow uses exits with multiple parameters, e.g. to collect customer name and invoice number, and only one parameter can be retrieved, the fallback exit is taken.
  • Failed Web Request / MCP fallback: If either a Web Request fails or a connection to an MCP server fails to connect, the with the Fallback exit accordingly. Any (optionally user-specified) “Fallback” parameters will be updated with the response generated by the AI.
 
 

Azure Open AI - Open GPT Realtime limitations

☝ This feature is not yet ready for productive use and only enabled for selected customers. We will make further adjustments and update Use Case - Setting up a Nimbus Virtual User using OpenAI GPT Realtime accordingly in an upcoming Nimbus release.

 
 
 

Table of Contents