Staging lets you change an assistant's configuration without affecting the people and integrations that use it. Nothing you change in Staging goes live until you deploy it, and you can restore an earlier deployment at any time.Think of Staging as a workspace where you can experiment, iterate, and collaborate freely, then deploy to Production when everything is ready.
How it works#
Every assistant has two environments: Staging and Production. Use the Staging / Production switch at the top of the assistant's page to move between them.| Environment | Who sees it | What it's for |
|---|
| Production | End users and assistant integrations | The current live configuration |
| Staging | Editors only | A workspace to prepare the next set of changes |
Production is read-only. To change an assistant, switch to Staging. See Edit Assistant.
Editing in Staging#
Change the assistant's name, description, corpus, tools, guardrails, skills, or any other setting. All edits apply to Staging only, so you can test them before they reach your live assistant. A counter next to Deploy shows how many changes are waiting.Your Staging changes are kept until you deploy them, so you can work across several sessions without losing progress.For example, you might update the instructions on Monday, add documents to the corpus on Wednesday, and adjust the guardrails on Friday, all in Staging, then deploy everything together once it works well.
Reviewing and deploying changes#
When you click Deploy, the Deploy to Production window lists each setting that changed, with its current Production value and its new Staging value. Settings that didn't change aren't listed, so the review stays short. You can add an optional description of what changed and why.Click Deploy Changes to update Production immediately. The message Successfully deployed to production appears and the assistant switches to Production. If Staging already matches Production, the window says Nothing to deploy.A new assistant starts as a draft. Its first deployment also changes its status from Drafted to Live.
Deployment history#
Every deployment is recorded automatically. In Staging, open Deployment History in the Configuration panel to see each deployment's number, description, date, and who deployed it. The first entry, Initial Snapshot, is created when the assistant is created.Deployment history is useful for audits, for example to find out who made a change and when. Each entry is also a known-good version you can restore.
Restoring a deployment#
If a deployment causes unexpected behavior, you can restore any earlier entry in the history, not only the most recent one. Click an entry to open the Restore window. It shows:What this deployment changed: The changes that were applied to Production when that version was deployed.
Changes applied to staging after restore: What will change in your Staging assistant if you restore.
Restoring never updates Production directly. You stay in control of when changes go live.
Use cases#
Big instruction rewrite: Rewrite an assistant's instructions over several days in Staging, test them in Staging with the other editors, and deploy only when the answers are right. People keep using the old version in the meantime.Bad change, quick fix: A deployment makes answers worse. Open Deployment History, restore the last good deployment to Staging, check it, and deploy it again.Audit trail: Use the description you add to each deployment to record why something changed, so the history explains itself later. 