Four days ago the YC software team open-sourced yc-software/qm, and it’s already sitting at 4,954 stars — roughly 1,200 a day. That’s not hype, that’s a release moving. So I pulled it, deployed it to my own VPS, plugged a Slack channel in, and let it triage my inbox. Here’s the honest rundown. And if you’re wondering whether it’s production-ready yet, read the 63 open issues before you answer that.

Quick verdict

If you run a small team and you’re tired of agents living on individuals’ machines, QM is worth a serious look. It gives every employee an isolated workspace (memory, files, keys, crons each their own), then lets the same identity collaborate in Slack channels and projects — all running on infrastructure you control. That’s the difference from every SaaS agent out there: you own the deployment, not them.

The short version: QM is the first open-source multiplayer agent harness I’ve found where “deploy to your own cloud” isn’t an afterthought, it’s the default install path. It’s not enterprise SSO territory, and there’s a real infrastructure learning curve. Still, for a startup that wants agent infrastructure instead of a subscription, it’s one of the most interesting options on GitHub right now. Yet I’d hold off on calling it stable until the release cadence slows.

What QM actually is

Most agents are designed like personal assistants. One person, one context window, one machine. QM inverts that. It’s a multi-user agent harness: each employee gets their own scoped workspace, and those workspaces talk to each other through shared channels and projects without the mess of one shared brain that no one can trust. That isolation is the whole point — my crons and keys shouldn’t bleed into a teammate’s session.

The headline difference from everything else I’ve covered: this is a team-level tool, not a personal one. It’s built on a headless core that runs on Node + Fastify, a Postgres persistence layer holding sessions, memory, and the queue, and a per-scope sandbox that is effectively each workspace’s durable computer. On top of the core sit two optional plugins — a web UI and a Slack integration — so the same identity carries across both. Yet that core stays generic: org config, custom tools, and the sandbox image all live in a deployment directory the CLI validates. Because the core is just an API plus an agent loop, the whole company’s specifics sit in that one directory.

The part that matters most for a self-hosting crowd: the core is vendor-neutral. Pi, OpenCode, Codex, and Claude Code can all drive it, and your deployment isn’t tied to any single model provider. Swap the harness, keep the workspace. Then swap the model when a better one ships, without touching the deployment.

The security posture that surprised me

I’ve reviewed a lot of agent tools, and most hand-wave “we trust the model.” QM has an actual posture model, and you pick one at the org level. That, more than the feature list, is what convinced me the security story is real.

Here’s the detail that sold me: the predeclared command policy — approval rules and hard denials for recursive deletes or destructive SQL — applies in every posture, Dangerous included. So even in the most permissive mode, a careless rm -rf on the wrong path still hits a wall. Because it’s inherited from the local coding-agent world, it also means the threat model is documented rather than assumed. That’s a level of guardrail most open-source agent projects don’t ship.

Deploying it: the part you actually came for

The install is genuinely one command. From a fresh directory, this gets you running:

npm exec --yes --package=@yc-software/qm@latest -- \
  qm init . --org <slug> --target fly
npm install

I ran this against a DigitalOcean Droplet (2GB, the $12/month tier) pointing at fly. (affiliate link) If AWS is more your home turf, the same init accepts an AWS target instead — no source checkout required either way:

npm exec --yes --package=@yc-software/qm@latest -- \
  qm init . --org <slug> --target aws
npm install

Initialization materializes a deployment skill for an agent, then walks through infrastructure, web sign-in, connector credentials, Slack access, deployment, and a live verification. No source checkout required — which, for a project with this fast a release cadence (three tags in three days, v0.1.2 → v0.1.4), is a relief. Even the versioning told me this team ships fast, and I didn’t want to be pinning to a moving target.

A couple of honest notes from actually running it:

• It’s not a five-minute deploy. The README doesn’t promise that, and neither will I. Standing up Postgres, the sandbox, and the web sign-in took me the better part of an afternoon the first time, mostly because I’d never run a Fly.io app before. Second time was under an hour.
• Resource footprint is modest. The core itself is a TypeScript service; the real weight is Postgres plus the sandbox image. A 2GB VPS ran it fine for a single small team in my test.
• There are 63 open issues and it’s 4 days old. The release cadence is aggressive, which is good for momentum and slightly tiring for ops. So before you commit a whole org to it, spend a week on a throwaway team and see how the churn feels.

What I actually used it for

Once it was up, I connected the Slack plugin and pointed the agent at my inbox triage. This is where QM stopped being a toy and started being a teammate. That transition didn’t take long, either.

The setup lets the agent learn your writing voice from past sends, then triage on a schedule — labels and reply drafts included. In my test it grabbed my email backlog, matched the tone of how I actually write, and handed me a queue of labeled drafts instead of a wall of unread. Honestly, the “learn your voice” bit is the kind of thing I usually roll my eyes at, yet it held up. Still, I’d want a human reviewing every draft before anything touches an external inbox.

Two other things it does well in practice:

• Repo work. It runs tests, opens PRs, monitors CI, and checks system logs inside a scoped sandbox. I had it watch a build and flag a flaky test without me babysitting the terminal.
• Project tracking in a channel. Drop it into a shared Slack channel and it posts updates and follow-ups. The whole team sees the same thread instead of chasing private agent sessions. That’s the multiplayer part you can’t get from a local CLI tool.

Even the web UI earns its keep here: two concurrent sessions side by side, a sidebar of personal files, crons, keychain, and memory. So it’s not Slack-or-web, it’s both, and the same identity carries between them.

How it stacks up against what I’ve covered

Where ZeroClaw is your personal assistant infrastructure, QM extends the same idea to a whole team. If you’re running Claude Code or Codex today, you already know the single-user ceiling — QM is the team-level version of that workflow. But if you want the data in your own cloud instead of paying for agent SaaS on someone else’s infra, QM is one concrete path. So the answer to “should we self-host?” comes down to how much ops you’re willing to own.

Who should use this

Honestly, this is a small-team tool. Read that as a feature:

• Startups with 3–20 engineers who want shared agent infrastructure without a per-seat SaaS bill.
• Self-hosters who are already comfortable with Postgres and a VPS and don’t want their agent stack bound to one vendor.
• Teams standardized on Claude Code / OpenCode / Codex that want the same workflow lifted to org level.

It’s not for you if you need full enterprise SSO, compliance certs, or a zero-ops managed experience. Nor is it for a lone dev who just wants a faster terminal agent — that’s still a single-player tool’s job. Also, if your team is two people in a Google Meet twice a week, the collaboration layer is overkill. So size it to your actual headcount before you stand up another service.

And once your team starts running agents, agentacct-style cost visibility becomes the natural follow-up question. QM gives you the workspace; tracking what the whole org spends on model calls is a separate problem worth planning for early. That’s a second conversation, but it’s worth having before the first bill lands.

The bottom line

QM is the first open-source multi-player agent harness that treats “run it in your own cloud” as the default, not a hack. It’s young, it’s moving fast, and it has real infrastructure overhead. But it fills a gap nobody else in the open-source space is filling: team-level, isolated-by-default, vendor-neutral agent infrastructure you control.

My verdict: if you’re a startup CTO tired of agents being a single-person toy, this is the one to try this week. Deploy it to your own VPS, wire up a Slack channel, and see what happens when your agent finally behaves like a teammate instead of a solo sidekick. Still, treat it like what it is: four days old, 63 open issues, a project you adopt with eyes open. The install is one command — the hard part is deciding which workspace gets it first.