Workspaces
A workspace is an isolated container for an AI agent’s resources. When you create a workspace, you define what the agent has access to — AI credentials, secrets, storage — and then launch runtimes inside it.
Creating a workspace
The name identifies this workspace. You get back a WorkspaceClient that you use to launch runtimes, execute steps, and manage the workspace’s lifecycle.
Mounting resources
Most workspaces need access to AI providers, a secret vault, or shared storage. You attach these at creation time via mounts:
AI credentials mount
Controls which AI provider credentials the workspace can use. allow is a list of credential IDs (managed via bctrl.aiCredentials). defaults sets the default credential per provider — runtimes and agents will use these unless overridden.
Vault mount
Controls which secrets from your vault the workspace can access. Scoped by key prefix — allow: ["prod/crm/"] means the workspace can read any secret under prod/crm/ but nothing else. deny explicitly blocks prefixes. allowRawReads controls whether plaintext secret values can be read directly.
Storage mount
Connects a storage namespace to the workspace. Files uploaded by runtimes (screenshots, downloads, exports) are stored here. Multiple workspaces can share the same storage namespace.
All runtimes launched inside the workspace inherit these mounts. See Scopes & Inheritance for how narrowing works.
Opening an existing workspace
If you already have a workspace ID:
Listing workspaces
Workspace state
Query the current state of a workspace — its active runtimes, mounted resources, and configuration:
Execute
For low-level control, you can execute structured automation steps directly on the workspace without going through a driver:
This is the HTTP-equivalent execution model. Most users should prefer the fluent driver APIs instead.
Related
- Runtimes — launch and automate resources inside a workspace
- Scopes & Inheritance — how mounts flow to runtimes
- API Reference: Workspaces — the underlying HTTP endpoints

