> ## Documentation Index
> Fetch the complete documentation index at: https://koreai.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# Deploy Agents
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.
| Term | Definition |
| ---------------- | -------------------------------------------------------------------------------- |
| **Version** | A frozen snapshot of a compiled agent. |
| **Deployment** | A manifest that maps agents and workflows to versions for one environment. |
| **Environment** | One of the deployment slots: development, staging, or production. |
| **Channel** | A user-facing surface that connects a deployment to end users. |
| **SDK key** | A public, client-side credential that SDK applications use, prefixed `pk_`. |
| **Platform key** | A scoped, server-to-server credential for backend integrations, prefixed `abl_`. |
## 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.
| Environment | Description |
| --------------- | ------------------------------------------------------------------------------- |
| **Development** | The first slot in the promotion chain, where you validate a new build. |
| **Staging** | The middle slot, where you verify the release against production-like settings. |
| **Production** | The final slot, which serves live users. |
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.
| Field | Description |
| ------------------------- | ------------------------------------------------------------------- |
| **Environment** | The deployment slot you target. Start every release in development. |
| **Label** | A short, readable name for the release. |
| **Description** | Optional notes about the deployment. |
| **Version Strategy** | How the platform selects each agent's version. |
| **Entry Agent** | The agent that receives the first message in a session. |
| **Workflows** | The workflow versions the deployment includes. |
| **Config Variables** | Optional. The config variable set version to bind. |
| **Environment Variables** | Optional. Deployment-scoped variable overrides. |
### 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.
| Option | Description |
| ----------------------- | ------------------------------------------------------------------------------------------- |
| **Use latest active** | Deploys the best available version for every agent, the fastest path to production. |
| **Customize per agent** | Pins a specific version for each agent and lets you configure model overrides individually. |
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.
| Status | Description |
| ------------ | --------------------------------------------------------------------- |
| **active** | Serves live requests and receives new sessions. |
| **draining** | Accepts no new sessions while existing sessions finish. |
| **retired** | Fully decommissioned, though active sessions continue until they end. |
## Channels
Channels connect your agents to the platforms your users already use, from messaging apps and voice systems to your own web and mobile applications. On the Channels tab you select a channel card to open its configuration, and each channel either follows an environment automatically or pins to a specific deployment version. This lets you expose the same agents across many surfaces without rebuilding them for each one.
The platform groups the available channels into five top-level categories.
| Category | Description |
| ------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Messaging** | Connects agents to chat and customer-support platforms such as Slack, WhatsApp, Microsoft Teams, and Zendesk. |
| **SDK** | Embeds agents into your own website or applications. |
| **Voice** | Routes live and telephony conversations through the Kore.ai Voice Gateway and partner connectors, including realtime LLM voice and traditional STT to LLM to TTS pipelines. |
| **Webhook** | Delivers agent responses to your own server asynchronously. |
| **Protocols** | Exposes agents through standardized agent-communication interfaces. |
To review the full list of supported channels and the step-by-step setup for each one, see [Channels](/agent-platform/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.
```bash theme={null}
curl -X POST 'https://agents-dev.kore.ai/api/v1/project/smartdesk-enterprise-assistant/staging/agent/emailassistant/chat' \
-H 'x-api-key: ' \
-H 'Content-Type: application/json' \
-d '{"message": "Hello", "sessionMetadata": {}}'
```
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.
| Key type | Description |
| ---------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- |
| **SDK key** | A public, client-side credential that SDK applications use to start a session. Requests stay constrained by the session token. Prefixed `pk_`. |
| **Platform key** | A scoped credential for server-to-server platform API access, used by integrations, workflows, and backend automation. Prefixed `abl_`. |
### 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.
| Field | Description |
| -------------- | ----------------------------------------------------- |
| **Masked key** | The truncated key value shown after creation. |
| **Created by** | The user who created the key. |
| **Created at** | The date and time the key was created. |
| **Lifecycle** | The key's current state and the time it last changed. |
| **Scopes** | The permissions granted to the key. |
### 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.
| Group | Scope | Description |
| ------------------ | -------------------------- | ------------------------------------------------------------------------------------------------ |
| **Execution** | Execute Workflows | Execute workflows through the Process API. |
| | Invoke Draft Workflows | Invoke draft, unpublished workflow versions, intended for CI/CD pipelines and automated testing. |
| | Read Workflows | Read workflow definitions and status. |
| | Execute Chat | Send messages to agents through the Chat API. |
| **Management** | Read Agents | List and inspect agent configurations. |
| | Write Agents | Create and update agent configurations. |
| | Read Channel Connections | Read project channel connection details for service integrations. |
| | Write Channel Connections | Create, update, and deactivate or delete project channel connections for service integrations. |
| | Read Deployments | List deployment status and history. |
| | Write Deployments | Create and promote deployments. |
| | Read Sessions | Read session history and transcripts. |
| | Write Sessions | Attach external provider metadata to sessions and trigger transcript sync. |
| **Knowledge base** | Query Knowledge Base | Execute search queries against knowledge bases. |
| | Read Knowledge Base | Read knowledge base metadata and configurations. |
| | Ingest Documents | Upload files and ingest data into knowledge bases. |
| | Write Document Permissions | Set document-level ACL permissions during ingestion. |
| **Analytics** | Read Analytics | Read analytics dashboards and metrics. |
| **Admin** | Read Workspace | Read workspace settings and usage data. |