Mindset docsHow it worksEnvironments
Environments
An environment is a named partition of your org, such as Sandbox or Production, with its own agents, connections and API keys.
Skills for your coding agent
An environment is a named partition inside your org, such as Sandbox, Test or Production. Everything built in one environment belongs to it and can't see anything in another.
Every org starts with exactly one, named Sandbox, with the address original. Add another to try changes against test systems, apart from the agents people rely on.
Why it matters#
You can change an agent without putting the live one at risk. Build and test against test systems, and nothing you do there can read a real invoice or send a real supplier query. An API key only works in its own environment, so a leaked Sandbox key can't reach Production.
What each one holds#
| Lives inside one environment | Shared by the whole org |
|---|---|
| Agents and their versions, scripts, functions and widgets | Members and their roles |
| Connections, their operations and their credentials | The list of environments itself |
| Each operation's tested status, and the write go-aheads given for test runs | Org settings, including the write operation switch |
| Test parameters, behavior tests and experiments | Model keys, embedding keys and the keys for the built-in agents |
| Triggers, schedules, conversations and runs | The audit record |
| Cost records | |
| API keys, and the Allowed websites list for embedded sign-in |
The connections make two environments different. If Test's finance connection holds the credentials for your test finance system, the invoice exceptions agent built in Test can't read a real invoice or send a real supplier query, whatever its instructions say.
Moving work between environments#
Nothing is copied between environments, and there is no promote step. Make the change again in the next environment once it holds up.
| What | Across environments |
|---|---|
| Operation approvals | Approving "send supplier query" in Test doesn't approve it in Production |
| Tested status | Kept per environment. A script or function rebuilt in Production can't go live until its operations have run successfully there, or an admin chooses Go live untested. See the go-live gate |
| The write operation switch | Org-wide, so you can't hold new write operations for approval in Production only. See Security and approval |
Webhook and MCP addresses (…/orgs/<org>/envs/<env>/mcp) name the environment, so a delivery or a client always lands in the one it was set up for. The Studio works in the one chosen in the Environment switcher in the left navigation.
Members and API keys#
Membership is access to every environment. A member's role is the same in all of them, and you can't invite someone into Test only.
An API key works only in the environment it was created in, and a call that names another environment is refused. The key is shown once, when it's created.
Names and addresses#
Only admins can create or rename an environment. Mindset derives the address from the name and adds a number if it's taken, so a second "Test" gets test-2. Renaming changes only the name people see, so every address keeps working. An environment can't be deleted.
To create environments and API keys, see Roll out Mindset.