QM turns workplace agents into scoped shared workspaces, not one shared assistant

QM is a workplace agent harness built around a simple but important distinction: a company agent should not behave like one personal assistant stretched across an organization. Its README describes a model where every employee gets an isolated workspace, while Slack channels, group messages, and projects can also become shared rooms where people collaborate with the agent.

Each person and each room carries its own scoped memory, files, keychain view, permissions, crons, web apps, and durable sandbox. That makes the project less about a new model benchmark and more about the operating boundary around agents. QM says Pi, OpenCode, Codex, and Claude Code can drive the same core, so a deployment can switch harnesses and models without binding the company to one vendor.

The architecture follows that premise. A Postgres layer stores sessions, memory, and queue state. A headless TypeScript core handles identity, policy, scheduling, and the agent loop. Tool execution happens inside the relevant scope’s sandbox, so installed tools and working files persist for that person or room. Slack, the web UI, the admin panel, and a public portal sit as plugins over the core HTTP API.

The HN discussion dug into whether “multiplayer” is meaningful here or just product vocabulary. Skeptics asked what is uniquely useful compared with prompts plus tools. Supporters focused on the per-person scope and shared-room model as a practical answer for a company-wide assistant, especially when the agent can search internal notes, email, documents, databases, and repositories, then continue background work through watches and crons.

Security is one of the clearer signs that QM is aimed at deployment rather than demos. Organizations choose a posture: strict approval for most tool calls, an auto mode with screening, or a dangerous mode with fewer interruptions. A command policy still blocks or gates destructive operations. The project’s real bet is that workplace agents become useful only when memory, permission, audit, and execution boundaries are first-class parts of the product.