qm (Y Combinator)
Canonical version: qm (Y Combinator).
qm is an open source 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."
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.
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 or OpenClaw, but useful for a whole company. Cloud-first, with Slack and a web UI natively.
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.
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. Treat the model and the sandbox as replaceable, and you stop rebuilding everything each time the frontier moves.
Setup:
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.
What people actually run always-on agents for
Some examples:
- 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
- ...
Every one of those is low-stakes, well-bounded and verifiable.
Note that the hard problem isn't running agents, it's reviewing what they produce.
Why I keep this note
qm matters less as a product I'll adopt and more as a signal about where team/enterprise 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
- Hacker News discussion (671 points, 2026-07-31)
- Y Combinator's announcement on X (2026-07-31)
Related
- AI Agents
- AI Agent Harness
- OpenClaw
- Hermes Agent
- Claude Code
- OpenCode
- Y Combinator
- Open Source
- Vibe Coding
- SQLite
About Sébastien
Ready to get to the next level?
Found this valuable? Share it with someone who needs it.