Skip to main content
Running a workspace takes two steps: create one on the backend that matches your target environment, then hand its resources to the agent.

Create Workspace

Each backend has its own persistence model and directory layout. Pick the tab matching your target environment:
LocalWorkspace persists state directly under workdir on the host filesystem; restarts simply re-open the same directory. The directory has the following layout:
default_mcps and skill_paths are seed-time inputs, but they never make resources shared inside a shared workspace. Each agent / session gets its own client instances the first time it accesses MCPs, and each agent gets its own skill partition copied from skills/.seed the first time it accesses skills. Later additions and removals only affect that agent / session.

Integrate with Agent

A workspace plugs into Agent along two axes: as a source of tools, MCPs, and skills, and as the offloader for context compression:
The tools returned by list_tools() are already bound to the workspace’s execution backend, so on a sandboxed workspace they run inside the container or sandbox. To bind your own tool instances to the same environment, obtain the backend with workspace.get_backend() and pass it to the tool constructor; see Switch Tool Backend.
Because the workspace exposes its resources as flat lists, you can partition them into ToolGroups when the agent has too many tools to keep all active at once. Pass the groups to Toolkit(tool_groups=[...]) and the agent activates them on demand through the built-in meta tool; only the reserved basic group stays always-on.