In this Use Case we're setting up a Virtual User that reaches out to your external systems mid-conversation — looking up customer or order data, querying ticket systems, or using any other APIs the bot needs to do its job. The Virtual User uses Nimbus' AI Workflow profile together with Extension Tools: Web Requests for any HTTP API, and MCP Servers for tool collections that speak the Model Context Protocol.

To achieve this, we're going to cover the following topics in this Use Case: 

• How to configure the Bot and Virtual User on the AI Workflow profile.
• How to write a Flow Description — the playbook that tells the model when to call a tool, which one to pick, and what to do with the result.
• How to attach Web Requests and MCP Servers as Extension Tools, and how to describe them to the model.
• How to wire the Virtual User into a Nimbus Workflow, including the default exits.

Preconditions

Use Case Overview

Details will be covered below in this Use Case. As a quick tl;dr, here is an overview of items you will need: 

Step 1 - Nimbus AI Bot Setup

Configuring the Bot

✅ The Bot is your “mapping” to the AI service that hosts the conversation.

1. Head to Nimbus Administration > Configuration > Bots and create a new Bot.
2. Give your Bot a descriptive name. 
   💡This name is just for Nimbus UI purposes.
3. Define the Organization Unit under which this Bot will be selectable. 
4. Type: pick Nimbus AI Service for the Luware-managed option (no endpoint or API key required), or Custom AI Service if you bring your own Azure OpenAI deployment.
5. Agent Type is Azure OpenAI — the only agent technology that supports Web Requests and MCP Servers.
   💡If you picked Custom AI Service, fill in the Endpoint, Authentication Type and API Key fields. For Nimbus AI Service those fields are hidden — Nimbus provides them.
6. Save and Close.

Configuring the Virtual User

✅ Virtual Users. Here you give your AI bot instructions on how to interact with the Customer and which Extension Tools it may use.

1. Head to Nimbus Administration > Configuration > Virtual Users and create a new Virtual User.
2. Give your Virtual User a descriptive name, e.g. Order Status Concierge.
   💡This name is just for Nimbus UI purposes, e.g. for later selection in your Workflows.
3. Define the Organization Unit under which this Virtual User is selectable. 
   💡Should ideally match the Services and Workflows accessing this Virtual User, and the OU where your Web Requests live.
4. Select the Bot you configured above.
5. Set Profile to AI Workflow.
   💡The Profile decides how the bot behaves in the conversation. AI Workflow unlocks the Extension Tools section further down the page (Web Requests, MCP Servers, Flow Description). The Intent Analyzer profile is intentionally blocked from using Extension Tools — pick it only for pure intent classification (see the Intent Analysis use case).
6. The “System Instructions” field is your behavioral guideline (persona, hard rules, flow order). Keep it about who the bot is, not about which tool to call — the latter goes into the Flow Description below.
7. Optionally define the Conversation Messages:
   💡Note that this field is optional in Nimbus: The underlying AI will engage with the Customer automatically. Optionally you can use these instructions to go directly into the first Conversation Topic. By adding Custom Parameters or System Fields and Parameters (retrieved via CRM using Flow Actions) you can also lead directly into a more direct conversation. 
8. Optionally set a Closing Message — a short line the Virtual User will say before handing off or disconnecting (e.g. “Thank you, I'll transfer you to a colleague now.”).
9. Define the Language and Voice of your Virtual User.
   💡Nimbus development aims to expand this list of supported languages gradually, ensuring that every User Voice is also compatible with each Language selected.
10. If you want to use your Virtual User productively, ensure your Virtual User has a license applied. This license can be applied directly in the Virtual User configuration or — in bulk — via Admin > Licensing view.
    ⮑ Applying the license enables usage of the “Add Virtual User” Workflow Activity.

Step 2 - Configuring your Extension Tools

✅This is the heart of the integration: deciding which external systems the Virtual User may reach into, describing them well enough for the model to pick the right one, and writing the Flow Description that orchestrates the whole conversation.

Flow Description

The Flow Description is a single free-text field on the Virtual User that tells the model how to drive the conversation when Extension Tools are involved. The model reads it alongside the System Instruction every turn and uses it to decide when to call a tool, which tool to pick, and what to do with the result.

💡 Keep it concrete and step-driven. The model performs best when it can read the description as a numbered playbook rather than as prose:

• Spell out the conversation phases (greet → identify → look up → confirm → close).
• Name each tool by the exact label it has on the Virtual User — “call the OrderLookup Web Request”, not “call the order system”.
• State when the bot should call a tool, and what to do if the tool fails or returns nothing.
• Avoid duplicating the System Instruction (role, tone, language). The Flow Description is about flow, not personality.
• Field length cap: 5,000 characters.

Example for an order-status bot:

1. Greet the caller and ask for their order number.
2. Call the OrderLookup Web Request with the order number the caller provided.
3. If OrderLookup returns a result, read back the order status and the expected delivery date.
4. If OrderLookup returns no result or an error, apologise, offer to transfer to a human agent,
   and end the conversation.
5. After confirming the status, ask whether there is anything else. If not, say goodbye and close.

Never invent an order status. Only state what OrderLookup returns.

Attaching Web Requests

✅A Web Request attaches a (previously) configured Web Request to the Virtual User so the model can call it mid-conversation.

1. Enable “Web Requests” on the Virtual User. This unlocks the Web Requests sub-section.
2. Click Create and pick a Web Request from the Virtual User's Organization Unit (or a parent OU). The Web Request's Name is what the model sees as the tool's identifier — use the same name in your Flow Description.
   1. Fill in the AI Description for this binding. This is a per-Virtual-User field — the same Web Request can have a different AI Description on every Virtual User it is bound to.
      💡A vague AI Description is the single most common reason for a bot to ignore a tool it is allowed to use.

Attaching MCP Servers

An MCP Server attaches a Model Context Protocol endpoint to the Virtual User. The server's tools are exposed to the model in real time during the call.

1. Enable “MCP Servers” on the Virtual User. At least one MCP Server is required when the toggle is on.
2. Click “Create” and fill in: 
   1. Name of the MCP Server
   2. URL
   3. Description
   4. Authentication
   5. API key

Step 3 - Configuring your Nimbus Workflow

✅Last but not least you need to configure a new Workflows to handle the Audio/Video interaction between Customers and your new Virtual User.

1. Head to Nimbus Administration > Configuration > Workflows.
2. Design or adjust any existing workflows you want to repurpose. 
   💡We recommend creating a copy of an existing Workflow so you can switch and test it with ease and return back should something not work as intended.
3. In your Workflow, Accept a call as normally. 
   💡Important: Do NOT add a “Queue” activity unless you want to involve human interaction in your workflow as well (e.g. after the Virtual User interaction).
4. Connect your Caller to the AI by using the “Add Virtual User” activity. You can find it in the Conversation Handling Activities. 
5. Configure the “Add Virtual User” activity as follows:
   1. Virtual User: Select the Virtual User you configured above.
      💡Note that the Virtual User will greet the Customer with the “Initial Message” field instructions provided. If any Parameters have been retrieved earlier in the workflow, they will be part of that message as well.
      💡Outbound calls: when the “Add Virtual User” activity runs inside an outbound-call workflow, the Initial Message is spoken once the call connects — no extra silence before the greeting.
   2. Max Input Timeout: Define this to a reasonable time where no answer has been given by the Customer — e.g. 1 minute. → The activity will take the “Idle Timeout” exit.
   3. Define a Fallback Parameter which receives the AI's summary of the conversation when the bot cannot resolve the request.
      💡A good way to route this exit is a regular “Queue” step, so a human can take the call instead of the Virtual User. 
      💡The Parameter can also be shown in the Extensions Service Settings (e.g. within My Sessions) as additional context for the receiving service user.
6. Route the default exits of the activity.
7. Finally: add the “Disconnect” activity at the end and Save your workflow.

Known Limitations