QM: Y Combinator’s Open-Source Multiplayer Agent Harness

Y Combinator just open-sourced QM, a “multiplayer agent harness for work” that argues the industry has been building AI agents the wrong way. For the last two years, the default shape has been per-user copilots bolted onto individual products. QM’s bet is that the useful unit for a company is a shared, org-wide harness — where every employee gets an isolated workspace, but the whole team collaborates with the same agent in Slack.

The repo hit 9,000+ stars within days of release, and YC says it runs QM internally across accounting, legal, events, and engineering — including building QM itself. Here’s what QM actually is, how it’s different from the frameworks you already know, and what to consider before adopting it.

What Is QM?

Most agents are designed like personal assistants. You can scale one to a whole company, but the complexity compounds quickly: shared context, permissions, credentials, memory collisions, and a single chat interface that no one really owns.

QM inverts that model. It’s designed for startups, with a dual-layered structure:

• Personal scopes. Each employee gets their own isolated workspace with scoped memory, files, a keychain view (for credentials), permissions, crons, web apps, and a durable sandbox — a persistent computer where installed tools stay installed.
• Shared collaboration. The same agent works in Slack channels, group messages, and project rooms, so teams interact with it as a collective resource.

The key insight is that scoping is the primitive. Every person and every room has its own memory and permissions, so the agent’s context is always relevant and secure — no more one giant brain that mixes everyone’s data.

Why Y Combinator Open-Sourcing It Matters

YC is not just endorsing a tool; it’s signaling a shift in how startups should buy AI infrastructure:

1. It validates the shared-harness model. YC’s own post says the firm uses QM “across accounting, legal, events, and engineering (including building QM itself!).” That’s a strong signal that the per-user copilot era is giving way to org-wide agent surfaces.
2. It’s vendor-agnostic by design. Pi, OpenCode, Codex, and Claude Code all drive the same core. A deployment isn’t tied to any single model vendor, which matters when model leadership changes quarterly.
3. It’s MIT-licensed and cloud-first. Startups get a blueprint for deploying capable, secure corporate AI without compromising data sovereignty or getting locked into a closed ecosystem.

Key Features

What you can actually do with it

• Search internal notes, email, documents, databases, and the web together
• Retrieve information from your “company brain”
• Build internal apps and keep their data current
• Learn your writing voice from past sends, then triage your inbox on a schedule — labels and reply drafts included
• Work in an existing repository: run tests, open PRs, monitor CI, check system logs
• Track a project in a shared channel and post updates and follow-ups

Architecture: A Deployable App, Not a Library

This is the most important distinction. QM is not another orchestration framework. It’s a complete application infrastructure:

• Core: A headless TypeScript core on Node with Fastify that routes every turn
• Persistence: Postgres holds user data, session history, and durable state
• Sandbox: A small, fixed tool surface; the execute tool runs commands in each scope’s isolated sandbox
• Surfaces: The web UI, admin panel, and public portal are optional plugins over the core’s HTTP API; Slack is an optional in-process plugin (built with Bolt)
• Extensibility: Every substrate (harness, session store, sandbox, memory) sits behind an interface, so production implementations swap in with one wiring change

Because the core is generic, everything company-specific — org config, custom tools, skills, sandbox image, infrastructure — lives in a deployment directory that the qm CLI validates and deploys.

QM vs. CrewAI, AutoGen, LangGraph, and OpenAI Agents SDK

The frameworks require you to code how agents talk to each other. QM gives you a running system where the collaboration model — personal isolation plus shared channels — is the product. If you need a library to orchestrate models in your own codebase, use a framework. If you want a team-wide AI workspace in Slack this quarter, QM is a different category entirely.

Deployment: The qm init CLI

Deploying QM skips source checkouts entirely:

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

Initialization materializes a deployment skill for an agent and walks through infrastructure, web sign-in, connector credentials, optional Slack access, deployment, and live verification. Each deployment runs in your own cloud account (Fly or AWS), and initialization does not generate deployment CI.

The private fork option

If you want the whole codebase in one place with private customizations, QM recommends a plain git clone — never GitHub’s Fork button. A GitHub fork inherits public visibility and shares an object network with the source repo, so commits stay fetchable by SHA from the public side. A plain clone keeps everything private.

Customizations live in deploy/layers/<org>/ while core stays byte-identical to upstream, which keeps merges small. Two AI skills maintain the boundary: update-qm merges upstream and opens a sync PR; upstream-pr sends organization-agnostic fixes back after checking for org identifiers.

Security Postures

QM follows the local coding agent model — the agent acts with the person’s credentials and permissions, and everything is audited. Orgs pick one of three postures, and narrower scopes can only tighten it:

A predeclared command policy — approval rules and hard denials for recursive deletes or destructive SQL — applies in every posture, including Dangerous. The repo’s SECURITY.md documents the threat model and known limitations.

The Honest Caveats

Independent coverage of QM has been enthusiastic but not naive. The most important caveats:

1. The README is a pitch, not an operations manual. It doesn’t explain how sandbox isolation is enforced under the hood, what the ongoing maintenance burden looks like for a small ops team, or how to decide which harness should handle which scope.
2. “1000x” language is marketing. YC staff on X made bold claims; treat them as hype, not measured benchmarks.
3. It’s an infrastructure commitment. If your team is very small, individual AI subscriptions might be simpler. QM is designed to replace a fragmented stack of copilots with a unified team surface — that’s a decision about how your company works, not just a tool install.
4. You own the ops. Postgres, Slack integration, cloud infrastructure, and the sandbox layer all need ongoing maintenance in your own cloud account.

Should Your Startup Adopt QM?

QM is worth a serious look if:

• You’re a startup (the design target) with 5-50 employees who already live in Slack
• You want one AI workspace instead of every team buying separate copilot subscriptions
• You care about model flexibility and don’t want to bet the company on a single vendor
• You have (or can hire) someone to own the infrastructure

Skip it for now if you’re a solo developer or a team of two — the scoping model pays off when there are enough people that isolation and sharing actually matter.

Getting Started

• Repo: github.com/yc-software/qm
• Docs: docs/getting-started.md (first run), docs/deploy-directory.md (deployment contract), cli/README.md (CLI reference)
• License: MIT
• Stack: TypeScript, Node, Fastify, Postgres, Bolt (Slack), Vite + Lit (web UI)

QM is one of the most interesting open-source releases of 2026 — not because it’s a better agent, but because it changes the unit of AI adoption from the individual to the organization. Whether you deploy it or not, it’s the clearest statement yet of where enterprise AI is heading.