QM — YC’s Multiplayer Agent Harness

Open-source agent fleet infrastructure from Y Combinator — one governed, scoped agent environment for each employee, room, or project, with Slack + web surfaces

← Agent harness landscape · AI Agents · Buzz · Hermes · OpenClaw · GFAVIP Webchat · Company Brain · Multiplayer agents · HQ for Work

Source & credit

Announced by Y Combinator (@ycombinator) — x.com/i/status/2083243960684908768 (31 Jul 2026).

Official line: they open-sourced a multiplayer agent harness used internally at YC, called QM, MIT license, cloud-first, with Slack and web UI natively. They use it across accounting, legal, events, and engineering (including building QM itself). Code: github.com/yc-software/qm.

Start here — official

Repo, site & docs

GitHub (source): github.com/yc-software/qm — MIT · “Multiplayer agent harness for work”
Product / lab page: qm.ycombinator.com
Contact: labs@ycombinator.com

Resources, tutorials & docs

Primary materials live in the repo. Use these when evaluating or deploying QM (not just the announcement tweet).

Resource	What it’s for
github.com/yc-software/qm	Source code, README, screenshots, architecture overview
qm.ycombinator.com	YC’s short open-source announcement (history: Ruby → Hermes fleet → QM)
docs/getting-started.md	First run, end to end
deployment.md	Deploy for your org (Fly/AWS targets, operator cloud account)
cli/README.md	`qm` CLI + deployment directory contract (`qm init` via `@yc-software/qm`)
docs/deploy-directory.md	Full deployment-directory shape
.env.example	Every config knob documented in place
plugins/	Slack, web UI, admin, portal surfaces
SECURITY.md	Threat model, postures (Strict / Auto / Dangerous), how to report vulns
CONTRIBUTING.md · adrs/	Contributions as human-written design notes (not drive-by code dumps)
AGENTS.md · CLAUDE.md	Agent/coding-assistant context for working on the repo itself
X announcement thread	Launch framing + feature list for a wider audience

Quick deploy hint (from upstream)

Org-owned deployment repo that depends on the package (no full source checkout required for init):

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

Details: deployment.md. Early experiment — pilot carefully with real secrets and governance.

What “QM” means

Confirmed on qm.ycombinator.com: QM is short for quartermaster — “the person on a ship who coordinates belowdecks to keep things in order.” That matches the product intent: not a single coding buddy, but a company-wide supply line for agent work (ops, legal, events, eng).

Best category name: multiplayer agent harness or agent fleet harness — a company-wide runtime with Slack/web as surfaces. It sits within the broader agent harness landscape.

What YC says it is

Easy to customize, like Hermes or OpenClaw, but useful for a whole company.

From the lab page and README: YC tried a simple Ruby agent loop, then ~50 Hermes personal agents (fleet management got hard), then built QM to be as flexible as Hermes with simpler administration — and something they could own and host. Each employee/project can get an agent; personal scopes and shared channels/projects both work. Harnesses (Pi, OpenCode, Codex, Claude Code) and models are swappable.

Multiplayer/fleet, not an agent swarm

QM is “multi-agent” in the organizational sense: many scoped agents serve different people, rooms, and projects. It is not primarily a swarm where several agents debate or divide up one prompt. The scope is the key unit — each person or room gets separate memory, files, credentials, skills, schedules, permissions, and a sandbox.

MIT open source — yc-software/qm
Cloud-first — deploy to operator’s Fly/AWS account via qm init
Slack + web UI native (same identity/config across both)
Headless core — Postgres sessions/memory/queue; per-scope sandboxes
Early experiment — useful internally; email feedback to labs@ycombinator.com

Features called out in the thread

Triggers

Crons and webhooks — agentic schedules and event-driven work (same spirit as Hermes crons / Grok /loop).

Memory + shared files

Company context that outlives one chat — vault / brain territory.

Company-brain connectors

Wire tools and data so agents synthesize across systems (see Company Brain).

Agent browser

Computer-use style browsing for work that isn’t pure API.

Shareable web artifacts

Outputs as apps/docs the team can open — Hermes Level 3 “artifacts” idea.

Multi-player projects

Humans + agents on shared work — multiplayer agents.

Harness vs chat surface (why “multiplayer agent harness” fits)

People mix three layers. QM sits mostly in the harness layer, with Slack as a surface:

Layer	Job	Examples
Chat / room surface	Where humans see work	Slack, Buzz, GFAVIP Webchat, Teams
Agent fleet / multiplayer harness	Runs governed, scoped agents with memory, triggers, tools, and sandboxes	QM, Hermes, OpenClaw, Grok Build workflows
Portable OS / vault	Durable knowledge & command center	Headless Empire OS, KB vault

Full map of the category (and naming): agent harness landscape.

How QM compares (for our stack)

	QM (YC)	Hermes / OpenClaw	Buzz	GFAVIP Webchat
Primary bet	Scoped agent fleet + Slack/web	Operator/agent runtime (profiles, skills, gateway)	Open collab room (Nostr) humans+agents	Our sovereign team chat
Company-wide	Per-person, room, project, and org scopes	You assemble it	Rooms, not full ops stack	Chat first; agents integrating
Slack-native	Yes	Via connectors / computer use	Alternative to Slack	Slack replacement
Self-host / OSS	MIT, early	Yes	Apache-2.0	Our product surface

Practical take: QM is closest to a governed fleet of Hermes/OpenClaw-shaped agents behind a multiplayer company UI. Buzz is the open room. GFAVIP is our room. HEOS is the portable markdown OS that should feed any of them.

What we should steal for GFAVIP + HEOS

Triggers — crons/webhooks into role agents (standup, quiet deals, event ops).
Shared files + memory — not only channel history; vault slices + rulings.
Company-brain connectors — CRM, calendar, repos, finance tools behind permissions.
Artifacts — agent outputs as links the team reuses (checklists, HTML, reports).
Multi-player projects — room = project; humans + agents co-own threads.
Blast radius — read/draft free; send/spend gated (same as multiplayer agent rules).

Role allocation still follows role-first agents, not one mega-bot per human.

Experiment vs production

YC is explicit: early, buggy, useful for them. Treat QM as:

Learn from — architecture and feature checklist
Pilot — one non-critical lane (events ops, eng triage) if you deploy
Don’t — dump client secrets into an unhardened self-host without governance

Related on this site

Agent harness landscape

Hub: QM, Buzz, Slack agents, GFAVIP, Hermes, OpenClaw, PowerLobster.

Open map →

Buzz by Block

Open-source human+agent rooms (Nostr).

Read →

Claude Tag / Open Tag

Agents inside Slack/Teams — multiplayer with lock-in risks.

Claude Tag → Open Tag →

GFAVIP Webchat

Our Slack alternative — where we seat role agents.