Manage MCP Servers
MCP declarations are isolated byagent_id + session_id. Even when several sessions share one workspace, the connections, cookies and login state of a stateful MCP never leak into another session. The client is only connected the first time that session calls list_mcps:
Persistence follows the workspace’s own model: an ephemeral
DockerWorkspace without a host workdir keeps the MCP list in memory only, and it is lost when the container goes away.Manage Skills
Skills are isolated byagent_id. skill_paths first populates the skills/.seed template; the workspace creates a private partition for an agent the first time it accesses skills. add_skill, remove_skill and list_skills only operate on the given agent’s partition:
Manage the Lifecycle
Three methods take a workspace through its life, and theasync with protocol wraps initialize / close for scoped use:
Allocate Workspaces in a Service
In a multi-tenant service, deciding which request gets which workspace (per user, per agent, or per session), caching live instances, and evicting idle ones is the job of the workspace manager, a separate service-side component. See its dedicated chapter:Workspace Manager
Allocation, isolation policies, TTL eviction, and integration with the Agent Service.