openclaw - 💡(How to fix) Fix [Feature]: First-class org/team deployment — workspace scaffolding, RBAC, and deployment manifests [1 comments, 2 participants]

Summary

First-class support for multi-user org/team deployments: workspace scaffolding CLI, per-session tool policies (RBAC), and declarative deployment manifests.

Problem to solve

Teams and orgs are adopting OpenClaw, but multi-user deployment requires significant manual configuration with no official tooling or guidance. Common patterns emerging in the community:

• One workspace folder per user/function, manually created and maintained
• Per-agent SOUL.md/AGENTS.md hand-configured with no templating
• No access control on which tools/skills a given session can invoke — every session has full tool access
• No way to version-control or reproduce a multi-agent deployment across environments

This means every org deployment reinvents the same scaffolding, and there's no clean separation of concerns between agents that should have different capabilities (e.g. a warehouse agent shouldn't access financial tools).

Proposed solution

1. Workspace scaffolding CLI

A command to initialise a workspace from a template:

openclaw workspace init --template team --agent "sales" --agent "support"

Creates directory structure, base config files, and agent identities in one shot. Reduces per-deployment setup from hours to minutes.

2. Per-session tool policies (RBAC)

Restrict which tools/skills are available per session or agent identity via config:

sessions:
  ceo-private:
    tools: ["*"]
  warehouse:
    tools: ["pharos", "stock_query"]
    deny: ["financials", "hr"]

This closes a real gap for team deployments where different users/roles should have different capabilities.

3. Declarative deployment manifest

An agents.yaml (or similar) that describes a complete multi-agent deployment:

agents:
  - name: production
    soul: ./agents/production/SOUL.md
    tools: ["pharos", "scheduler"]
    channel: telegram-group-12345
  - name: ceo-private
    soul: ./agents/ceo/SOUL.md
    tools: ["*"]
    channel: telegram-dm-67890

Enables reproducible, version-controlled deployments. Spin up identical configurations across clients or environments with a single file.

4. Documented org deployment pattern

Official documentation covering:

• One gateway, multiple isolated agent workspaces
• Telegram forum topics as department/function channels
• Private DM sessions with isolated context
• Recommended directory structure and naming conventions

Alternatives considered

• Manual per-deployment configuration — This is the status quo. It works but doesn't scale; each deployment reinvents the same patterns, and there's no reproducibility or access control.
• External orchestration (Ansible/Terraform wrapping OpenClaw) — Adds infrastructure complexity outside the project. Workspace structure and tool policies are application-level concerns that belong in OpenClaw's config layer, not in external provisioning tools.
• Per-agent config files without a manifest — Solves templating but not reproducibility. A declarative manifest allows diffing, version control, and CI/CD integration that scattered config files don't.

Impact

• Affected: Power users, consultants, and teams deploying OpenClaw for orgs (multiple agents, multiple users/channels)
• Severity: Blocks clean scaling — currently requires hours of manual setup per deployment and offers no access control
• Frequency: Every org deployment hits this — it's not an edge case
• Consequence: Duplicated effort across deployments, no tool isolation between roles, no reproducibility, and a high barrier to entry for team adoption

Evidence/examples

• Community guides already document DIY org deployment patterns (e.g. "One OpenClaw Gateway, Multiple Isolated AI Assistants" on dev.to)
• Related issues: #42981 (per-session tool policies), #43235 (per-agent command lanes), #42686 (per-agent lane isolation) — these address pieces of the same underlying need

Additional information

These enhancements don't change OpenClaw's core "personal AI assistant" paradigm — they formalise patterns the community is already building, reducing friction for the growing segment of users deploying OpenClaw at org scale. Each of the four proposals is independently useful and could be shipped incrementally.