OpenClaw agents: proposed roles and workspaces

Status: updated 2026-09-28. startup-advisor and qwestly-career-lab are created (own workspace + own agentDir); the SOC 2 specialist is still only planned. No new channel bindings were added, and main (Max) remains the default system agent.

What an agent is

A configured OpenClaw agent has a persistent identity, workspace, session history, model/auth state, and optional tool policy. The Agents page shows this roster and opens each agent's main chat. Subagents are temporary delegated runs; Pi's coding subagents are a separate mechanism. Nothing here requires moving Qwestly's coding workflow from Pi into OpenClaw.

An agent's workspace is its default working directory and the source of its bootstrap instructions. It is not a filesystem security boundary: host tools may reach other paths unless constrained by sandbox and tool policy. Runtime sessions, credentials, and agent state stay under ~/.openclaw/agents/<agent-id>/agent/, even if the workspace is under ~/Work.

Proposed roster

Role	Workspace	Purpose and boundary
Max (main)	~/.openclaw/workspace	Keep the current personal assistant and general coordinator unchanged.
SOC 2 specialist	~/Work/qwestly-local/qwestly-private-docs/SOC2	Use the existing AGENTS.md, IN-PROGRESS.md, renewal and evidence playbooks. Vanta is the live compliance system of record; verify evidence claims against current implementation in ~/Work/qwestly-workspace. Do not treat HR/Legal as general context. Draft locally and get human sign-off before auditor-facing submissions. Keep the vault local-only; do not add a remote by default.
Startup advisor	~/.openclaw/workspace-startup-advisor (created 2026-09-28)	Dedicated discussion and decision history for leadership, product, and engineering strategy. It should challenge assumptions, not silently perform operational changes.
Career-agent lab	~/.openclaw/workspace-qwestly-career-lab (created 2026-09-28)	Prototype Qwestly career-agent behaviors and evaluation scenarios. Start with synthetic or explicitly consented data. Treat OpenClaw as a product experimentation surface, not a replacement for the Python/Pydantic AI service and web client in production.
SOC 2 specialist	~/Work/qwestly-local/qwestly-private-docs/SOC2 (planned, not created)	See the SOC 2 boundary above; not yet registered.

~/Work is simply where Dom keeps work, not a maturity or version-control marker. No uniform workspace path is required. Keep source repositories in place rather than copying them into agent workspaces.

Workspace files

• AGENTS.md: operating rules and task routing, loaded in agent sessions. The SOC 2 directory already has this and should remain authoritative.
• SOUL.md: optional persona, tone, and boundaries.
• IDENTITY.md: optional name and visual identity.
• USER.md: optional stable user context and preferences.
• MEMORY.md and memory/: optional agent-specific continuity. For SOC 2, first use the existing IN-PROGRESS.md as the durable work handoff; decide where any chat memory or scratch belongs so it does not pollute evidence or Git history.

These extra files are conventions, not prerequisites to create the SOC 2 agent. Do not copy Max's private MEMORY.md or entire user profile into specialist workspaces.

Shared capabilities and boundaries

~/.agents/skills is the current shared personal skill location, including the Qwestly Asana and personal-notes skills. A skill's availability is not a permission grant. The Asana skill's CLI uses a credential in its skill directory; an agent able to execute it can act through that account. The personal-notes skill points at ~/Work/personal-notes, which may contain material outside a specialist's remit. Define task/project ownership and the allowed reference scope for each role before granting broad tool or filesystem access. Tool policy, sandboxing, and credentials need separate review; workspace paths and prose alone do not enforce isolation.

Possible starting scope: Max retains broad personal context; the SOC 2 agent gets the SOC 2 vault, relevant code verification, Vanta, and compliance-related Asana tasks; the advisor gets selected strategic references; the career lab gets test fixtures. Share only the notes each role actually needs. A binding routes an already-admitted channel conversation to an agent; it is not access control.

Before creating any agent

1. Decide each role's real workspace path, audience, and whether its chat history will contain sensitive material.
2. Review effective tools, filesystem/sandbox access, and any shared CLI credentials. In particular, inspect the SOC 2 vault's existing Git and bootstrap-file behavior before allowing OpenClaw to create files there.
3. Write a concise role contract in the workspace's AGENTS.md or extend the existing SOC 2 guide only where OpenClaw behavior requires it. Avoid duplicate instructions.
4. Test with a narrow read-only task, inspect what the agent could access and what it wrote, then deliberately expand authority if needed.

No configuration, agent, channel binding, credential, or automation is created by this document.

Referenced by

• overview