OpenClaw Office: a virtual floor plan for watching a multi-agent system work

A front end for a Gateway you have to be running already

OpenClaw Office is the visual monitoring and management front end for the OpenClaw Multi-Agent system. The project description puts the ambition plainly: it turns the collaboration logic of AI agents into a real-time digital twin office.

The mapping it uses is worth knowing because it explains the whole interface. An agent is a digital employee. The office is the agent runtime. A workstation is a session. A meeting room is a collaboration context. Once you hold that mapping, the isometric scene stops being a decoration and becomes a rendering of the runtime's actual state: where each agent is working, which ones are talking, and which sessions are grouped.

The hard prerequisite is stated up front and it is not a detail. You need OpenClaw installed and running, and OpenClaw Office connects to a running OpenClaw Gateway. The documentation is explicit that it does not start or manage the Gateway itself. The runtime prerequisites are Node.js 22 or later, and the OpenClaw project.

The data path follows from that. The real-time communication is a native WebSocket talking to the OpenClaw Gateway, and the server injects configuration into the browser. There is also a Mock mode, which lets you develop the interface without a Gateway at all, and that is the practical escape hatch for front-end work.

So the shape is a companion front end. It is a monitor, a console and a development environment for skills, and it assumes the hard part, the agent runtime, already exists elsewhere.

The office is an SVG scene, and the agents move through it

The virtual office is rendered as a 2D isometric floor plan in SVG, with CSS animations doing the movement. The scene has a workstation area, a temporary workstation area, a meeting area, and a set of furniture including desks and chairs, sofas, plants and coffee cups.

Each agent appears as an SVG avatar generated deterministically from its agentId. That word deterministically matters: the same agent gets the same face on every reload and in every browser, so you learn to recognise the character rather than re-reading a name. The avatars carry live state animations for idle, working, speaking, making a tool call and error, which is the difference between a dashboard that shows a list and one you can read at a glance.

The connections between agents are drawn as collaboration lines representing message passing, and the bubble panels show the real-time Markdown text stream and the tool calls. The side panel is where the numbers live: agent details, a token line chart, a cost pie chart, an activity heatmap, a sub-agent relationship graph and an event timeline.

So there are three layers of information on screen at once, and they answer different questions. The floor tells you the shape of the work right now. The panels tell you what it cost. The timeline tells you what happened. A team that has been watching agents through logs gets the first of those immediately and has to dig for the other two, which is where the value of a rendering like this actually comes from.

The rendering is also responsive, with mobile optimisation that switches automatically to a 2D mode.

Skill Workbench: authoring a skill by talking to the model

The Skill Workbench is the part of the project that distinguishes it from a dashboard, and the readme is direct about that. The claim is that OpenClaw Office turns OpenClaw from a chatbot into a Skills system, where skills are created, modified, debugged and deployed as reusable capabilities rather than retyped into a prompt each time.

The routing is a three-level nested path. The list is at /skill-workbench, the creation wizard at /skill-workbench/create, and the detail view at /skill-workbench/:slug. The development loop is the chat sidebar: you talk to the AI in the sidebar to create or modify a skill, and the file changes synchronise to disk in real time. That is a real difference in approach. A skill is a file, and editing a file through a chat that writes it for you removes the round trip between describing a change and making it.

The flowchart generation is automated and guarded. A built-in guard skill, skill-workbench-mermaid-guard, generates a colour-coded Mermaid diagram to a FLOWCHART.md file that conforms to the project's conventions, in both single and multi-diagram modes. The preview goes entirely through the Markdown rendering path so several Mermaid blocks render in one pass, rather than through a separate diagram renderer.

The A2UI piece is the least conventional. A form is declared as a schema, and an a2ui fenced block inside a chat reply is rendered automatically as an interactive form, with text fields, choices and file upload among the field types, and the submitted form returns to the agent as a structured message. The detail page has an A2UI debugging tab that generates and previews the form in one action.

One more convenience closes the loop. On first entry to the workbench, the embedded server copies the default skills bundled in the npm package into ~/.openclaw/workspace/skills/, so there is no manual installation step to get a starting set of skills.

Running it: one command, then the Gateway credentials

There is no clone step in the quick start. The fastest route runs the published package directly:

npx @ww-ai-lab/openclaw-office

npm install -g @ww-ai-lab/openclaw-office
openclaw-office

The first form is for a one-off run and the second installs the command globally so you can start it later by name. Either way you get a login page in the browser, and that page is where the Gateway connection is configured.

Three values are asked for. The Gateway URL is the Gateway WebSocket address, defaulting to ws://localhost:18789 and pre-filled from configuration the backend injects. The access token is the Gateway authentication token, taken from the gateway.auth.token field of the OpenClaw configuration file at ~/.openclaw/openclaw.json. The password is optional and only applies if password authentication is enabled on the Gateway. The documentation also notes that on a local deployment without authentication enabled you can leave the default URL and the token empty and connect directly.

The command line has its own set of flags for the same settings: -t and --token for the Gateway token, which is detected automatically when omitted, -g and --gateway for the WebSocket address with the same default, -p and --port for the service port with a default of 5180, --host for the bind address defaulting to 0.0.0.0, and -h for help. One caveat is stated: this route runs the prebuilt production version, and hot-reload development is a separate path in the development section.

If you want it running in the background, the service installer registers it with launchd on macOS or systemd --user on Linux, so it starts at login without a command:

openclaw-office service install
openclaw-office service install --token <your-token> --port 3000
openclaw-office service status
openclaw-office service log --follow
openclaw-office service uninstall

The service starts immediately once installed. The status, stop, start and restart subcommands manage it, and there is a Settings panel in the application itself for viewing Gateway status and restarting things without touching the terminal.

Windows gets a WSL2 launcher that wires both halves together

For Windows the project provides a one-click path, because OpenClaw itself does not run natively there. The system requirement is Windows 10 21H2 or Windows 11 with WSL2 and a Linux distribution such as Ubuntu.

Double-clicking start-openclaw-office.cmd performs six steps in order: it detects the WSL distribution and skips docker-desktop, installs Node.js 22 or later and OpenClaw inside WSL if they are not already there, initialises the OpenClaw Gateway configuration and generates a token on first run, starts the Gateway service under systemd inside WSL, starts the Office server as a Node.js process on the Windows host, and opens the browser at http://127.0.0.1:5180.

The split in that list is the important architectural detail. The Gateway runs inside WSL, and the Office server runs on Windows, and the two talk over the WebSocket. That is why the Windows path needs a Linux distribution at all, and why the browser URL is a loopback address rather than a WSL one.

The same script is callable from PowerShell with parameters:

.\scripts\start-openclaw-office.ps1 -OpenClawVersion "2026.3.28" -OfficePort 5180 -GatewayPort 18789
.\scripts\start-openclaw-office.ps1 -Distro "Ubuntu-22.04"

So you can pin the OpenClaw version you test against and pick the WSL distribution to use, rather than relying on whatever is installed.

The container image runs as a non-root user with a health check

The repository ships a Dockerfile and a compose file, and both are worth reading because they show what the server actually needs at runtime.

The image is a two-stage build on node:22-alpine. The builder stage enables corepack and pins pnpm at version 10, installs dependencies with the frozen lockfile, copies the source and runs the production build. The runtime stage creates a group and a user named openclaw, switches to it, and copies only three things from the builder: the dist directory, the bin directory and package.json. The comment in the file explains the reasoning, that no production dependencies are needed beyond Node itself, since bin/openclaw-office.js only uses node:http, node:fs, node:path and node:os. The image exposes port 5180 and the entrypoint is node bin/openclaw-office.js.

That last point is worth pausing on. The server that ships the front end and brokers the Gateway connection is a small Node program with no framework behind it, which is why the runtime image can stay thin.

The compose file runs the published image, ghcr.io/ww-ai-lab/openclaw-office:latest, with a restart policy of unless-stopped and a port mapping of ${PORT:-5180} to 5180. The Gateway address and token come in as environment variables, with the token explicitly meant to live in a .env file rather than being hardcoded, and a commented-out alternative that mounts the local OpenClaw configuration read-only instead. The health check polls the root path with wget every 30 seconds, and extra_hosts maps host.docker.internal so the container can reach a Gateway running on the host.

The front-end build environment is configured through .env.local, following the .env.example file, where VITE_GATEWAY_URL prefills the login form, VITE_GATEWAY_TOKEN is optional because authentication happens in the browser, and VITE_MOCK=true lets you develop without a Gateway.

The console pages, the chat workspace and the slash commands

Beyond the office scene there are two more surfaces, and they cover different needs.

The chat workspace is reached from the top navigation at /#/chat, with a docked bar at the bottom kept as a shortcut. It supports session management with new sessions, history and routing by agent, so several agents can be conversed with in parallel. Replies stream in, with the ability to abort and resend, and the server caches chat history in daily shards, which is what makes the history stable across browsers, devices and page refreshes. Tool calls appear inline in the stream and can be collapsed to see the detail. Slash commands cover /help, /new, /reset, /model, /think and /export. Attachments cover images and arbitrary files, and there are a search, a Markdown export, a focus mode and message pinning.

The console is the administration side, with a page per concern. Dashboard gives overview statistics, alert banners, channel and skill overviews and quick navigation. Agents covers listing, creation and deletion, with a multi-tab detail view for Overview, Channels, Cron, Skills, Tools and Files. Channels holds channel cards, configuration dialogs, statistics and the WhatsApp QR binding flow. Skills is a market with install options and detail pages. Cron manages scheduled tasks and their statistics. Settings covers provider management including adding and editing providers and a model editor, plus appearance, Gateway, developer, advanced, about and update pages.

Two cross-cutting features are easy to miss. Internationalisation is complete in both Chinese and English with runtime language switching, and the console is the more useful of the two surfaces for most teams, since the office scene answers a question about the present while the console answers questions about configuration.

Where OpenClaw Office is the wrong tool

The first limit is the dependency. OpenClaw Office cannot create a multi-agent system, run one, or replace one. It needs a running OpenClaw Gateway, and it needs the OpenClaw project installed. A team that wants to try agent orchestration has to start with OpenClaw itself, and this front end is a second step rather than a first one.

The second is that it is a monitor, so it can only show what the Gateway reports. If a Gateway does not emit token usage or cost data, the pie chart and the line chart stay empty, and the readme does not describe an enrichment layer that would fill them in. The visual richness of the office therefore depends on the telemetry of the runtime underneath, which is outside this project.

The third is the version line. The release list shows v2026.6.2-beta.3 with the note that the Skill Workbench A2UI visual input form system has shipped, v2026.5.10-beta.1 for the Skill Workbench development platform itself, and v2026.4.10 from 2026-04-09. The last push to the repository was on 2026-06-12. The interesting features are on beta tags, the package version in the manifest is 2026.6.11, and the two do not line up, so what you get from npm and what the tags describe are not the same thing. The 2026 format for the version, a date rather than a semver, also means there is no compatibility contract between releases.

The fourth is the credential handling, which is honest but worth reading carefully. The Gateway access token is entered in a browser login form and can be prefilled through VITE_GATEWAY_TOKEN, which is a value that ends up in a front-end build. The compose file pushes you towards a .env file instead, and the front-end configuration comment notes that authentication is completed in the browser. For a local monitoring tool on a laptop that is a reasonable arrangement. For anything exposed on a network, the combination of a token in a browser form and a default bind address of 0.0.0.0 deserves a second look.

The fifth is that the office scene is a reading of the runtime, not the runtime. It shows you sessions as workstations and collaboration as lines on a floor plan, which is a good metaphor for one pattern of agent work and a poor one for a system whose agents are doing something that does not map to a desk.

Editorial conclusion

OpenClaw Office is worth running if you already have an OpenClaw Gateway and you cannot tell what your agents are doing, because the isometric office, the per-agent detail panels and the chat workspace all read from the same live Gateway connection, and because the Skill Workbench moves skill authoring into the chat instead of a separate editor. It is the wrong tool if you do not already run OpenClaw, since it will not start or manage the Gateway, and the wrong tool if you want an agent runtime of your own. Before you install it, check the three things that decide whether it works: that a Gateway is running and reachable at its WebSocket address, with the access token taken from gateway.auth.token in ~/.openclaw/openclaw.json; that the port and host you choose do not collide with anything else on the machine, since the default 5180 and the bind address of 0.0.0.0 are set in the CLI and the container; and the release line, where the newest tag is v2026.6.2-beta.3 and the last push was on 2026-06-12, so the Skill Workbench you are evaluating is still on a beta tag.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. WW-AI-Lab/openclaw-office on GitHub