Deployments

How to deploy your AI agent as a website chat widget, an internal team chat, or a phone agent. Covers channels, models and failover, access control, widget customization, voice settings, phone numbers, and data residency.

A deployment is how your AI agent reaches the people who talk to it. It connects a configured Agent to a specific channel, gives you channel-specific settings (look and feel, voice, access control), and assigns the AI model that powers that channel.

You manage deployments from an Agent's Deploy tab. All deployments for an agent are listed there, each on its own card. They share the same Agent configuration and Knowledge Base — changes to the system prompt or knowledge base apply to every deployment instantly.

Who can manage deployments

Members cannot see the Deploy tab's deployment controls. Builders can view deployments but cannot change them.

Channels

botts.ai has three live channels today. Three more appear in the channel picker but are not yet available — they are greyed out with a Coming Soon badge.

Creating a deployment

1. Open your Agent and go to the Deploy tab.
2. Click New Deployment to open the channel picker.
3. Pick a channel tile.

Some tiles can be disabled for your org:

• Phone is disabled with a No quota badge when you have no remaining phone-number quota and no spare pooled number.
• Chat (Internal) is disabled with an already configured badge once the agent has an internal chat. Each agent can have only one internal chat.

There is also an overall deployment limit tied to your plan. If you reach it, creating a deployment is blocked with a message to upgrade your plan to add more.

Each card in the deployment list shows the channel, the deployment name (hidden for internal chat), the model name, a data-assessment shield badge, the deployment ID, and an active/inactive toggle plus a delete button. Phone cards also show the access-mode badge and the assigned number (or "No number").

Choosing a model

Every deployment runs on one primary AI model, which is required. You pick it from a model picker when you create or edit the deployment. Model text rates are shown per 1,000 words in the picker, and usage is billed in credits.

A few rules govern which models you can choose:

• The list is filtered by your organization's data-residency setting. Under a strict setting the list can be short or even empty. See Data residency below.
• Phone deployments require a voice model. Every other channel requires a text model. The pickers pre-filter accordingly, and the backend rejects a mismatched model (for example, "Phone deployments require a voice model" or "Voice models can only be used for phone deployments").
• Changing the model takes effect immediately with no downtime.

If a model you already selected later becomes non-compliant with your residency setting, the deployment keeps running on it but is flagged with an amber residency-warning badge (see below). botts.ai never silently changes your model.

Backup model and failover

Website and Chat (Internal) deployments can also have an optional backup model, chosen from a second picker. When the primary model's provider is unreachable, requests transparently fail over to the backup, so a provider outage doesn't take your chat down.

Failover is text-only. Phone deployments have no backup model because voice failover is not supported.

A few constraints apply to the backup:

• It must be a different model from the primary.
• It must be a text model (not voice).
• It must satisfy the same data-residency setting as the primary, because it serves real traffic during an outage.

Choosing a backup on the same provider as the primary gives you little protection — if that provider is down, both models are down. The picker shows an amber warning in this case.

Failover triggers only on a provider outage:

• HTTP 5xx server errors
• HTTP 429 rate-limit / quota errors
• Connection-level failures — timeouts, network unreachable, DNS failures
• The specific case of a 400/404 saying the model itself was decommissioned or is invalid (a different backup model can still serve the request)

It does not fail over on other client errors (bad requests, authentication, validation). Those would fail the same way on the backup, so retrying would only add latency.

Website widget

The website widget is a customizable chat bubble that sits on your public site, by default in the bottom-right corner. Visitors click it to chat with your agent. Website deployments are public — there is no access mode; access is controlled by the embed/API key.

Create

When you pick Website, a create form captures the essentials:

• Name — defaults to Website <date>.
• Model (text-only) and an optional backup model.
• Initial customization: welcome message, theme and message-bubble colors, suggested messages, and position.

The default colors are an indigo header and user-bubble (#6366f1), a white chat background, and a light-grey bot bubble. Rich customization happens after creation, in the editor.

Edit: the split-pane editor

Opening a website deployment shows a split-pane editor.

The left panel holds the name, model and backup-model pickers, the full widget settings, and the embed code. The right panel is a live preview that updates as you change styling. You can collapse the preview between the widget-button view and the full chat, and adjust its size and side.

Available customization options:

Link previews can be enabled and limited to a list of allowed domains, so links the agent sends render as rich previews in the widget.

Embed code

Copy the embed snippet from the editor and paste it into your site's HTML, just before the closing </body> tag:

<script async src="https://your-api-url/widget/chat-widget.js?key=YOUR_API_KEY"></script>

The snippet is keyed by the deployment's unique API key (the key query parameter), loads asynchronously, and works on any platform — WordPress, Shopify, Squarespace, Wix, or custom HTML. A copy button is provided.

API key

Every deployment has a unique API key (prefixed bts_) that authenticates widget requests. Admins and Owners can rotate it with Regenerate key; the old key stops working as soon as the new one is issued, so update your embed code afterward.

Chat (Internal)

Chat (Internal) is a chat channel for your own organization members rather than the public — for example, a team-facing assistant over your knowledge base. Each agent can have only one internal chat.

Configuration:

• Model (text-only) and optional backup model.
• Avatar / logo — a circular image for the chat.
• Welcome message — a multi-line opening message.
• Show Tool Use — a toggle (on by default) that shows members which tools the agent is using as it works.
• Access control — see below.

The default name is Chat Internal and is hidden on the deployment card.

Access control

Access modes apply to Chat (Internal) and Phone. Website deployments have no access mode (they're public via the embed key).

• Phone offers all four modes and defaults to Public.
• Chat (Internal) offers Organization, Role-based, and Invite-only (no Public) and defaults to Organization.
• Role-based reveals a minimum-role picker (default Builder).
• Invite-only reveals a member checkbox list.

Phone agent

A phone deployment answers real phone calls with a real-time voice model. Customers dial the assigned number and speak with the agent.

Create

Selecting Phone creates the deployment immediately — there's no create form first. You'll see a brief "Creating phone deployment…" spinner, then the edit view. botts.ai auto-picks a voice model (the one you selected if it's a voice model, otherwise the first available voice model). If your org has no voice model available, creation fails with "No voice model is available." The default name is Phone <date>, and the default access mode is Public.

Voice and model settings

The phone edit form shows a voice-only model picker, a voice picker, and a single-line welcome message (the agent's opening line). The default voice is alloy.

Turn detection

Turn detection controls how the agent knows the caller has finished speaking.

With Normal selected, advanced sliders appear:

Advanced settings

Calls are transcribed with Whisper. Recording is off unless you enable Record calls.

Phone numbers

Phone numbers are an org-level resource managed by Admins and Owners. You buy numbers into an organization pool, then assign a pooled number to a phone deployment. Managing numbers is blocked for Builders and Members.

Supported countries

You can buy numbers in: United States, United Kingdom, Germany, Italy, Switzerland. Searchable number types are local, mobile, and toll-free; only voice-capable numbers are returned. For US numbers you can filter by area code; other countries filter by a digit pattern.

Quota

Each organization has a phone-number limit. The picker shows used / limit. When you've used your full quota, buying a new number is blocked with "Phone number quota exhausted… Contact support to increase your limit."

Assign and unassign

• Assigning a pooled number to a deployment is free and instant. It wires the number's voice webhook to that deployment. A number can hold only one deployment, and a deployment can hold only one number.
• Unassigning returns the number to the pool and clears its webhook.
• Deleting a deployment automatically unassigns its number back to the pool (it is not released).

Releasing a number

Releasing a number back to the carrier removes it from your pool entirely. A number must be unassigned first, and it cannot be released until 30 days after you bought it (the carrier's hold period). The picker shows when each number becomes releasable.

Data residency and transparency

Every deployment exposes where its data physically lives, and your organization can require models hosted in specific places.

Residency tiers

Your organization's data-residency setting filters which models you can pick.

Switzerland counts as European but is not part of the EU. If a model violates a non-global tier, selecting it is rejected ("Selected model is not allowed by your organization's data-residency setting"). The backup model is checked against the same tier when you set it. A model you already chose is not re-checked on save — if it later becomes non-compliant it keeps running but is flagged.

Data assessment badge

Each deployment shows a small emerald shield badge summarizing the countries where its data sits. Hovering reveals a transparency panel.

The panel lists:

The panel links to a data-residency explainer for more detail.

Managing multiple deployments

You can run several deployments on the same agent — for example a public website widget and an internal team chat, or separate phone numbers for different countries. Each deployment has its own channel, model, settings, and API key, but they all share the same Agent and Knowledge Base. Each card has an active/inactive toggle so you can pause a deployment without deleting it.

Last updated on June 16, 2026