Y Combinator Open-Sources QM, a Multiplayer Agent Harness for Slack and the Web

Y Combinator has open-sourced QM, its MIT-licensed multiplayer agent harness for running AI agents across Slack and the web. The practical takeaway for AI builders is less about another chat interface and more about architecture: QM treats agent ownership, workspace isolation, permissions, and scheduling as first-class infrastructure.

QM is an organizational deployment, not a desktop assistant

QM, short for Quartermaster, is described as software YC uses across accounting, legal, events, and engineering, including work on QM itself. The project is released as an experiment with early bugs, but it is deployable today for startups and mid-sized companies that have a cloud account, Postgres, and at least one person comfortable with platform infrastructure.

The intended pattern is organization-owned deployment. An operator initializes a deployment with an organization slug and targets Fly.io or AWS. The resulting system runs in the operator's own cloud account, with setup covering web sign-in, connectors, optional Slack access, and live verification.

Per-user workspaces are the important design choice

QM's strongest idea is its decision to avoid one company-wide assistant with a shared memory and permission model. Each person and room receives an isolated workspace with its own memory, files, keychain view, permissions, scheduled jobs, web apps, and durable sandbox. Skills belong to a scope and can be shared by grant, with organization-wide promotion gated by an administrator.

That model maps more closely to how work is actually authorized. An employee can ask an agent to work with their credentials, while a project room can have a different context and access boundary. The same identity and configuration can carry between Slack and the web, so the interface changes without requiring a separate agent architecture.

For builders, this is a useful alternative to putting every tool and data source behind a single powerful agent. It can reduce accidental cross-user context leakage, although the isolation is only as strong as the deployment's identity, storage, connector, and sandbox configuration.

A vendor-neutral core with a small tool surface

Every turn runs through a central headless core responsible for the API, identity, policy, scheduling, and agent loop. Postgres stores sessions and durable state. The stack uses TypeScript on Node, Fastify for HTTP, Bolt for the Slack integration, and Vite with Lit for the web interface.

QM is also described as harness-agnostic. Pi, OpenCode, Codex, and Claude Code can drive the same core, which means the deployment is not structurally tied to one model or coding-agent vendor. Optional web, administration, and public-portal interfaces sit on top of the core's HTTP API.

The tool surface is intentionally small. Its execute tool runs commands inside the scope's isolated sandbox, where installed tools remain available. That makes patterns such as repository testing, inbox triage, internal search, scheduled work, and CI monitoring possible, but it does not eliminate the need to define what each scope may access.

Security policy is part of the product boundary

QM includes organization-wide operating postures. Strict pauses harness tool calls for human approval. Auto, the default, screens provenance-labeled external data and tool results with a classifier before they reach the model. Dangerous removes content screening but still applies predeclared command restrictions, including hard denials for destructive operations such as recursive deletes and destructive SQL.

This is a sensible separation between model behavior and execution policy. It also means teams should read the project's threat model and documented limitations before connecting sensitive systems. The supplied material points to SECURITY.md, but it does