qm: the agent harness yc runs their company on

QM is a multiplayer agent harness. Y Combinator built it to run their own company, then MIT-licensed the whole thing at github.com/yc-software/qm. Accounting, legal, and engineering at YC all run through it, and the QM team uses QM to build QM. It's at 9,700+ stars within days of release.

"Multiplayer" is the load-bearing word. Claude Code, Codex, and OpenCode are single-player: one person, one terminal, one context. QM is what happens when a whole team shares the same agents. Everyone gets an isolated workspace with their own memory, files, keychain, and sandbox, and the same agents also show up in Slack channels and group projects where the context is shared.

the problem nobody talks about

Personal agents don't scale past one person. You can bolt a company onto a personal assistant, but every integration becomes a special case: whose credentials does it use, who can see which files, what happens when two people ask it to do conflicting things in the same repo.

I know because I hand-rolled a single-player version of this over the past month. An email triage agent on a cron, a state layer in markdown files, a supervisor agent that QCs the others. It works, for exactly one user, and every new capability was a night of duct tape. QM ships that whole pattern out of the box, scoped for a team.

The commercial alternatives run thousands per month and mostly cap out at chatbots with retrieval. QM is closer to an operating system for agents: per-scope sandboxes, a permission model, crons, and an audit trail.

why this changes everything

It's harness-agnostic. Pi, OpenCode, Codex, and Claude Code all drive the same core. Your deployment isn't married to one vendor's model or agent loop; you switch harnesses in config, not in a rewrite.

Scoped everything. Each person and each room gets its own memory, files, keychain view, permissions, crons, and a durable sandbox where installed tools stay installed. Two people can't stomp on each other's state.

Slack-native, web-optional. The same identity and configuration carries between Slack and the web app. Your team doesn't adopt a new tool; the agents move into the room where work already happens.

Background work is first-class. Crons and watches run while nobody's watching: inbox triage on a schedule, CI monitoring, project channels that post their own follow-ups.

Security postures are explicit. An org picks one of three postures, and narrower scopes can only tighten it: Strict (every tool call pauses for human approval), Auto (a classifier screens external data before it reaches the model), and Dangerous (no screening, no pauses). A predeclared command policy with hard denials for things like recursive deletes applies in every posture, Dangerous included.

The stack is boring on purpose: TypeScript on Node, Fastify for HTTP, Postgres for persistence, Bolt for Slack, Vite and Lit for the web UI.

step 1: understand the deployment model

There is no hosted version. QM runs in your own cloud account (Fly.io or AWS), and everything specific to your org lives in a deployment directory that the qm CLI validates and deploys. The core stays generic; your config, custom tools, skills, and sandbox image sit in your own repo that depends on @yc-software/qm as a package. No source checkout required.

step 2: initialize the deployment repo

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

qm init materializes a deployment skill for a coding agent and walks through infrastructure, web sign-in, connector credentials, optional Slack access, deployment, and live verification.

step 3: let your coding agent drive

This is the part that got the install its reputation. The materialized deployment.md is written to be followed by an agent, so the practical install step is pointing Claude Code (or Codex, or OpenCode) at the deployment directory and telling it to deploy. It provisions the infrastructure, wires the connectors, and verifies the deployment live. Watching your coding agent stand up Postgres for your company is a genuinely strange experience.

step 4: pick your security posture

Default is Auto. If your org handles anything sensitive, start Strict and loosen per scope once you trust the workflows. Read the repo's SECURITY.md before going anywhere near Dangerous; it documents the threat model and the known limitations honestly, which is rarer than it should be.

step 5: connect slack (optional but the point)

Slack is an optional in-process plugin. Skipping it gives you the web app only, which works, but the shared-channel workflows are where QM stops being a fancier chatbot and starts being a coworker.

honest limitations

• YC says outright that it's early and has bugs. They shipped it anyway; plan for rough edges.
• You're the operator. Cloud bills, model API keys, Postgres, and upgrades are all yours. Free license, not free to run.
• Customizing the core means maintaining a private fork, and the repo is specific that you must do this with a plain clone rather than GitHub's Fork button (a fork of a public repo can't be made private, and its commits stay fetchable by SHA from the public side). They ship update-qm and upstream-pr skills to manage the boundary.
• The contribution policy is unusual: they take contributions as human-written descriptions of changes, not code PRs.
• Solo builders get less from this. If you're one person, a local harness plus your own cron scripts covers most of it. QM earns its complexity at team scale.

quick reference

Thing	Value
Repo	github.com/yc-software/qm
License	MIT
Deploy targets	Fly.io, AWS
Harnesses	Pi, OpenCode, Codex, Claude Code
Surfaces	Slack, web app, admin panel, public portal
Security postures	Strict / Auto / Dangerous