Multi-environment Agent

The Multi-environment Agent blueprint demonstrates how a single agent can operate across multiple isolated shell execution environments by dynamically loading different skillsets at runtime.

The Core Problem

When an agent needs to work across different environments (development, staging, production, or simply different project workspaces), each environment must maintain its own shell session state, file system, and installed dependencies. If the agent used a single shell/exec ability, all commands would run in the same sandbox - mixing state, leaking environment variables, and making it impossible to tell which environment produced which output.

The Solution: One Skillset Per Environment

Each environment is represented by a separate skillset containing its own shell/exec and shell/rw abilities, each bound to a dedicated space. Because the shell session is tied to the skillset's space, each environment gets its own isolated sandbox with persistent state. The agent installs the skillset for the environment it needs, runs commands there, and can switch to another environment by installing a different skillset.

How It Works

The agent starts with a core skillset that provides two meta-abilities:

1. List Environments uses blueprint/resource/list filtered to type: skillset to discover all available environment skillsets. Each skillset's name and description tell the agent what the environment is for (e.g. "Development" vs "Staging" vs "Production").

2. Install Environment uses conversation/skillset/install[by-id] to dynamically load a skillset into the current conversation. Once installed, the agent gains access to that environment's shell and file abilities.

Each environment skillset contains:

• A shell/exec ability bound to its own space for command execution
• A shell/rw ability bound to the same space for reading and writing files

Because each space is independent, commands in the Development environment cannot affect the Staging environment, and vice versa. Environment variables, installed packages, and file state are all isolated.

Why Separate Skillsets Matter

Without separate skillsets, there is no way to maintain distinct shell sessions or know which sandbox a command runs in. The skillset is the unit of session isolation - it binds abilities to a specific space, and the space provides the sandbox. This is what makes multi-environment operation possible: the agent does not just switch contexts mentally, it physically switches to a different execution environment.

Use Cases

• Dev/Staging/Prod workflows - test a script in development, then run the same commands in staging to verify, and finally execute in production.
• Multi-project workspaces - each project gets its own environment with its own dependencies and configuration.
• Isolated experimentation - try something risky in one environment without affecting others.
• Comparative testing - run the same script in two environments and compare outputs to detect environment-specific issues.

Getting Started

1. Chat with the agent and ask it to list available environments.
2. Ask the agent to install the Development environment.
3. Run commands - they execute in the Development sandbox.
4. Ask the agent to install the Staging environment.
5. Run the same commands - they execute in a completely separate sandbox with its own state.

Backstory

Common information about the bot's experience, skills and personality. For more information, see the Backstory documentation.