AI Agents Go to Work: qm, YC's Open-Source Multiplayer Agent Harness

The hard part was never getting an agent to work — it’s getting five people’s agents to work in the same company without stepping on each other. That’s the real reason YC’s open-source project qm scored 465 points on Hacker News: it didn’t invent a smarter agent. It invented the agent’s workstation.

Every agent product of the past two years runs on the personal-assistant mental model: one terminal, one sandbox, one context. But real work is collaborative — code review, on-call alerts, cross-department queries. qm’s angle is direct: give each employee an isolated workspace, give every channel, group, and project a shared room, and let agents work in both. A comment from knighthacker nailed it: “The hardest problem in multiplayer agents is not the agent loop — it’s scoping. QM’s per-person scopes plus shared rooms is a sane answer for a company-wide assistant.”

This article breaks down how qm solves that problem, and the “human-written contributions only” rule that set the comments on fire.

• Lesson 1: The bottleneck in agent collaboration is scoping, not intelligence. Who owns what memory, who can touch which files, whose commands override whose — these isolation rules decide whether a team agent system ships, more than model capability does.
• Lesson 2: Security models should layer like permission systems. qm ships Strict / Auto / Dangerous postures plus a predeclared command blacklist that applies in every posture — destructive commands stay blocked even at “maximum privilege.”
• Lesson 3: AI projects are now demanding “human-written” in reverse. qm’s contribution rule accepts only human-written text proposals, not code PRs — because code can be delegated to agents, but design intent must come from a person.

〇、The meta-question: when an agent goes from “personal assistant” to “team employee,” what changes?

The default design for a solo agent: one agent = one context = one user. It remembers your preferences, touches your files, uses your credentials. That model works flawlessly in personal use — until you hand an agent to a team.

Teams immediately hit three problems that solo mode never had:

1. Isolation: your agent memorized your API keys and drafts — can a colleague’s agent see them? If the sandbox is shared, one misstep is a company-wide disaster.
2. Sharing: full isolation fails too — teams need agents collaborating in channels, touching shared repos, shared knowledge bases, on-call alerts.
3. Trust: when an agent acts “as an employee,” how does the company audit who told the agent to do what?

Together these are scoping — the one design problem that cannot be skipped when agents evolve from personal tools into team infrastructure. qm’s value isn’t that its agents are smarter (it doesn’t even train models — it plugs in Pi, OpenCode, Codex, and Claude Code), it’s that it gives a complete, deployable answer to scoping.

一、What qm is: assigning agents their desks

qm (“multiplayer agent harness for work”) is an open-source, multiplayer agent workspace with interfaces in Slack and on the web. The core design is a two-space model:

• Personal scopes: every employee gets a fully isolated workspace — own memory, files, keychain, permissions, crons, web apps, and a durable sandbox. “People customize the agent to be theirs, and still work with it collaboratively in Slack channels and projects.”
• Shared rooms: channels, group messages, and projects each have their own scope, where members share the room’s agent, files, and memory.

Every scope — person or room — has its own memory, files, keychain view, permissions, crons, web apps, and a durable sandbox: tools and environments you install stay installed.

This model answers question one (isolation) and question two (sharing): personal scopes guarantee isolation, shared rooms guarantee collaboration, and the two connect through explicit permissions — not by papering over everything with one giant shared context. That’s exactly where most products that throw a solo agent at a team fall apart.

二、Architecture: don’t build models, build infrastructure

qm’s architecture is remarkably restrained — deliberately no models, no harness lock-in:

┌─────────────────────────────────────────────┐
│  Slack plugin (Bolt)      Web UI (Vite + Lit)│
│  Admin panel              Public portal      │
└──────────────────┬──────────────────────────┘
                   │ HTTP API
┌──────────────────▼──────────────────────────┐
│         Headless Core (Node + Fastify)       │
│   API · identity · policy · scheduler        │
│   Agent loop ← Pi / OpenCode / Codex /       │
│                Claude Code, swappable        │
└──────────────────┬──────────────────────────┘
                   │
┌──────────────────▼──────────────────────────┐
│  Postgres: sessions · memory · queue        │
│  Per-scope sandbox: files · tools · logins  │
└─────────────────────────────────────────────┘

The key decisions:

Decision 1: swappable harnesses, generic core. All agent loops (Pi, OpenCode, Codex, Claude Code) drive the same core; a deployment isn’t tied to any single vendor. Company-specific customization (org config, custom tools and skills, sandbox image, infrastructure) lives entirely in a deployment directory validated and deployed by the qm CLI. The philosophy underneath: models and agents iterate fast, but “who has what permission” should be stable.

Decision 2: Postgres is the only durable layer. sessions, memory, and queue all persist in the DB; the web UI and admin panel are optional plugins over the core’s HTTP API, and Slack is an optional in-process plugin the core starts and supervises. State ownership belongs to the core, not to a frontend or an agent process — so swapping harnesses, models, or even UIs never loses the team’s memory or permissions.

Decision 3: sandboxes isolate by scope, not by process. Each scope’s agent executes in its own persistent sandbox where installed tools stay installed. The unit of isolation is the “workspace,” not the “session” — the essential difference from the “one throwaway container per agent” approach.

三、Security: three postures plus one line that cannot be crossed

Security is the heaviest section of qm’s docs. Its principle matches local coding agents (OpenCode, Codex, Claude Code): the agent acts as the person it’s working for, with their credentials and permissions, and everything it does is audited. The org picks one security posture; narrower scopes can only tighten it:

But the genuinely notable piece is the predeclared command policy that applies in every posture: approval rules and hard denials — recursive deletes, destructive SQL — cannot be bypassed at any level. “Dangerous” does not mean “no guardrails.” This design answers half of the trust question: even at the most permissive setting, destructive commands stay behind a hard wall.

四、The controversy: an AI project demanding “human-written” contributions — regression or clarity?

qm’s CONTRIBUTING rule generated 40+ comments of HN debate:

“We take contributions as human-written text, not code. Describe the change you’d like informally in a .txt or .md file in adrs/, and if we’re aligned we’ll handle the implementation.”

Translation: contributors write human text about what they want; the maintainers (and their agents) write the code. The rule splits “writing code” from “knowing what you want” completely.

The thread split hard. tptacek’s read was sharpest: “They just want your prompts, not your code.” ronsor added the knife: “Coding agents are extremely useful but often extremely dumb with design. If you do not design the software yourself, you will probably get slop. This was always the core issue with vibe coding.” Supporters countered: better 50 thought-through requirement docs than 5000 slop PRs nobody will triage.

The rule itself is more interesting than qm’s features: with AI writing code by default, the human’s core output is shifting from “code” to “intent.” The contribution rule just makes the trend explicit — code is cheap; knowing what you want is scarce. Commenters were quick to note the irony: qm’s own README is generated and its commit history is openly credited to claude — “an AI-written project demanding human-written proposals.” The loop is very much of this era.

五、The future: agent collaboration’s next bottleneck is review, not execution

stephenway’s comment may be the most forward-looking in the whole thread:

“The interesting challenge isn’t running agents, it’s reviewing their work. The more code agents produce, the more important provenance, review ergonomics, and trust become. Repository platforms will need to evolve.”

qm answers this today with audit logs and the “agent acts as the person” model, but the thread generally agrees that’s only a start. Two more threads worth noting: someone argued “agents need new UI primitives — right now we just stuff a chat box into everything,” and several compared qm with personal agents like Hermes/Openclaw, concluding the positioning is different: personal agents manage your machine; qm manages your company. As argssh put it: “I’d rather use Hermes/Openclaw for OS-level things.”

Summary: the age of the agent’s “desk” begins

qm’s real contribution isn’t another agent — it’s the first serious answer to “how do agents clock in at a company.” It lifts the solo-agent product philosophy (local, autonomous, your credentials) to team scale, inventing organizational concepts along the way: scopes, postures, deployment directories.

When agents writing code becomes the default, the next competitive front is agent governance, isolation, and collaboration — which needs not just better models, but better organizational design.

🤖 Evaluating agent tooling for your team?

• Does your team run agents individually, or do you need a shared “company agent”?
• When agents act as employees, is your audit and permission model ready?
• Have you considered: should contribution rules accept “code” or “intent”?

📬 Follow 梦兽编程 for more AI agent and engineering efficiency analysis.

Sources:

• GitHub: qm — Multiplayer agent harness for work External link
• HN: qm – Multiplayer agent harness for work External link