The Staging feature lets you make changes to an assistant's configuration in a staging environment before they reach your end-users and assistant integrations. Nothing you change in Staging goes live until you publish. You can also revert any previously published changes at any time.This functionality protects end-users from seeing incomplete or broken configurations. Think of Staging as a space where you can experiment, iterate, and collaborate with others freely, and only promote changes to Production when everything is ready.
Make your changes to the assistant — update the name, description, knowledge sources, tools, guardrails, or any other configuration. All edits apply to Staging only, allowing you to review and test before propagating them to your published assistant.Your staging changes are preserved until you publish them, so you can work across multiple sessions without losing progress.
Working across sessions
You might update the system prompt on Monday, add a new knowledge source on Wednesday, and adjust the guardrails on Friday — all in Staging — and only publish the full set of updates once you're happy with how everything works together.
Before publishing, you can review a side-by-side comparison of what has changed between Staging and Production. The comparison covers:
Assistant settings (name, description, model configuration, etc.)
Instructions
Knowledge sources
Tools
Guardrails
Each changed field shows the current Production value alongside the new Staging value, so you can verify everything looks correct before it goes live.
Only differences are shown
If a field is unchanged, it will not appear in the comparison — only the fields that differ between Staging and Production are highlighted. This keeps the review focused and easy to scan, even when your assistant has many configuration options.
When you are satisfied with your staging changes, deploy them to make them live. Production is updated instantly and a snapshot of the changes is saved to your deploy history.
NOTE
Nothing to deploy? If Staging is already identical to Production, there is nothing to deploy.
Deployment is a one-click action. Once confirmed, the changes will immediately reflect on the production assistant.
Review before you publish
Because the update is instant, it's important to review your changes carefully using the side-by-side comparison before proceeding.
Every deployment is recorded automatically. Each entry in your deployment history shows:
Who deployed
When it was deployed
A summary of what changed
You can browse this history at any time.
Why deployment history matters
The deployment history is useful for auditing purposes — for instance, if you need to understand who made a particular change and when. It also serves as the foundation for the Rollback feature, since each history entry represents a known-good snapshot you can revert to.
If you need to roll back a change or return to an earlier configuration, you can restore any entry in your deployment history.This is useful if a newly deployed configuration causes unexpected behavior. You are not limited to rollback only the most recent deployment — you can select and restore any entry from the full history.
Before committing to a restore, you can preview what would change in Staging so there are no surprises.The preview shows the side-by-side diff view, it shows what exactly changed in that deployment and it compares the selected history entry against the current state of Staging, so you can see exactly what will be rolled back before you commit.
It restores the changes introduced by that deployment onto Staging and rollbacks any changes made after that. Production is not affected immediately. This gives you a chance to review the restored changes before it goes live. Once satisfied, deploy to make the restore live in Production.
Production is not immediately affected
Restore does not immediately update Production. You are always in control of when changes go live.
