Skip to main content
A deployment makes an Agentic project live so users can reach your agents. The platform organizes every part of going live under four tabs in the Deployments workspace: Environments, Channels, Endpoints, and API Keys. This page covers each tab in the order you use it. Before any user reaches an agent, three things must exist together. You need an active deployment in the target environment, environment variables that resolve every reference your ABL uses, and a channel bound to that environment with an API key that authorizes access. The following terms recur throughout this guide.

Environments

The Environments tab is where you create deployments, manage the variables they depend on, and move a release from development to production. It lists a shared Base variable set, one card for each environment, and a history log of retired deployments. The tab header shows how many deployments are currently active and provides the New Deploy button.

Deployment lifecycle

A deployment always scopes to a single environment, and only one deployment stays active per environment at a time. When you activate a new deployment, the platform retires the previous one automatically. In-progress sessions finish on the old version while new sessions route to the latest deployment. The lifecycle follows a fixed path. You build agent versions, configure variables, deploy to development, promote to staging, promote to production, then connect channels so users can reach the agents.

Environment cards

Each environment card represents one deployment slot. When a deployment is active, the card shows its ID, status, label, the number of agents and workflows it contains, and the pinned component versions. The three environments follow a fixed promotion order. Each card provides Snapshot, Promote, Rollback, and Retire controls. Snapshot captures the current state, Promote pushes the manifest to the next environment, Rollback restores the previous deployment, and Retire decommissions the deployment. Production omits Promote because it’s the final stage in the chain.

Environment variables

Configure variables before you deploy, so that every reference resolves at runtime. The Base set defines fallback values shared across all environments, and any environment can override a Base value with its own. The panel also lets you export, import, and copy variables between environments. To add an environment variable:
  1. Open Base (Default), Development, Staging, or Production.
  2. Click Add, then enter the key and value.
  3. Select Secret when the value is sensitive. The platform stores secrets write-only, so no one can read them back after you save.
  4. Click the confirm icon to save the variable.
Variable changes affect new sessions only. In-progress sessions keep their original values until they end, and runtime execution fails when an agent reads an unresolved variable. You can also set global variables under Admin Settings -> Env variables. When keys collide, the environment-specific variable takes priority.

Create a deployment

Click New Deploy to open the Create Deployment dialog. You choose the target environment, name the release, decide how the platform selects agent versions, and confirm the agents, workflows, and variables the deployment includes. Complete the fields in order.

Version strategy

The version strategy controls which build of each agent the deployment uses. Choose the approach that matches how much control you need over individual agents. For workflows, pin each one to a published version or select Auto-create from draft to generate a version from the current working copy. A running summary confirms the payload before you deploy. When you click Deploy, the platform validates your ABLs, resolves configuration placeholders, activates the deployment, and retires any previous deployment in that environment.

Promote through environments

Promotion moves the exact manifest you tested into the next environment, so you never rebuild a release by hand. This keeps development, staging, and production in sync and reduces configuration drift. To promote a deployment:
  1. On the Development card, click Promote to push the manifest to staging.
  2. Confirm the deployment behaves as expected in staging.
  3. On the Staging card, click Promote to push the same manifest to production.

Roll back a deployment

A rollback reverses an active deployment when it causes problems. The platform retires the current deployment and reactivates the previous one, so users recover quickly. To roll back a deployment:
  1. Locate the environment running the problem deployment.
  2. Click Rollback.
Sessions on the failed deployment finish naturally, and new sessions reach the restored version immediately.

Deployment history

The Deployment History log records every retired deployment for audit and recovery. Each entry lists the deployment ID, source environment, retired status, date, and component versions, along with a Snapshot link.

Deployment status

Every deployment moves through a small set of states as it goes live and later steps down. The status tells you whether a deployment serves new sessions, is winding down, or is fully decommissioned.

Channels

Channels connect your agents to the places your users already are—messaging apps, voice systems, or your own web and mobile apps. Open the Channels tab, pick a channel card, and configure it. Each channel can either follow an environment automatically or stay locked to a specific deployment version. This means you can publish the same agent across many surfaces without rebuilding it each time. For the full list of supported channels and setup steps, see Channels.

Endpoints

The Endpoints tab gives you the direct call surface for each agent in a chosen deployment. You select a deployment, then copy the ready-made request for any agent it contains. Each agent exposes three request modes: Chat, Stream, and WebSocket (SDK). Open Select deployment and choose the deployment you want, such as the active staging, production, or dev deployment. The tab then lists each agent with its Chat URL and the three request modes. A Chat URL follows this structure. The Chat tab supplies a copy-ready request.
The Stream and WebSocket (SDK) tabs use the same base URL with a different request format. Capture and confirm those request bodies before publishing.

API keys

The API Keys tab creates and manages the credentials external applications use to reach your agents. It separates keys into two types for two audiences, each on its own sub-tab. The type you create determines the format of the key and the permissions it can carry.

SDK keys

The SDK Keys sub-tab lists every SDK key by name and masked value. Each row includes a delete control, and rows show a last-used date once the key has been called. Click Create Key to add a new one.

Platform keys

The Platform Keys sub-tab lists every platform key with fuller metadata and edit and delete controls. Each key also carries a status, such as revoked, and a View scopes expander that reveals the permissions it grants.

Create a platform key

A platform key carries explicit scopes, so you grant only the permissions the integration needs. You name the key, select its scopes, and set an expiration before you create it. To create a platform key:
  1. Click Create Key, then enter a key name.
  2. Select one or more scopes from the groups below.
  3. Choose an expiration: No expiration, 30 days, 90 days, or a Custom date.
  4. Click Create Key.

Scopes

Scopes define exactly what a platform key can do. The platform groups them by function, so you can grant read access, write access, or execution rights independently.