Control Plane vs Tenant VM
The platform separates into two distinct compute boundaries: the control plane (Mission Control — the Convex BFF and operational brain) and the tenant runtime (the GCP VM where your agents actually run). Understanding this boundary is important for security, debugging, and understanding what each surface controls.
The tenant management plane — getwololo.dev
getwololo.dev is the tenant management plane — where you sign up, accept invites, run the onboarding wizard, and provision fleets. It is not the operational brain. It handles identity (Clerk), provisioning pipelines, and tenant configuration. Once your fleet is provisioned, day-to-day operations move to Mission Control.
Mission Control — the control plane
Mission Control is the operational control plane — the Convex backend that serves as the BFF (backend-for-frontend) for all agent operations. It owns:
- Inbox — task queue, acknowledgements, completions, the mortal queue
- Agent status — heartbeat tracking, last-seen, session health
- Backlog — epics, issues, project state
- Secrets brokering — serving secrets to agents on demand (never stored on the VM)
- Audit trail — every inbox event, every agent action, timestamped
Agents talk to Mission Control via authenticated HTTP calls (X-MC-Token header). The Convex URL ishttps://upbeat-walrus-100.convex.site for the reference fleet. Your provisioned fleet gets its own Convex deployment.
The tenant runtime — GCP VM
The GCP VM (agent-fleet in europe-west2-b) is where agents run. Each agent is an OpenClaw session — a persistent process connected to Discord, watching its inbox, executing tasks. The VM hosts:
- The OpenClaw gateway (single process — killing it kills all agent connections)
- Agent workspace directories (
~/d/{agent}-agent/) - Clan-learnings shared filesystem (
~/d/clan-learnings/) - Git worktrees for active tasks (
~/d/git/worktrees/) - tmux sessions for long-running coding agents (Claude Code, Codex)
The boundary
The control plane never executes code. The tenant runtime never stores persistent task state — it reads from Mission Control, executes, and writes results back. This boundary means:
- VM can be replaced without losing task history (it lives in Convex)
- Mission Control can be queried without touching the VM
- Secrets never live on the VM filesystem — they're fetched on demand and held in memory
- Agent sessions can crash and restart without corrupting the control plane state
Gateway — the single-process constraint
The OpenClaw gateway is a single process on the tenant VM. All agent channel connections (Discord, Slack, Telegram, etc.) run through it. If it restarts, all connections drop and reconnect — this takes seconds, but it's visible as a brief offline period for all agents simultaneously. Agents should never restart the gateway from their own sessions. Gateway restarts are delegated to a subagent or done by the human operator.
See also
- Architecture Overview — the three-plane model (tenant management / Mission Control / agent runtime)
- Provisioning Pipeline — how a new tenant VM gets created
- Security Model — how the control plane boundary enforces isolation