Environments

Most teams want content changes on production and code changes rehearsed on staging first. The platform models both, and lets you decide per request.

Two kinds of staging

• Content staging — a separate dataset or environment in your CMS (Sanity dataset, Contentful environment). Connect one and the assistant can read and write it independently of live content: rehearse a restructure, prepare a launch, test a content model change.
• Code staging — a staging branch in your repository, deployed by your host as a preview/staging site. Code changes land there first and move to the production branch when you're ready.

Both are optional. Without them, everything targets production and the assistant simply won't offer a staging option.

Per-request targeting

The Production/Staging switch in the portal sets the suggested default — but the target is confirmed conversationally before the first write of each task, and saying it in your request ("on staging", "straight to live") is enough. One answer covers the whole task; the assistant won't re-ask per document or per file. It also never switches environment to get around a permission denial.

Environment-scoped roles

Role rules can be limited to an environment, which unlocks patterns like: writers who can do anything on staging but nothing on production; a developer restricted to the staging branch; an agency that prepares campaigns on staging for your in-house editor to promote. See Roles & permissions.