# agent-office: a shared 3D office for coding agent workers

> agent-office is a cartoon 3D office where each of your GitHub repositories becomes a floor, each coding agent becomes a worker at a desk with a live terminal, and issues and pull requests hang on cork boards. It is a work in progress by its own warning, it changes fast between releases, and it installs with a single curl line that puts an agent-office command on your PATH.

**AgentSystemLabs/agent-office** — A cartoon 3D office where your team hires Claude Code workers at desks, shares live terminals, talks over voice, and tracks GitHub issues and PRs.

- Repository: https://github.com/AgentSystemLabs/agent-office
- Stars: 799 · Forks: 225
- Language: TypeScript
- License: MIT
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/agentsystemlabs-agent-office

## A floor per repository, a desk per agent

agent-office is described as a cartoon 3D office where your team spawns coding agent workers at desks, shares live terminals, talks over voice, and tracks GitHub issues and pull requests. The office sits between you and the agent CLIs, and the metaphor is carried through with some consistency.

The first thing you do is choose a project. Ride the elevator, pick one of your GitHub repos, and the office clones it, showing how far along it is, and opens a floor for it. Every worker, board, and queue on that floor works in that checkout. So the building is organised by repository, and the vertical structure is a way of navigating between projects rather than decoration.

The second thing is the desks. Walk up to an empty desk, press E, and pick from Claude Code, Codex, OpenCode, Grok, Muse, DeepSeek Harness, Pi or Cursor, each with its model and reasoning effort. The agent's live terminal shows on the laptop in front of it, and anyone can open it and type.

That last clause is the collaborative core of the project. A worker is not a background process you poll, it is a terminal on a desk that a human can take over and type into. That is a different relationship with an agent from sending a prompt and waiting for a result, and it is the reason the office is described as something a team shares.

The features list also mentions voice, chat, screen sharing on the lounge TV, and a shared whiteboard, so the office is a meeting place as well as a work floor. There is a rooftop bar, an office dog, an arcade, and supercars in the garage to drive around a scenic loop past a farm, pines, mountains, and a beach.

The maps are configurable, which is the more interesting feature of the three dimensional layer. The whole building can be turned into a castle, with a throne of iron blades and workers lining up when they are done, or into a space station in orbit with the Earth turning outside the windows, and you can make a map of your own with its own way of seeing workers off, described in JSON in docs/maps.md.

## One curl line, and three questions on first run

The installation is the shortest possible one, and it is worth reading the warning at the top of the README before you run it.

```bash
curl -fsSL https://raw.githubusercontent.com/AgentSystemLabs/agent-office/main/install.sh | bash
```

On Windows there is a PowerShell equivalent that downloads install.ps1 and runs it with iex, and the repository carries both scripts. The installer puts an agent-office command on your PATH, so the next time you just run agent-office, and you run the install line again to update. The settings of the installer, such as choosing a particular release or installing without starting, are listed at the top of the two script files.

The requirements are short. Node.js 20 or newer on the machine that runs the office, at least one agent CLI signed in as the user that runs the office, and git with the GitHub CLI authenticated with gh auth login, which is what the clone step and the issue and pull request boards depend on. The list of agent CLIs is long, and it names the binaries directly: claude, codex, opencode, grok, muse, dsh for DeepSeek Harness, pi at 0.87.1 or newer, and the Cursor CLI, cursor-agent. There is also a route for people who do not want to sign in on the server at all, since with accounts everyone can sign in to their own Claude from the office instead.

The first time it starts, the office walks you through setup in the terminal, and there are three questions. First, where to clone your projects. It suggests a code folder you already have, such as ~/Workspace or ~/code, and otherwise ~/agent-office, and each project goes into a folder named for the owner and the repository. Second, GitHub: if the GitHub CLI is not signed in, it offers to run gh auth login for you. Third, your first project, picked by number from a list or typed as owner/name, which the office clones as the first floor.

Any step can be skipped by pressing Enter, and the elevator in the office asks for the answers later if you skipped them.

Beyond running it locally, the README lists deployment targets for AWS EC2, Azure, Railway, Fly.io, Dokploy, Coolify, and any Ubuntu or Debian server, plus sections on adding users and on the controls.

## Beacons, banners, and voice input through the browser

The hardest part of supervising several agents at once is not starting them, it is knowing when one of them needs you. The project has three answers to that, and the second one is the most useful idea in the whole feature list.

The first is the attention system. A worker that stops to ask you something lights a red beacon over its desk, puts a banner on your screen saying who and what for, and sounds an alarm. A worker that has finished jumps up and down and dings. And pressing N takes you straight to whoever is waiting. In a session with six agents running, that is the difference between supervising and supervising by watching six terminals.

The second is voice. Hold Ctrl+Space, or press the microphone button, in a worker's terminal or in a prompt box, say what you want, and it is typed in for you to send. The detail that makes this work is in the implementation note: your browser does the listening, so there is nothing to install.

That is a real constraint with a real benefit. The browser speech recognition API is available in the page you are already looking at, so the feature works on any machine with a modern browser and no native dependency, at the cost of accuracy and of the fact that the browser has to be told to listen.

The third is the mobile path. The /lite route is the office in 2D: every worker and what it is waiting on, its terminal with the keys a phone keyboard lacks, and the boards. The 3D office offers the same route on a phone or on a slow computer.

That last detail matters more than it sounds. A 3D scene is expensive to render, and a phone is a bad place to run one, so the project ships a two dimensional fallback that covers the same information, and it is the same information rather than a subset, which means a worker waiting for you is still visible when you are away from the desk.

## Cork boards, worktrees, and one task across several projects

GitHub is not a separate dashboard in this design, it is part of the room. Issues and pull requests hang on cork boards, and the interaction model is physical: hand an issue to a worker, queue tasks, give a worker its own git worktree and open its pull request with one key.

The worktree detail is the one that shows the design has been tested against reality. Giving each worker its own worktree is what lets several agents work on one repository at the same time without fighting over the working directory. And the failure mode is handled explicitly, which is the part that matters: if a worktree gets deleted behind the office's back, the worker waits at its desk until you rebuild it, rather than silently working in the wrong place or losing your changes.

One task can also span several projects. The worker gets a worktree of each, and a pull request in each that links the others. For a change that touches a shared library and two services, that is a genuinely useful arrangement, because the branches and the links are set up before the agent starts rather than assembled afterwards by a human.

The agents also manage each other, and this is the part that is unusual enough to be worth reading twice. Every worker can list, hire, message, and send home the others, through an agent-office MCP server for Claude Code, Codex, and OpenCode, or through the office-workers command. You can ask one to send everyone whose pull request merged home, and it does, deleting their worktrees and branches unless they hold unpushed work.

That last clause is the safety rail. Sending an agent home means destroying its worktree and its branch, so the operation refuses to discard unpushed work, which is exactly the case where you would lose work. And a worker that opens its pull request itself shows it at its desk, while one the office missed can be told which pull request is its own with the office-workers pr command.

## The stack, and the build that produces the office

The package metadata describes the technology choices, and they are all aimed at one problem, which is streaming terminal output to a browser and rendering a scene at the same time.

The runtime dependencies are five.

```json
  "dependencies": {
    "@lydell/node-pty": "^1.2.0-beta.15",
    "@xterm/addon-serialize": "^0.14.0",
    "@xterm/headless": "^6.0.0",
    "selfsigned": "^5.5.0",
    "ws": "^8.21.3"
  },
```

The pseudo terminal library is what runs the agent CLIs, since a coding agent is an interactive program and it needs a terminal to be driven properly. The headless xterm build is the terminal emulator, rendered into the browser rather than into a window, with the serialize addon for capturing what is on the screen. The WebSocket library carries the terminal and the office state to the browser, and selfsigned generates a certificate so the page can be served over TLS, which matters because the browser microphone and other capabilities want a secure context.

On the front end, the dependency list names the renderer and the editing surface plainly: three for the 3D office, React and React DOM for the interface, the xterm packages for the terminal views, Excalidraw for the shared whiteboard, and marked with DOMPurify for rendering markdown safely. Playwright is there for the tests, and the dev server is Vite with TypeScript 7, and the server is compiled separately with tsc using its own tsconfig, which is why the repository carries a tsconfig for the base, the client, and the server.

The test script is worth noting for the detail it reveals, since it runs the node test runner through tsx with a custom import mapping for the CSS support module and a glob over the test files. The dev script runs the Vite client and the server watcher at the same time, on port 4600 with a dev password and the no-open flag, which is the whole development loop in one line.

## A work in progress, released many times a day

The warning at the top of the README is the first thing in the document and it is unusually blunt, so it belongs in any assessment of this project.

It says the project is a work in progress, built for one person's workflow, namely the author's, and that it changes fast as they iterate on it. It says to expect breaking changes between releases: keys that move, screens that get redrawn, features that come and go without notice. And it says that if it is close to what you want, fork or clone it and bend it into what you need it to be.

That is not a disclaimer, it is a usage model. The project is offering itself as a starting point rather than as a dependency, and the recommendation to fork is a signal about the kind of engagement it expects.

The release history is consistent with that. The three most recent releases are v0.1.211, v0.1.210, and v0.1.209, and all three are dated on 2026-10-09, within a few hours of each other, with the last push to the repository on the same day. A version number in the low hundreds of patches, released several times in a single day, tells you that this is a personal tool being iterated on, not a package with a support commitment.

There is more in the repository than the README shows, which is a good sign for anyone who wants to extend it. There is a bin directory with the command entry point, a src directory, a blender directory, which is where the 3D assets are likely produced, a deploy directory, a docs directory holding the features, how it works, and maps documentation, and a tests directory. There are also AGENTS.md and CLAUDE.md files at the root, which is what you would expect from a project that is itself built with coding agents, and that is worth noting in itself: the tool is a good example of its own subject.

## Conclusion

agent-office fits one developer or a small team who runs several coding agents at once and wants to see them working, share their terminals, and hand them issues without switching windows, and who are prepared to fork it rather than depend on it. It does not fit a team that needs a stable contract, because the project states plainly that it changes fast and expects breaking changes between releases, and it does not fit a machine without a signed-in agent CLI, since a worker is a running CLI in a terminal. Verify first that you have Node 20 or newer, an agent CLI already signed in as the account that runs the office, and the GitHub CLI authenticated, and that the release you install matches the keys and screens you are following in the documentation.

## FAQ

### How do I install agent-office?

Run the install line, which downloads install.sh and pipes it to bash, and it puts an agent-office command on your PATH. On Windows there is a PowerShell script, install.ps1. Running the install line again updates the installation, and the installer options, such as a particular release or installing without starting, are listed at the top of the scripts.

### What do I need before agent-office will run?

Node.js 20 or newer, at least one agent CLI already signed in as the user that runs the office, such as claude, codex, opencode, grok, muse, dsh, pi or cursor-agent, and git with the GitHub CLI authenticated through gh auth login for cloning repositories and the issue and pull request boards.

### How do the GitHub issues and pull requests work in agent-office?

Issues and pull requests hang on cork boards in the office. You can hand an issue to a worker, queue tasks, and give a worker its own git worktree with one key to open its pull request. A worker whose worktree is deleted behind the office's back waits at its desk until you rebuild it, and one task can span several projects with a linked pull request in each.

### Can one agent manage the other agents in agent-office?

Yes. Every worker can list, hire, message, and send home the others, through the agent-office MCP server for Claude Code, Codex, and OpenCode, or through the office-workers command. Sending someone home deletes their worktrees and branches unless they hold unpushed work.

### Is agent-office stable enough to depend on?

The project says it is a work in progress built for one person's workflow, that it changes fast, and that you should expect breaking changes between releases, with keys that move and features that come and go. The README suggests forking or cloning it if it is close to what you want, and the recent releases show several versions published on the same day.

## Sources

- [AgentSystemLabs/agent-office on GitHub](https://github.com/AgentSystemLabs/agent-office)
- [Issues](https://github.com/AgentSystemLabs/agent-office/issues)
- [License: MIT](https://github.com/AgentSystemLabs/agent-office/blob/main/LICENSE)
- [README](https://github.com/AgentSystemLabs/agent-office/blob/main/README.md)
- [Releases](https://github.com/AgentSystemLabs/agent-office/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/agentsystemlabs-agent-office