Outworked: a pixel office that gives every Claude Code agent a desk and a role

The office is a real game engine, listed as a dev dependency

The framing is a pixel-art office where agents walk to desks and collaborate in real time, and the implementation detail behind that is worth naming because it explains the install. The office is described as powered by Phaser, and Phaser appears in the development dependencies alongside a native canvas binding, which is the combination you would expect for a small 2D scene rendered inside a desktop window. The build is not pure compilation: the build script first runs a generator that produces the default asset pack, then runs the bundler, so the default sprites and furniture exist as build output rather than being checked in as finished art. That is a sensible arrangement for something cosmetic, and it also means the first build is doing real work. The application entry point is the Electron main process, with Vite building the renderer, so the whole thing is a web app wrapped in a desktop shell rather than a native interface.

Every agent gets full tool access with persistent sessions

This is the line in the feature list that should shape your expectations, and it is stated without hedging: every agent gets full tool access, with shell execution, editing and reading named explicitly, and with persistent sessions that survive between tasks. There is no per-agent permission model described anywhere in the documentation, no read-only role, and no confirmation step before an edit. The practical reading is that an agent in this office is as capable as the underlying coding agent, and that whatever guardrails you would put around a coding session have to be put around this application rather than inside it. That is not a criticism so much as a boundary: the tool is aimed at people already running these agents in a terminal, and the contribution it makes is the orchestration and the visibility layer, not a reduction in blast radius.

Orchestration is a router that turns a goal into subtasks

The four-step description of how it works is short enough to be the whole mental model. You hire agents, giving each a name, a role, a personality, a model and a sprite. You describe a goal in plain English, and an orchestrator breaks it into subtasks and routes them to the right agents without you assigning the work. You then watch the agents walk to their desks and do the work, and the last step is simply letting them finish the workflow. The example workflows show how concrete that routing is, with named roles doing specific things: a frontend developer scaffolding a site and starting a local server, a designer reviewing the result in the built-in browser and asking for a spacing change, a researcher per competitor running in parallel, a writer collecting the findings and committing a document, a project manager triaging issues, and a backend engineer assigned only the bugs that were reproduced. Agents talk to each other through a bracketed mention syntax and a shared message bus.

Scheduled triggers carry the examples more than the chat does

Of the four worked examples, the one that does not depend on you watching is the scheduled task, and the documentation sells it on the maintenance it removes rather than on the model. You tell an operations agent to set up a recurring job, the agent creates a scheduled trigger with a cron expression, and from then on it runs unattended. The documented example is a daily nine in the morning summary of open pull requests:

0 9 * * *

On each run the agent wakes, queries the connected GitHub server for open pull requests, writes a summary and sends it over iMessage. The stated benefit is that there are no scripts to maintain and no scheduled pipeline to debug, and the phrasing is fair: a cron entry inside an agent is easier to change than a job definition, since you change it by talking to it. That does depend on the channel working and the tool server being reachable, so a schedule that silently stops delivering is the failure mode to watch for.

Capability is whatever MCP servers you connect

The capabilities section is really a list of integrations, and that is the honest framing. Out of the box the agents can write and ship code across multiple repositories, browse the web with a built-in browser for research, scraping, forms and screenshots, exchange messages over iMessage and Slack, and run on schedules. Beyond that, capability arrives through the Model Context Protocol: a PostgreSQL server so agents can query a database and generate reports without you writing SQL, a GitHub server for issues and pull requests, Linear for tickets, and anything else with a tool interface, including internal APIs and monitoring dashboards. The version history shows this wiring being improved rather than introduced late, with a release dedicated to improved server wiring and channel reliability. A messaging integration can also trigger work, so a channel can be watched for a keyword and turn into a task.

Asset packs are zip files, with fallthrough when several are installed

Customisation arrived in a single version and has been patched twice since, which is a useful summary of the state. The asset pack system added custom sprites, furniture, backgrounds and fonts, with support for more than one pack and a fallthrough rule, and extended the music player to play tracks the user added rather than only the shipped ones. The two following releases fixed problems with that feature specifically: zip import, directory paths containing spaces, and custom sprite loading. That sequence is a reasonable signal of where the rough edges are, since a cosmetic feature that accepts user-supplied zip archives has the obvious failure modes of path handling and archive format, and all three of those were fixed. The download is an Electron disk image, and the visible release asset is for arm64 only, so there is no published Intel build to fall back on.

Two native modules are rebuilt on every install

The install is heavier than a JavaScript application usually is, and the reason is two native dependencies. A SQLite binding is a runtime dependency, and a canvas binding is a development dependency, and neither ships prebuilt for every platform, so the postinstall script runs a native rebuild against the SQLite module specifically, forcing a rebuild rather than accepting a cached binary. On a machine without a working C++ toolchain that step fails the install, which is the most common reason this kind of application will not install cleanly. The rest of the dependency list is conventional: the Anthropic agent SDK at a 0.2 release, an updater for self-update, an archive library for the asset packs, and then Electron, the builder, the renderer framework, a stylesheet framework, a markdown renderer with syntax highlighting, a UUID library and a bundler. Two of those are at major versions that suggest a recent dependency refresh.

Three releases in two days, then six months of silence

The activity record needs reading as two separate things. There is a burst: a storage and scheduling release that introduced SQLite, iMessage, scheduled triggers, skills and server integration, then a release adding Slack, a triggers interface and reliability work, then the asset pack system, then three patch releases inside two days covering pop-out chat windows and the asset pack fixes. After that, nothing. The last push was on 2026-04-01 and the repository is not archived, so the code is readable and runnable but is not being iterated on. The licence is GPL-3.0-only, which is worth noting for a desktop application people may want to modify, and the package itself is marked private, so there is nothing on a registry and installation is a disk image from the releases page. Given the burst pattern, this reads as a project that got to a working demonstration and stopped rather than one that is winding down.

Editorial conclusion

Outworked is a good fit if the bottleneck is not what your agents can do but whether you can see what they are doing, since a visible office turns an opaque background process into something you can watch and interrupt. Two things to weigh. Every agent is documented as having full tool access including shell execution, editing and reading, with persistent sessions, so the security model is Claude Code's rather than a sandbox of its own, and the project offers no narrower permission story. And the release record stops: three versions landed within two days at the end of March 2026 and the last push was on 2026-04-01, so judge it as a fixed snapshot. The download is an Apple silicon disk image only.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. outworked/outworked on GitHub
4. README
5. Releases