Workspaces
A workspace is the isolated, persistent environment where an agent does its work. Every interactive session and workflow execution runs in its own workspace: a directory tree with mounted repositories, reference files, seed data, and environment context.
In Xema, workspaces are persistent by default. They survive pod restarts, scale-down events, and session pauses. Storage is backed by durable volumes, not ephemeral container filesystems. An agent can pick up exactly where it left off.
Quick Links
| Page | What it covers |
|---|---|
| Concepts | Storage pools, sub-path layout, session persistence, isolation model |
| Git Workflow | Auto-commit, branch policy, publish-to-prod, conflict resolution |
| Multi-User Sessions | Participants, actor attribution, real-time collaboration |
| Worker Runtime | WorkerRuntime driver, Kubernetes and Docker schedulers, cold-start |
| Image Variants | Per-org Docker image variants, Kaniko builds, base-image cascade |
| Versioning Lockfile | Lockfile, one-click update, rollback |
| Examples | Worked examples |
Getting Started
- Concepts — understand how storage pools and isolation work.
- Git Workflow — see how workspace changes flow back to source control.
- Worker Runtime — understand what runs inside a workspace.
- Versioning Lockfile — lock and update dependencies.
FAQ
Q: Does a workspace persist between sessions? A: Yes. Storage is PVC-backed per session and survives pod restarts. Sessions in the same project share project-level storage; sessions of the same user share user-level storage. Separate users get separate storage trees.
Q: Can multiple people work in the same workspace at once? A: Yes. See Multi-User Sessions for the participant model and actor attribution.
Q: Can I use a custom base image? A: Yes. Per-org Docker image variants let orgs ship their own toolchain. See Image Variants.