Summary

An Agents Plane — an infrastructure layer that lets organizations deploy isolated AI agents for team members. Each agent gets its own VM, service account, secrets, and network isolation. This is essentially "OpenClaw for Teams."

Motivation

Today, deploying OpenClaw agents for a team is manual: spin up a VM, install OpenClaw, configure secrets, set up channels — repeat per person. There's no unified way to provision, manage, or enforce isolation across a fleet of agents. Organizations need:

• One command to provision an agent for a team member
• Zero-trust isolation between agents (no shared secrets, no shared network)
• Admin oversight without admin access to individual agent secrets
• Cost visibility per agent

Related Issues & PRs

• feat: GCP Secret Manager integration for external secrets management #16663 — GCP Secret Manager integration (per-agent secret scoping is foundational)
• feat: Agent Thinking Clock — periodic reflection with multi-model orchestration #17287 — Thinking Clock (each agent gets its own reflection cycle)
• Platform prerequisites for multi-agent per-org isolation #10004 — Platform prerequisites for multi-agent per-org isolation
• memory-lancedb: add per-agent memory isolation (agentId scoping) #15325 — Per-agent memory isolation (agentId scoping)
• feat: Sysbox Docker Runtime for Secure Container Isolation (Host Maintenance Required) #7575 — Sysbox Docker runtime for secure container isolation
• [Feature]: Add a secure way to pair dynamically autoscaled worked nodes in K8s #12429 — Secure pairing for dynamically autoscaled worker nodes in K8s
• Feature Request: Multi-user permission management with role-based access control #8081 — Multi-user permission management with RBAC
• [Feature Request] Unified Built-in Sandbox with Multi-Platform Support and Tiered Presets #12505 — Unified sandbox with multi-platform support
• Critical: Default configuration provides zero isolation - users have unrestricted filesystem access and plaintext credentials #7139 — Default config provides zero isolation
• [Critical Bug]: Session Isolation Leak #12571 — Session isolation leak

Proposed CLI

# Create a plane (admin)
openclaw planes create --name "acme-agents" --project gcp-project-id --region us-east4

# Provision agents for team members
openclaw planes add-agent --plane acme-agents --name alice --owner alice@acme.com --vm-type e2-small
openclaw planes add-agent --plane acme-agents --name bob --owner bob@acme.com --vm-type e2-small

# Manage
openclaw planes status
openclaw planes remove-agent --plane acme-agents --name alice
openclaw planes logs --plane acme-agents --name bob

What Gets Provisioned Per Agent

Deployment Model Comparison

Recommendation: Start with VM-per-agent (simplest, strongest isolation). Add K8s support later for organizations at scale.

Security Model

• Zero trust between agents — no agent can access another's VM, secrets, or network
• SSH via IAP only — no SSH keys on disk, all access audited
• Per-agent service accounts — each can ONLY access its own Secret Manager secrets
• Admin audit without secret access — separation of duties (admin sees metrics/logs, not secret values)
• Network isolation — agents cannot reach each other's ports; egress controlled per policy

Architecture

┌─────────────────────────────────────────────┐
│              Agents Plane (admin)            │
│  ┌─────────┐  ┌─────────┐  ┌─────────┐     │
│  │ Agent A  │  │ Agent B  │  │ Agent C  │    │
│  │ (alice)  │  │ (bob)    │  │ (carol)  │    │
│  ├─────────┤  ├─────────┤  ├─────────┤     │
│  │ SA: a@   │  │ SA: b@   │  │ SA: c@   │    │
│  │ Secrets  │  │ Secrets  │  │ Secrets  │    │
│  │ VPC/FW   │  │ VPC/FW   │  │ VPC/FW   │    │
│  │ IAP→alice│  │ IAP→bob  │  │ IAP→carol│    │
│  └─────────┘  └─────────┘  └─────────┘     │
│                                              │
│  Shared: VPC, Cloud NAT, monitoring, billing │
└─────────────────────────────────────────────┘

Open Questions

1. IaC tooling — Terraform/Pulumi for declarative infra, or pure gcloud CLI for simplicity? Terraform is more portable for multi-cloud.
2. Multi-cloud — GCP first (we're already there), but the abstraction should allow AWS/Azure later. How tightly do we couple to GCP APIs?
3. K8s vs VMs — Should we support GKE from day one, or add it as a second backend later?
4. Billing/cost tracking — GCP labels per agent for cost attribution? Or a built-in usage tracker?
5. Channel provisioning — How do we automate WhatsApp/Telegram setup per agent? (WhatsApp Business API requires phone numbers)
6. Agent updates — Rolling updates across a plane? openclaw planes upgrade --plane acme-agents?
7. State & backup — Agent workspace snapshots? Memory export/import for migration?

Scope

This is a large feature. Suggested phases:

1. Phase 1: planes create + add-agent with VM-per-agent on GCP, Secret Manager isolation, IAP access
2. Phase 2: Admin dashboard, cost tracking, agent health monitoring
3. Phase 3: K8s backend, multi-cloud support
4. Phase 4: Self-service portal for team members, channel auto-provisioning