Skip to main content
Environments are how you move safely from experimentation to production. They let you test changes, review impact, and roll back mistakes without exposing real users to unfinished work. A typical deployment pipeline looks like this:
  • Sandbox → Pre-release → Live
Each environment runs a specific published version of your agent. Draft changes do nothing until they are published and promoted.

​
How environments work (mental model)

Think of environments as checkpoints, not branches.
  • Draft: Your working state. Changes exist only for you.
  • Published version: A snapshot of the agent at a moment in time.
  • Environment: A place where a specific version is running and can receive traffic.
Multiple environments can point to the same version, but only one version per environment is active at any time.

​
The Environments page

This page shows every published version of your agent and where it is currently deployed. You’ll see:
  • Version name or description
  • Author and timestamp
  • Which environments it’s active in (Sandbox / Pre-release / Live)
  • An overflow menu for actions
Key actions from the menu:
  • Preview version – load the agent exactly as that version behaves
  • Compare versions – open a side-by-side diff
  • Rollback to this version – immediately restore a previous state

​
Sandbox

Sandbox is your development and testing environment. Use Sandbox for:
  • Writing or editing KB topics
  • Adjusting rules and behaviour
  • Changing voice settings
  • Wiring or modifying actions, SMS, or handoffs
Do
  • Confirm you are in Sandbox before editing.
  • Publish frequently with short, descriptive notes.
  • Test after every meaningful change.
Example publish note: “Clarified late checkout KB and added SMS consent language”
Verify
  • Chat testing reflects your latest changes.
  • Test calls hit Sandbox numbers, not Live numbers.
  • Conversation Review shows the Sandbox environment tag.

​
Pre-release

Pre-release is your staging / UAT environment. It should be treated as:
  • Stable
  • Reviewable
  • Close to production
Use Pre-release for:
  • Stakeholder sign-off
  • QA review
  • Final voice and pacing checks
  • Regression testing
Do
  • Promote to Pre-release only after Sandbox tests pass.
  • Re-run your full smoke test:
    • Simple FAQ
    • Multiturn FAQ
    • SMS offer
    • Handoff
    • Out-of-scope refusal
  • Review Conversation Review data again.
Example UAT checklist:
  • Does the agent still ask for SMS consent?
  • Are handoff reasons correct?
  • Does voice sound identical to Sandbox?
Verify
  • No unexpected KB topics are triggered.
  • No new hallucinations appear.
  • Behaviour matches expectations across channels.

​
Live

Live is production. Real users are here. Rules for Live
  • Never edit directly.
  • Never “just test something quickly”.
  • Always know exactly what version is live.
Do
  • Promote to Live only from Pre-release.
  • Confirm promotion explicitly in the dialog.
  • Monitor first calls after release.
Example safe release habit: Promote → make one test call → open Conversation Review → confirm behaviour → continue monitoring.

​
Publishing and promotion flow

  1. Make changes (Draft).
  2. Click Publish.
  3. Add a clear description.
  4. Version appears in Sandbox.
  5. Promote to Pre-release.
  6. Test and review.
  7. Promote to Live.
Nothing skips steps. If it does, something is wrong.

​
Comparing versions

The Compare versions view is your primary safety tool. It shows:
  • Added KB topics
  • Modified content
  • Removed actions
  • Function wiring changes
  • Sample question edits
Use this before every promotion.
Example comparison insight:
  • Late checkout KB text changed
  • New SMS action added
  • No rule or voice changes
If you can’t explain every change in the diff, don’t promote.

​
Rollbacks

Rollbacks are instant and safe. Use rollback when:
  • A KB topic misfires
  • Voice sounds wrong
  • Handoffs spike unexpectedly
  • A release introduces confusion
Do
  • Select a known-good version.
  • Roll back.
  • Confirm rollback.
  • Verify with a live test call.
Rollback restores behaviour immediately without deleting newer versions.

​
Phone numbers and environments

Each environment can have its own phone number. Best practice
  • Sandbox number: internal testing only
  • Pre-release number: QA / stakeholder testing
  • Live number: public traffic
This prevents accidental testing on production users.

​
Common mistakes

  • Editing while in Live without noticing.
  • Forgetting to publish before testing.
  • Assuming KB edits propagate automatically.
  • Skipping version comparison.
  • Using vague publish notes like “updates”.

​
Verify you understand environments when:

  • You can say which version is live without checking.
  • You know how to roll back in under a minute.
  • You can explain what changed between two versions.
  • You never feel tempted to “just tweak production”.
If environments feel slow, that usually means they’re doing their job.