# qm (Y Combinator) qm is an open source [[AI Agent Harness|agent harness]] built by [[Y Combinator]] Software and released under the [[MIT License]]. Its own one-liner: *"A multiplayer agent harness for work. In Slack and on the web."* The word doing the work there is **multiplayer**. Most [[AI Agents]] tooling assumes one person, one terminal, one session. qm assumes a company: every employee gets their own agent with their own files, their own logged-in services and their own memory, and those agents can still meet in a shared channel. It wasn't built to be a product. YC ran it internally first, across accounting, legal, events and engineering, and used it to build itself. Their framing when they announced it: easy to customize like [[Hermes Agent|Hermes]] or [[OpenClaw]], but useful for a whole company. Cloud-first, with Slack and a web UI natively. That origin explains most of the design decisions below, and it's the reason I take it more seriously than the usual "we open sourced our agent framework" post. That comparison is the fastest way to place qm. [[OpenClaw]] and [[Hermes Agent]] are both self-hosted personal assistants: one person, one machine, one set of credentials. qm keeps the customizability and moves the unit of ownership from the person to the org, which is where identity, policy and audit stop being optional. ## How it's put together - **A headless core** runs the agent loop and owns the API, identity and policy. It can drive different models and harnesses underneath (Pi, [[OpenCode]], [[Claude Code]]). - **[[PostgreSQL]]** persists sessions, memory and work queues. Nothing lives only in a chat window. - **A sandbox per scope**, holding that scope's files, tools and authenticated services. Agents run commands and tests inside it. - **Optional plugins**: a web UI (Vite/Lit), Slack via Bolt, an admin panel, a public portal. The pieces sit behind standard interfaces, so the substrates (harness, session store, sandbox) can be swapped. That's the part worth stealing even if you never run qm: treat the model and the sandbox as replaceable, and you stop rebuilding everything each time the frontier moves. Getting one going: ```bash npm exec --yes --package=@yc-software/qm@latest -- qm init . --org <slug> --target <fly-or-aws> ``` ## Security postures Running agents for a whole org means someone has to answer "what is this thing allowed to do?". qm answers it with three postures: - **Strict**: a human approves actions. - **Auto** (default): actions run, with content screening. - **Dangerous**: no restrictions. Two things hold regardless of the posture: every agent action is audited, and predeclared command policies still apply. Simple, and honest about the tradeoff instead of pretending safety is free. ## The contribution rule that started the argument qm hit 671 points on Hacker News on 2026-07-31, and most of the thread ignored the architecture. Everyone went after `CONTRIBUTING.md`, which asks for contributions as **human-written text rather than code**: describe the change informally in a `.txt` or `.md` file under `adrs/`, and the maintainers implement it. It explicitly asks you not to have an AI expand your idea into a formal proposal. The objections wrote themselves. An AI project, largely written by AI, asking humans not to use AI to write the proposal. Someone pointed out the README itself reads generated, and that the `adrs/` directory was empty. The defence was better than I expected: - [[SQLite]] has refused patches from random people on the internet for years. Not a new idea, and not a post-AI one. - Maintainers generally prefer a clear written problem statement to a drive-by pull request. That was true before agents existed. - If your team already has a working harness, implementation costs about ten minutes. The scarce thing is the quality of the idea, and text is much cheaper to screen than a diff. That last point is the one I keep coming back to. When implementation gets cheap, review becomes the bottleneck, and the artifact you want from a contributor shifts from code to intent. qm just made that shift explicit and took the heat for saying it out loud. The counter-argument in the thread is equally sharp: coding agents are useful and bad at design. If you don't do the design yourself, you get slop. That was always the real problem with [[Vibe Coding]], and pushing contributors to write down the design instead of the diff is one answer to it. ## What people actually run always-on agents for The most useful part of the discussion had nothing to do with qm. Practitioners described what an agent with production access earns its keep doing: - Fixing simple CI failures automatically - Receiving production alerts, then drafting the RCA and a fix PR - Hunting slow database queries on a read-only account, running `EXPLAIN ANALYZE`, proposing indexes - Answering one-off data questions with a chart - Acting as first responder during on-call Notice the shape. Every one of those is low-stakes, well-bounded and verifiable. Nobody reported handing an agent the interesting work. And the sharpest comment in the thread was about none of that: the hard problem isn't running agents, it's reviewing what they produce. Provenance, review ergonomics and trust are where the pain moves next. ## Why I keep this note qm matters less as a product I'll adopt and more as a signal about where team tooling is heading. Personal agent, personal sandbox, shared channel, audited actions, swappable model underneath. That's a reasonable sketch of what a company's [[AI Agents]] setup looks like in a couple of years, whoever ends up building it. ## References - [qm on GitHub](https://github.com/yc-software/qm) - [Hacker News discussion (671 points, 2026-07-31)](https://news.ycombinator.com/item?id=49126604) - [Y Combinator's announcement on X (2026-07-31)](https://x.com/ycombinator/status/2083243960684908768) ## Related - [[AI Agents]] - [[AI Agent Harness]] - [[OpenClaw]] - [[Hermes Agent]] - [[Claude Code]] - [[OpenCode]] - [[Y Combinator]] - [[Open Source]] - [[Vibe Coding]] - [[SQLite]]