YC Open‑Sources QM: A Multiplayer Company‑Level Agent Operating System

YC Opens Its Internal Agent System QM

YC announced that the internal Agent system used for accounting, legal, events, and engineering has been open‑sourced under the MIT license. The system, named QM (quartermaster), is positioned not as a personal AI assistant but as a company‑wide Agent operating system that gives every employee and project a dedicated Agent capable of collaborating in Slack channels.

Key Design Principles

Open‑source MIT‑licensed code on GitHub.

Each employee and project receives an isolated Agent workspace rather than a single shared Agent.

Supports four mainstream Agent engines – Pi, OpenCode, Codex, and Claude Code – without locking to a single vendor.

Security model with three tiers (Strict, Auto, Dangerous) and hard‑coded high‑risk operation blocks.

Three‑generation evolution: Ruby script → Hermes fleet (50+ instances) → QM.

Early‑stage experimental project with bugs, yet already enables a tiny team to produce output comparable to a large organization.

Multiplayer Agent Concept

Traditional Agent products follow a “personal assistant” model where one Agent serves one user. QM takes a different approach: every employee and every project gets a private, isolated Agent that can be pulled into Slack rooms to collaborate with real people and other Agents. In plain terms, QM provides a whole AI team rather than a single AI employee.

Agent Capabilities

The README lists capabilities that cover the most time‑consuming tasks in a startup:

Unified search across internal notes, emails, documents, databases, and the public web – an “enterprise brain”.

Build and publish internal tools with continuously updated data.

Learn a user's writing style to automatically clean inboxes, generate tags, and draft replies.

Interact directly with code repositories: run tests, open PRs, monitor CI, and inspect logs.

Provide long‑term project updates and reminders in shared channels.

These functions exist in many AI assistants, but QM integrates them under a single identity and permission system, so the same Agent works consistently across Slack and the web UI.

Technical Architecture

The architecture centers on a headless core handling API, identity, policy, and scheduling, backed by a Postgres store for sessions, memory, and task queues. Each conversation is executed by a pluggable “Agent loop” that can run one of the four supported engines.

Each user or collaboration space has its own sandbox containing installed tools, logged‑in services, and a persistent environment – effectively a personal computer for the Agent.

The core runs on Node.js with Fastify for HTTP, Vite for the web UI, and Lit for rendering. All customizations (organization config, tools, sandbox images, infrastructure) are placed in a separate deployment directory and validated by the qm CLI.

For teams that need deeper customization, QM offers a “private fork” workflow: clone the upstream repository into a private repo, keep the core byte‑for‑byte identical, and store all custom layers under deploy/layers/<org>/. Two built‑in skills synchronize upstream updates and contribute generic fixes back upstream.

Security Mechanism

Because an Agent can execute commands, access keys, and act on behalf of a user, QM adopts a security model inspired by local coding agents:

Strict : Every tool call requires manual approval, with only two harmless actions exempted.

Auto (default): A classifier filters external data and tool results before they enter the model context; teams can replace the classifier with their own audit service.

Dangerous : No content filtering and no pause between tool calls.

Regardless of the tier, a pre‑declared command policy (e.g., blocking recursive deletes or destructive SQL) is always enforced via SECURITY.md.

Deployment

QM is deployed by creating a “deployment repository” that depends on the published @yc-software/qm package. Initialization is performed with a single CLI command:

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

The init process generates an Agent‑focused deployment skill and walks the user through infrastructure setup, web login, connector credential configuration, optional Slack integration, deployment, and health checks. Currently Fly and AWS are supported, and each deployment runs in the user’s own cloud account.

Evolution History

YC disclosed three generations of internal Agent systems:

First generation : A Ruby‑based loop with basic tools, later extended with cron jobs and webhook triggers.

Second generation : Over 50 Hermes instances serving as personal assistants, but managing such a fleet became burdensome.

QM : Combines the flexibility of Hermes with the simplicity of the first generation, built as a self‑hosted, open‑source system.

The project is still experimental, contains bugs, and provides a feedback email on the official site.

Implications for AI‑Native Companies

QM illustrates several emerging trends:

Assigning a dedicated Agent to every employee turns AI from a personal productivity tool into core organizational infrastructure.

The “multiplayer” concept shifts focus from single‑Agent capability to coordinated multi‑Agent collaboration.

Vendor‑agnostic engine support reflects a move toward interchangeable AI components.

YC’s direct involvement and full open‑source release set a precedent for how AI‑native startups might build and share foundational tooling.

Getting Started

To try QM:

Repository: github.com/yc-software/qm Official site: qm.ycombinator.com Feedback email: [email protected] Despite its early‑stage status, QM offers a glimpse of the next generation of company‑wide AI collaboration.