YC ships qm, a multiplayer agent harness for Slack and web

YC has released qm, an open source "multiplayer agent harness for work" that runs inside Slack and as a standalone web app, published under the yc-software GitHub organization. Most agent products are built like a single personal assistant; making one serve an entire company gets complicated fast. qm instead gives each employee an isolated agent workspace, with its own scoped memory, files, keychain view, permissions, crons, web apps and a durable sandbox, so people work independently without affecting each other. The same employees can also collaborate with the agent inside shared Slack channels, group messages and projects, and every room, not just every person, gets its own scoped memory and permissions.
Every turn runs through one headless core written in TypeScript on Node with Fastify for HTTP: an API and identity, policy and scheduler layer paired with an agent loop that can run on Pi, OpenCode, Codex or Claude Code. A Postgres layer holds session history, memory and other durable state, and the agent's small, fixed tool surface includes an execute tool that runs commands inside the scope's own isolated, durable sandbox, where installed tools stay installed. The web UI, built with Vite and rendered with Lit, the admin panel and the public portal are optional plugins over the core's HTTP API, and Slack is an optional in-process plugin, built with Bolt, that the core starts and supervises directly. Everything specific to one company (org configuration, custom tools and skills, the sandbox image, infrastructure) lives in a separate deployment directory that the qm CLI validates and deploys, and every substrate (harness, session store, sandbox, memory) sits behind an interface so a production deployment can swap implementations through one wiring file.
An organization picks one of three security postures, and any narrower scope inside it can only tighten the rules, never loosen them. Strict pauses every harness tool call for human approval, with the sole exception of two no-effect turn-ender calls. Auto, the default, runs a classifier over provenance-labelled external data and tool results before they reach the model, and a deployment can point that classifier at its own screening proxy. Dangerous applies no content screening and no pauses between tool calls at all. A separate, predeclared command policy, covering approval rules and hard denials for actions such as recursive deletes or destructive SQL, applies in every posture, Dangerous included. The design follows local coding agents such as OpenCode, Codex and Claude Code: the agent acts as the person it works for, with that person's own credentials and permissions, and everything it does is audited.
Two ways to deploy exist. Running the qm CLI's init command (npm exec against the published package, with an org slug and a Fly or AWS target) creates an organization-owned deployment repository and walks through infrastructure, web sign-in, connector credentials, optional Slack access, deployment and live verification, with no source checkout of qm itself required; each deployment then runs inside the operator's own cloud account, and initialization neither generates nor enables any production deployment CI. Organizations that instead want engineers and coding agents to read the core and their own customizations together can keep a private fork: create it with a plain bare clone and a mirror push into a new private repository, never with GitHub's Fork button, because a fork of a public GitHub repository cannot be made private and shares one object network with the public original. Everything specific to the organization then lives under a dedicated per-org layers folder, while the core stays byte-identical to upstream, and two maintenance skills keep the boundary: one merges upstream changes into the private fork, and the other sends organization-agnostic fixes back to the public project after checking the diff, commit messages and screenshots for organization identifiers. The trade-off of the plain-clone approach is that upstream's own CI workflows then run live in the adopting organization's cloud account, so its secrets must be supplied or the unwanted workflows disabled.
The project takes contributions as human-written text rather than code: contributors describe a desired change informally in a text or markdown file, and the maintainers implement it themselves if they agree with the direction. Vulnerabilities are to be reported privately rather than filed as a public issue. qm is released under the MIT License, except where a file states otherwise. The Hacker News submission, posted by user tosh, had reached 634 points and 146 comments about 24 hours after posting; the source gives no pricing, hosting-cost, user-count or adoption figures, and names no individual founders, funding, revenue or headcount for the project.
Key facts
- Each employee gets an isolated agent workspace with its own memory, files, keychain view, permissions, crons and durable sandbox, and can still collaborate with the same agent in shared Slack channels, group messages and projects.
- Pi, OpenCode, Codex and Claude Code all drive the same underlying core, so a qm deployment is not locked to a single agent vendor.
- Three security postures apply org-wide, and narrower scopes can only tighten them: Strict pauses every harness tool call for human approval except two no-effect turn-ender calls; Auto, the default, screens provenance-labelled external data and tool results with a classifier before they reach the model; Dangerous adds no content screening and no pauses.
- A predeclared command policy, with approval rules and hard denials for actions like recursive deletes or destructive SQL, applies in every posture, including Dangerous.
- Two deployment paths exist: a generated deployment repository via the qm CLI's init command that needs no source checkout of qm itself, or a private fork made by plain clone and mirror push, never GitHub's Fork button, since a fork of a public repository cannot be made private.
Why it matters
Most agent products are built like a single personal assistant, and scaling one assistant to serve a whole company quickly gets complex. qm's pitch is per-scope isolation on top of shared infrastructure: every employee and every room gets its own scoped memory, files, permissions and sandbox, yet all of it runs through one core that is not tied to a single agent harness or model, since Pi, OpenCode, Codex and Claude Code can all drive it. That combination, personal and shared scopes plus vendor neutrality, is what distinguishes qm from a single company-wide bot.
Who it affects
Startups that want an agent deployed across the whole company rather than as one individual's assistant; engineering and ops teams who pick a security posture and a backing harness or model; admins who set org-level configuration and decide which harnesses and models are available; and anyone contributing to the project itself, since changes are taken as plain-text descriptions rather than submitted code.
How to use it
Deploying runs the qm CLI's init command through npm, passing an organization slug and a Fly or AWS target; that creates an organization-owned deployment repository and walks through infrastructure, web sign-in, connector credentials, optional Slack access, deployment and live verification, with no source checkout required, and each deployment runs in the operator's own cloud account. Organizations that want a single codebase instead keep a private fork made by plain clone rather than GitHub's Fork feature, then use two maintenance skills to merge upstream changes in and send organization-agnostic fixes back out. qm is released under the MIT License; no pricing or hosting-cost figure is given for running a deployment.
How solid is it
The retelling rests on qm's own README and documentation, self-published under the yc-software GitHub organization. The Hacker News submission, posted by user tosh, reached 634 points and 146 comments in about 24 hours, but that popularity is not independent verification. No user or customer numbers, no benchmark or comparison against other agent-harness or Slack-bot products, and no named individual founders, funding, revenue or headcount figures accompany the release; the repository does document its own threat model and known limitations separately.
Risks and caveats
The Dangerous security posture explicitly removes content screening and pauses between tool calls, and it is on an adopting organization to actively choose the safer Strict or Auto posture instead, though the predeclared command-policy denials still apply even in Dangerous mode. Because qm has the agent act as the person it works for, with that person's own credentials and permissions, a mis-set scope or an unscreened Dangerous deployment could let the agent take destructive actions with a real employee's access. No security incident or deployment failure is described; the posture and threat-model text is presented as design, not as a response to any past event.
“Pi, OpenCode, Codex, and Claude Code all drive the same core, so a deployment isn't tied to any single vendor.”
— qm project README