QM: The Multiplayer Operating System for AI Agents

A deep look at how `yc-software/qm` turns isolated agent sandboxes, scoped identity, and Slack-native collaboration into shared company infrastructure.

8 to 10 min read • View on GitHub • More from yc-software

A wide editorial scene of a company floor feeding into a central control console. Many desks, Slack-like message streams, and small workrooms converge into one orchestrator, while separate sealed compartments inside the console hold their own files, keys, and execution state. The image explains QM as shared infrastructure for many scoped agents, not one universal bot. — QM treats agents as organizational actors with their own boundaries, not as a single shared chat thread.

Key Takeaways

QM’s core move is to make AI agents behave like organizational infrastructure with scoped identity, durable memory, and explicit policy.
Its strongest idea is multiplayer tenancy, where a person, Slack room, or project gets a private agent workspace instead of sharing one bot.
The deployment layer matters because QM signs capability payloads and treats updates as controlled ingress into a live runtime.
The project’s governance is as opinionated as its architecture, with prose-first contributions and humans owning implementation.

Why personal AI breaks the moment a company uses it

Personal assistants are easy because the trust model is simple. One person, one context, one set of secrets. QM starts where that model fails: once an organization wants agents in shared channels, on shared projects, and around shared credentials, the chat thread becomes the wrong abstraction.

That is the interesting wager in yc-software/qm. It is not trying to be a smarter chatbot. It is trying to be the layer that makes agents safe, durable, and legible inside a company.

Single-user assistant	QM
One human, one conversation	Many people, rooms, and projects with distinct scopes
Ephemeral chat state	Durable files, memory, and execution state
Loose trust boundary	Explicit security postures and admin policy
Tooling attached to a prompt	Tooling packaged into an organizational control plane

QM’s core idea: scoped identity plus durable memory

QM gives each employee or Slack room its own workspace. That workspace keeps private files, credentials, cron-like jobs, and memory that persist across tasks. The point is not just isolation. It is continuity with boundaries.

This is what makes QM feel more like a workstation or service account than a disposable prompt session. An agent can return to the same scope, keep its tools installed, and operate inside a security posture that matches the risk of the task.

QM routes people, rooms, and projects into separate durable agent scopes, each with its own state and policy.

Primitive	What it means in QM	Why it matters
Scope	A person, room, or project gets a dedicated agent workspace	Identity and context stop collapsing into one shared bot
Durable memory	State persists across tasks instead of vanishing after a chat	The agent can build up continuity and local history
Private files and keychain	Each scope keeps its own assets and secrets	A team can share infrastructure without sharing everything
Execution state	Installed tools and sandbox state stay available	Agents behave more like long-lived workers than sessions

The deployment layer is the nerve ending

The mechanical heart of the repo shows up in `cli/src/deployment-layer.ts`. It bundles skills and tools into a content-addressed payload, signs the result with HMAC, and sends that package to the running core. In other words, QM does not just execute agents. It packages capabilities and proves where they came from.

// Conceptual shape, simplified from the deployment layer
const contentHash = hash(payload)
const signature = hmac(secret, contentHash)

send({
  contentHash,
  payload,
  signature,
  headers: { 'x-signature': signature }
})

The important detail is the update path. QM treats agent capabilities as signed, controlled ingress into a live environment. That is the difference between a toy harness and an operational platform.

A close-up of a deployment capsule being sealed before entering a guarded sandbox gate. A compact bundle of scripts and descriptors is locked by a hash seal on one side, while a gate on the other side has three posture switches labeled Strict, Auto, and Dangerous. A thin wire links the seal to the lock, explaining how signed capability packages enter the runtime under policy. — Capabilities are not dropped into the runtime casually. They are signed, checked, and admitted through policy.

Security is not a bolt-on, it is the product

QM’s security model is opinionated because it has to be. The repo distinguishes between Strict, Auto, and Dangerous postures, which is a useful admission that agent autonomy is always a policy decision. You do not solve that problem with prompting alone.

Posture	Behavior	Trade-off
Strict	Every risky call expects human review	Slowest, but easiest to reason about
Auto	The system screens or mediates calls automatically	Faster, but still governed by policy
Dangerous	The agent can act with minimal friction	Most flexible, but also the riskiest

The sandbox contract and internal auth chassis reinforce that posture. Credential paths are constrained, replay resistance is built into internal service calls, and the agent runtime is meant to operate under explicit rules instead of vague trust.

We take contributions as human-written text, not code — see CONTRIBUTING.md . 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.

Y Combinator, Maintainer · yc-software/qm GitHub README

How QM talks to the rest of the stack

QM is built around a control plane that can route different engines underneath it without changing the outer wrapper. The repo supports multiple model backends and uses a plugin chassis so auth, core communication, and service boundaries stay consistent even when the underlying engine changes.

Layer	Role in QM	Takeaway
Auth plugin	Handles login and identity flows	Identity is a system primitive, not an afterthought
Core client	Standardizes internal service calls	Plugins can talk to the core without inventing their own protocol
Slack integration	Brings scopes into shared rooms	The agent becomes part of company communication
Model engines	Swappable execution backends	The org does not have to rebuild its control plane to change models

The governance twist: prose-first, human-written, maintainers implement

QM’s contribution model is unusually deliberate. External contributors are asked to write informal ADRs rather than open direct code PRs, and the maintainers handle implementation. That is a strong signal that architectural coherence matters more here than raw contribution volume.

For an agent platform, this makes sense. A project built around durable autonomy probably cannot afford fuzzy decisions at the edges. It needs a shared vocabulary for scope, policy, and trust before it needs more patches.

thanks for reminding me about qm, it has some cool features. My MindRoot framework had some of qm's main features awhile ago though.

ilaksh, Developer · Hacker News Discussion

What QM replaces, and what it doesn’t

QM is not a Claude Code replacement. It sits around tools like Claude Code, OpenCode, and Codex the way an operating system sits around applications. Those tools are inner-loop engines. QM is the outer loop that gives them tenancy, persistence, policy, and a place in the organization.

Category	Inner-loop tools	QM
Primary unit	One developer	One organization with many scopes
State	Local and session-bound	Durable and tenant-aware
Policy	Mostly user-managed	Built into the platform
Integration	Developer-centric CLI	Slack-native and company-wide
Role	Execution engine	Shared control plane

That also explains where QM competes. Against hosted enterprise assistants, it offers self-hosted control and model flexibility. Against local harnesses, it offers persistence and collaboration. Its niche is not better chat. It is better organizational shape.

The trade-off: power through centralization

QM’s promise is also its tension. It centralizes identity, memory, deployment, and policy so that agents can be shared across a company without dissolving into chaos. That same centralization means admins get visibility, operational discipline matters, and trust has to be earned at the platform level.

That is the real story. QM is compelling because it treats agents as governed infrastructure, not clever scripts. Whether that feels empowering or too centralized depends on how much control your team wants to trade for leverage.