TL;DR

QM is Y Combinator’s open-source multiplayer agent harness — an agent designed from the start for a company, not a person. Every employee gets their own isolated scope (memory, files, keychain view, crons, sandbox), and every shared room — Slack channel, group DM, project — gets its own scope too. The same agent identity follows you between Slack and the web app.

Key facts (verified 2026-08-27):

  • 14,256 GitHub stars, 1,707 forks, 321 open issues — created 2026-07-29, so under a month old
  • MIT licensed, TypeScript, runs directly on Node with Fastify for HTTP
  • Latest release: v0.1.5 (2026-08-17). Still 0.1.x, and YC calls it an experiment
  • Harness-agnostic: Pi, OpenCode, Codex, and Claude Code all drive the same core
  • Hit #1 on Hacker News with 682 points and 164 comments on 2026-07-31
  • Three security postures — Strict, Auto (default), Dangerous — with a command policy that applies in all three
  • Deploy targets: Docker (local), Fly.io (Fly Machines as agent computers), AWS (ECS Fargate ARM64 + Lambda MicroVM)
  • Contributors include Garry Tan, YC’s CEO, though the bulk of commits come from two people

The interesting claim isn’t that QM is a smarter agent. It’s that the hard problem was never one agent — it was five people’s agents in one company without stepping on each other.

Why This Matters Now

Almost every agent harness we’ve reviewed competes on the single-operator axis. Pi competes on minimalism. DeepSeek Harness competes on extensibility. Apache Maka competes on auditability. Tilde Run competes on sandbox isolation. All of them assume one human at one terminal.

That assumption breaks the moment an agent becomes useful to a team. The README states the problem plainly:

Most agents are designed like personal assistants. You can make one work for a whole company, but it quickly gets complex.

The complexity is real and it’s mostly about scope. If Alice’s agent and Bob’s agent share memory, Alice’s half-finished salary analysis leaks into Bob’s context. If they don’t share anything, the agent is useless in the #eng channel where the actual work coordination happens. If they share a keychain, everyone gets everyone’s credentials. QM’s whole design is an answer to that trilemma: scopes are first-class, and both people and rooms are scopes.

Architecture: One Core, Many Faces

QM’s shape is unusual for an agent project. The core is deliberately generic and headless:

Postgres (sessions · memory · queue)
        ↕
  Headless core
    ├── API · identity · policy · scheduler
    └── Agent loop (Pi, OpenCode, Claude Code, Codex)
        ↕
  Per-scope sandbox (files · tools · logged-in services)

Three things about this are worth pulling out.

1. The tool surface is tiny. The agent gets a small, fixed set of tools. One of them is execute, which runs commands in that scope’s own isolated sandbox — described as its “durable computer, where installed tools stay installed.” Rather than shipping 200 tools, QM ships a persistent machine and lets the agent install what it needs. That’s the same bet Hermes makes, but scoped per-person instead of per-user.

2. Surfaces are plugins. The web UI, the admin panel, and the public portal are optional plugins over the core’s HTTP API. Slack is an in-process plugin that core starts and supervises. You can run QM headless and talk to it entirely through the API, or run just Slack, or just web.

3. Every substrate sits behind an interface. Harness, session store, sandbox, and memory all swap via one wiring file. This is what makes the “pick your own model and harness” claim structural rather than aspirational — a deployment isn’t tied to any single vendor, and in 2026 that matters, because the best-value model changes roughly every three weeks.

The core runs TypeScript directly on Node (no build step for core), Slack uses Bolt, and the web UI builds with Vite and renders with Lit — a genuinely uncommon choice in a React-saturated ecosystem.

Getting It Running

QM’s install instructions are the most 2026 thing in the repo. The README’s entire Setup section reads:

Tell your coding agent of choice Let's deploy https://github.com/yc-software/qm.

That is not a joke. qm init materializes a deployment directory and a deployment skill for an agent to follow. But the CLI path is fully documented if you’d rather drive it yourself:

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

npm exec qm -- check           # validate config, secrets, tools, skills — no network
npm exec qm -- infra render
npm exec qm -- doctor          # read-only check of external prerequisites
npm exec qm -- infra build-image
npm exec qm -- plan            # render the deployment
npm exec qm -- up --yes        # AWS mutation requires the explicit --yes
npm exec qm -- check --live

Provider choice happens at init time, not later — it determines config, secret rules, generated files, and the teardown contract. Changing providers means initializing a fresh directory. That’s a sharp edge worth knowing before you type --target fly.

Configuration lives in .env, and the example file is refreshingly legible:

HARNESS=pi
HARNESS_SECURITY_POSTURE=auto

#ANTHROPIC_API_KEY=sk-ant-...
#OPENAI_API_KEY=sk-...
#OPENROUTER_API_KEY=sk-or-...

ORG_ID=acme
PORT=8080

#SLACK_BOT_TOKEN=xoxb-...
#SLACK_APP_TOKEN=xapp-...

CORE_SIGNING_SECRET=
CAPABILITY_SECRET=
PORTAL_IDENTITY_SECRET=
CONNECTOR_SECRET_KEY=
SKILL_SIGNING_SECRET=

RATE_LIMIT_PER_WINDOW=60
RATE_LIMIT_WINDOW_MS=60000
BUDGET_USD_PER_WINDOW=25
ORG_BUDGET_USD_PER_WINDOW=100
BUDGET_WINDOW_MS=86400000

Note BUDGET_USD_PER_WINDOW and ORG_BUDGET_USD_PER_WINDOW. Per-user and per-org spend caps ship as first-class config, not as a monitoring afterthought. Anyone who has watched a runaway agent loop burn $400 overnight will appreciate that these are in .env.example rather than in a GitHub issue.

The AWS path also does something most deploy tooling doesn’t: up snapshots the RDS instance under the deploy lease before its first mutation, names the snapshot after the deployment manifest it precedes, and records it. Because rollback restores code and configuration only, it then prints the matching data restore point for you. That’s a thoughtful detail from people who have been burned.

The Security Model Is the Real Product

QM’s SECURITY.md is the most honest document in the repo, and it’s where the project’s maturity actually shows. Rather than claiming isolation, it states the goal and immediately disclaims it:

QM is designed to isolate each person’s data and activity by scope. It is early, experimental software: that design goal is not a promise that data cannot leak, a certification, or a substitute for a deployment-specific security review.

An org picks one posture, which narrower scopes can only tighten:

PostureBehavior
StrictEvery harness tool call pauses for human approval, except the two no-effect turn enders
Auto (default)A classifier screens provenance-labelled external data and tool results before they reach the model
DangerousNo content screening, no pauses between tool calls

The predeclared command policy — approval rules and hard denials for recursive deletes, destructive SQL, and similar — applies in every posture, Dangerous included. That’s the right call. “Dangerous” should mean fewer interruptions, not a disabled seatbelt.

Two admissions in the threat model deserve to be quoted, because most vendor security pages would bury them:

An org admin is a privileged content reader, not only a policy administrator. Admin content reads are scope-authorized and audited, but require no additional user approval.

The agent and software it runs in a sandbox are not trusted to make authorization decisions.

The first tells employees exactly what their admin can see. The second is the correct architectural stance — core enforces identity, scope, grants, delivery, and effect gates around the model, because the model is not a security boundary. QM also explicitly states it is not a hardened public or multi-tenant service boundary, and that audit records “support investigation; they do not prevent an action.”

There’s even a section titled “Deliberately portal-only actions,” flagging three capabilities excluded from the agent self-API: “They look like capability-parity gaps in an audit; they are walls, not gaps, and should not be ‘fixed’ without revisiting the reasoning here.” Leaving a note for the future auditor — human or agent — is a nice piece of institutional memory.

What the Community Actually Said

The HN thread hit 682 points, but the top discussion wasn’t about the agent at all. It was about CONTRIBUTING.md, which asks for contributions as human-written text, not code — describe your change informally in a .txt or .md file in adrs/ and the maintainers implement it.

The sharpest criticism came first:

Starting to think people were right when they talked about our industry itself having an AI psychosis problem. — Drupon

And a related jab at the irony:

i find something a bit funny in an ai project, written by ai, requiring human-written text with specific guidance to not use ai. — john_strinlai

But the thread turned. Maintainers with scars showed up:

As someone who has maintained an open source project, I much prefer written bug reports and feature requests to drive-by PRs. — bityard

as a maintainer, seems nicer than getting a slop pr with no context. — meagher

One commenter noted the precedent isn’t even post-AI — SQLite has refused patches from random people on the internet for years. Another articulated the underlying economics well:

because the implementation effort is so low, the only aspect that matters is the quality of the idea. It’s way easier to screen human written text than a bunch of code in a PR. — 2001zhaozhao

And tptacek compressed it to nine words: “The point is that they just want your prompts, not your code.”

Not everyone was persuaded. bakugo: “So, basically, > Please write our prompts for us.” And stefan_ landed a fair hit — the README itself is visibly LLM-generated (“Two skills maintain the boundary in both directions”), while adrs/, the directory of human-written text that’s supposed to drive development, was empty at the time of the thread.

The most useful sub-thread had nothing to do with QM. Someone asked what people actually run org-agents for, and the answers were concrete:

  • automatically fixing simple CI failures
  • getting production alerts and automatically creating RCAs and a fix PR
  • periodically checking slow DB queries and finding ways to speed them up
  • creating charts to answer one-off questions about our data

— supermdguy

Another user runs an agent as first responder for on-call: “It’s not as efficient as coding agent by default, but it’s been tremendously helpful.” That’s the real shape of org-agent value in 2026 — ambient, scheduled, unglamorous work.

Honest Limitations

It’s 0.1.5 and it says so. YC’s own announcement calls it an experiment. 321 open issues on a month-old repo with two primary contributors is a lot of surface area. Open issues at review time include “Run local sandboxes on Docker deployments” and “Fix Docker auth broker private routing” — the local path is not fully settled.

The bus factor is two. ReganBell (118 commits) and 16francej (63) account for essentially all the work. Garry Tan’s single commit is a signal of institutional interest, not engineering capacity.

You cannot contribute code. For some teams that’s a feature; for anyone who wants to fix their own blocker and ship it, it’s a hard stop. You file a .txt and wait.

It is not multi-tenant. QM assumes one organization of authenticated internal users. Guests and external users sit outside the interaction boundary. If you were imagining reselling a QM deployment, read the Scope section first.

Deployment is not lightweight. Postgres, object storage, an identity broker, sandbox infrastructure, and a cloud account you own. There’s no hosted tier — every deployment runs in the operator’s own cloud. That’s a real security advantage and a real ops cost. qm init does not generate deployment CI, and the repo has no production deployment workflow.

The README oversells fluency. As HN noticed, the prose is generated. docs/ is genuinely good, but the marketing layer reads smoother than the software is mature.

Who Should Actually Try This

Good fit: a 5–50 person startup already living in Slack, with an engineer willing to own infrastructure, that wants scoped org memory and scheduled background work without shipping company data to a third-party SaaS agent.

Bad fit: solo operators (use a single-user harness — it’s a fraction of the ops), enterprises needing SOC 2 and a hardened tenant boundary today, and teams without someone who can own Postgres and a cloud account.

The honest framing: QM is a well-designed skeleton with a serious security document and a real deployment story, published by an organization that runs it internally. That last part matters more than the star count. It is not a product you install this afternoon and forget.

FAQ

Is QM free and open source? Yes — MIT licensed, with the source on GitHub at yc-software/qm. There is no hosted tier and no paid version. You pay for your own cloud infrastructure and your own model API usage, which is why per-user and per-org USD budget windows ship in the default config.

Which models and harnesses does QM support? Pi, OpenCode, Codex, and Claude Code all drive the same core, selected via the HARNESS environment variable. Model credentials come from ANTHROPIC_API_KEY, OPENAI_API_KEY, or OPENROUTER_API_KEY — OpenRouter support means effectively any model it proxies. An admin sets which harnesses and models are available org-wide.

Do I need Slack to use QM? No. Slack is an optional in-process plugin. The web UI, admin panel, and public portal are separate optional plugins over the core HTTP API, so you can run web-only, Slack-only, both, or neither and drive core directly. That said, the shared-room scoping — where the multiplayer design earns its name — is most natural in Slack channels.

How does QM stop one employee’s agent from reading another’s data? Core resolves a principal and scope for every turn, separates scope workspaces, uses signed ingress and capability tokens, applies grants and audience checks, and records security-relevant actions. Critically, the agent and its sandbox are not trusted to make authorization decisions — enforcement lives in core, around the model. QM’s own SECURITY.md notes these controls reduce cross-scope access but are “not a formal non-interference proof.”

Is QM production-ready for my company? Not without your own review. It’s at v0.1.5, roughly one month old, with 321 open issues, two primary contributors, and an explicit self-description as experimental software. Run it for internal, non-critical workflows first — CI triage, alert summaries, scheduled digests — and keep the Auto or Strict posture on while you build confidence.

How is this different from just running Claude Code for the whole team? Claude Code is a single-operator coding harness: one person, one machine, one context. QM is the layer above that — identity, per-scope memory and keychains, shared rooms, crons, webhooks, budgets, audit, and admin policy — and it can use Claude Code as its execution engine. They’re complementary, not competing.

Sources