Workspaces
A workspace is the execution root for an agent — where it reads files, runs commands, and applies patches. Every agent always has exactly one active workspace.
What a Workspace Defines
| Concern | Set by workspace |
|---|---|
| Instruction root | Where AGENTS.md and policy files resolve |
| Execution root | Default working directory for commands |
| ApplyPatch target | Where file mutations land |
| Memory scope | Workspace-scoped episode records and indexes |
Workspace vs Shell Directory
A workspace is not a shell cd. Shell cd changes the directory for
that one command process. Agents use explicit binding and activation tools to
change where runtime tools operate.
| Action | Effect |
|---|---|
cd /other in shell | Only affects that command |
AttachWorkspace | Adds a workspace binding without switching |
SwitchWorkspace | Changes active workspace for subsequent operations |
holon workspace attach /path | Attaches and activates through the CLI compatibility flow |
Workspace Commands
Attach
Attach to a project directory as the active workspace:
holon workspace attach /path/to/project
holon workspace attach --agent my-agent /path/to/project
This discovers or creates a workspace record for the directory and makes it active for the agent. The workspace persists across sessions.
Exit
Return to the agent's home workspace:
holon workspace exit
holon workspace exit --agent my-agent
Detach
Remove a workspace record entirely:
holon workspace detach <workspace-id>
Detaching does not delete the directory — it removes the workspace record from Holon's index. Memory and episode records associated with the workspace are preserved.
Worktree Isolation
CreateWorktree creates a managed linked worktree from an explicit attached
workspace, branch, and base ref:
CreateWorktree {
workspace_id: "ws_...",
branch: "feature/example",
base_ref: "origin/main"
}
Isolated workspaces are useful for:
- Safe experimentation without polluting the working copy
- Parallel work on the same repository by different agents
- PR review branches where changes should not leak
Agent Home vs Project Workspace
| Workspace Type | Purpose | Example |
|---|---|---|
| Agent home | Agent-local state and memory | ~/.holon/agents/my-agent/ |
| Project workspace | Code and files being worked on | /path/to/project |
Every agent starts with its agent home as the active workspace. Use
workspace attach to switch to a project workspace, and workspace exit to
return to agent home.
Agent Workspace Tools
GetWorkspaceState({})— inspect bindings, active projection, worktrees, and occupancyAttachWorkspace({ path: "/repo" })— attach without switchingSwitchWorkspace({ workspace_id: "ws_..." })— activate a canonical rootSwitchWorkspace({ execution_root_id: "..." })— activate a retained worktreeSwitchWorkspace({ workspace_id: "agent_home" })— return to agent homeCreateWorktree(...)— create or safely reuse a linked worktreeRemoveWorktree(...)— clean-only registered cleanupDetachWorkspace({ workspace_id: "ws_..." })— remove a binding; active targets first return to agent home
UseWorkspace remains a hidden compatibility alias for historical calls.
See Also
- Runtime Model — Workspace lifecycle in the runtime
- CLI Reference — All workspace commands
- Agent Templates — How templates initialize agent homes
