qm – Multiplayer agent harness for work

A new open-source “multiplayer agent harness” from YC aims to give each employee a personal AI assistant that can act across company tools, while sharing scoped context in shared “rooms.” Commenters are intrigued by the idea of org-wide agents and the contribution model—feature ideas submitted as human-written text rather than code—but question how much this really advances beyond existing Slack bots, Copilot/Cowork-style products, and other agent frameworks like Hermes or OpenClaw. There is also skepticism about hype-driven design choices such as an elaborate “anti-slop” taste skill and broader concerns that always-on agents may generate more noise, security risk, and superficial automation than genuine productivity gains.

Contribution model & AI-generated code

  • Project only accepts “human-written text” ADRs, not code PRs. Maintainers then implement changes, often via their own agents.
  • Many see this as a practical way to avoid low-effort or LLM-slop PRs and focus on ideas and specs instead of code review.
  • Others find it ironic or “AI-psychotic” that an AI-heavy project bans AI-written proposals, though some note the restriction is really on AI-formalized specs, not general AI use.
  • Comparisons are made to projects like SQLite that also avoid random code contributions; several maintainers say they prefer detailed issues over drive‑by PRs.

“Taste” / anti-slop skill

  • The shipped “taste skill” for frontends tries to avoid typical AI-looking design and copy.
  • Some like the idea of explicitly encoding anti-slop rules; others criticize its huge prompt size and negative, prescriptive style.
  • Bans on specific stylistic markers (like certain palettes or punctuation) are seen by some as overfitted and silly; others think such tells will just invert over time.

Agent harnesses, Hermes, and use cases

  • Discussion compares qm to Hermes, Openclaw-like systems, and other harnesses.
  • Some prefer feature-rich harnesses like Hermes; others favor minimal, extensible setups or rolling their own for control and resource usage.
  • Reported real uses: on-call alert triage, CI fixers, RCA generation, DB query optimization, inbox and RSS/news triage, charts/analytics, and internal tools via webhooks.
  • A recurring concern: producing lots of agent code is easy; reviewing, tracing provenance, and trusting it is the hard part.

“Multiplayer” agents and UX

  • “Multiplayer” is interpreted as org-wide agents and shared rooms/scopes so each person has an assistant that can collaborate and share context.
  • Some see this as just another job scheduler or glorified Slack bot; others think scoped, shared context is the real challenge and value.
  • There is interest in new UI and agent primitives (e.g., state models tied to UI, MCP-based apps), but many note current marketing pages are vague and similar.
  • Debate over whether to build bespoke harnesses vs. using generalized platforms; customization is valued, but fragmentation and “yet another harness” fatigue are evident.

Reception, novelty, and skepticism

  • Some find qm real, useful, and a natural evolution of earlier personal RAG/agent setups.
  • Others see it as overengineered, hype-driven, rushed in response to “multiplayer AI” buzz, or a solution in search of problems that mainly burns tokens.
  • Concerns raised about security (agents having all a user’s permissions), unclear differentiation from tools like Copilot or Cowork, and YC’s broader strategic motives.