Skip to main content
A runtime environment is the agent’s computer. Everything a person has preinstalled on a laptop before starting work, the AWS CLI with a kubeconfig, kubectl, the Snowflake or Google Cloud CLI, a language toolchain, the team’s conventions, is what the agent finds installed when its session starts. It is attached per agent, not per session: every conversation of that agent starts on the same computer. This is a different thing from the two other places an agent has: A CLI in the runtime environment often replaces a skill. An agent with the AWS CLI and a kubeconfig operates the account the way an engineer does, one command at a time, instead of needing a skill for every operation. The same holds for a Snowflake or Google Cloud CLI, or anything else a laptop would have.

​
What goes in

Settings > Runtime environments > New runtime environment: “Context, packages, setup scripts and config files an agent inherits when it attaches this environment.”
Runtime environments tab in Settings

Settings > Runtime environments. Shown with sample data.

​
How it reaches the agent

The environment is built once and mounted read-only into every session of the agents that attach it. The context is read at the start of every run and is managed only in Xpander Chat, so an agent cannot rewrite the guidance it was given. Because the environment is attached to the agent, it follows the agent to whichever location it runs in. Secrets are not part of a runtime environment. A CLI reads its credential from the agent’s Workspace secrets at the moment of a call, so a kubeconfig or a cloud profile in Config files names the endpoint and the account, never the key.

​
Attach it to an agent

Agent settings > Advanced > Runtime environment lists the organization’s environments; pick one. The agent’s next session starts on it. Switching environments does not touch the agent’s files.