Skip to content

Deployments

A deployment publishes agents and teams. It combines them with environments, guardrails and the list of roles that may use them. Until an agent is part of a deployment, nobody can chat with it.

POST ${RUNTIME_BASE_URL}/v1/deployments
Content-Type: application/json
{
"id": "support-prod",
"environments": ["base", "production"],
"components": ["agent/support-agent", "team/escalation-team"],
"guardrails": ["scope-input", "shopfloor-safety"],
"access_control": {
"execute_roles": ["support-team"]
}
}
FieldMeaning
idUnique ID of the deployment
environmentsEnvironments to use, merged in this order
componentsAgents and teams to publish. Only agent and team components are allowed.
guardrailsOptional guardrails that check requests and answers
access_control.execute_rolesRoles that may use the published agents

Updating a deployment (PUT /v1/deployments/{id}) replaces all its fields. Changes take effect without a redeployment of the service.

A user needs at least one of the roles in execute_roles to use an agent of the deployment. The roles are created automatically when the deployment is saved. Your tenant administrator then assigns them to users. See Roles and permissions.

Each published agent or team gets an instance ID:

{deployment_id}.{component_type}.{component_id}

For the example above, the IDs are support-prod.agent.support-agent and support-prod.team.escalation-team. Applications use this ID as the model value when they call the agent, and can list instances with GET /v1/instances.

GET /v1/instances/{instance_id}/health checks whether an agent or team is configured correctly and whether the language models it needs are available, without running it. See Instance health.

One deployment per stage:

support-test → test environment + support agent
support-prod → production environment + support agent

One deployment per user group:

sales → sales agent, lead qualifier
support → support agent, escalation team