Skip to main content
Every agent has one draft and a linear history of published versions. Edits in the Builder or via the API always land in the draft — production sessions never see them until you publish. Publishing snapshots the draft into an immutable, numbered version, so you can iterate freely without touching live traffic.

Edit the draft

Prompt, voice, and conversation settings — all autosaved.

Test before publishing

Preview calls talk to the draft, not the live version.

Automate via API

Manage drafts, publishing, and version history programmatically.

​
Draft vs. published

An agent that has never been published cannot take production sessions — session creation returns 409 until the first publish. Publishing is the single gate between editing and live traffic.

​
Publish from the Builder

1

Edit — changes autosave

There is no Save button. Every change is written to the draft automatically; the Saving… / Draft saved indicator in the top bar shows the current state.
2

Watch the unpublished-changes indicator

When the draft differs from the last published version, the Publish button becomes active with an unpublished-changes hint next to it. When there is nothing new to publish, the button is disabled. An agent that has never been published always counts as having changes.
3

Publish

Click Publish. Any pending edits are saved first, then the draft is snapshotted as the next version. A confirmation shows the new version number, and the agent shows as Live in your agents list.
New sessions use the newly published version from that point on. To hear a change before it goes live, run a preview call — previews always use the draft.

​
Publish via the API

Configuration edits (PATCH) go to the draft; a separate publish call rolls them out. A version_title and version_description are optional and make the version history easier to audit:
The publish response includes the new version_number.

​
Version history

List published versions, or fetch the complete configuration snapshot of any one of them — including the version currently serving production:
Each version record includes: Fetching a single version returns the full configuration as it was published. Because GET .../config always shows the draft, the snapshot endpoint is how you read back what is actually running in production.
Version snapshots never echo credential secrets. Write-only fields — such as webhook secrets and tool authorization headers — return a has_secret: true marker instead of the value, in every version including historical ones.

​
Restore a previous version

Roll back by copying an old snapshot back into the draft: read the version you want, then PATCH its sections into the draft config.
Patching updates the draft — it does not publish. Review or preview the restored draft, then publish it as a new version; the rollback becomes part of the linear history, so the audit trail stays intact. Because snapshots never echo secrets (see above), credential fields keep their current draft values unless you set them again explicitly.

​
Clone an agent

Cloning creates a new agent from an existing one’s draft configuration. In the console, open the agents list and choose Clone from the agent’s row menu. The clone starts with a copy of the source’s current draft. Published versions do not carry over — the new agent is unpublished until you publish it yourself. Use clones to template a base configuration across many agents, or to experiment without risking an agent that is already live.

​
Going further

Agent configuration

Everything that lives in the draft: prompt, voice, conversation settings.

Preview calls

Talk to the draft before it ships.

Agent tests

Run regression tests against the draft, then publish with confidence.

Integration overview

Connect published agents to your product via SDK and API.