YC open-sources QM for Slack-based AI workspaces

Y Combinator has open-sourced QM, a multiplayer agent harness for work that gives employees and shared rooms their own AI workspaces across Slack and the web. The official QM project page presents the release as YC's attempt to turn a fleet of work-oriented agents into software a startup can own and administer. For operators, the important change is not a new model; it is a shared system for identity, scope, tools and background work.

QM is designed around scoped collaboration rather than one company-wide assistant. Each person and room can have its own memory, files, permissions, keychain view, web apps, crons and durable sandbox, while the same identity and configuration can move between Slack and the web. That makes QM relevant to teams deciding whether an AI agent should act as an individual helper, a shared channel participant or both.

Definition: QM is Y Combinator's open-source multiplayer agent harness for work, short for quartermaster.

Example: A team can give an employee a personal scope while also giving a project room a shared scope for collaboration with the agent.

Key takeaway: QM moves the unit of agent deployment from one assistant toward many scoped workspaces.

Business impact: Teams can evaluate a self-hosted operating layer for agents, but they also inherit responsibility for infrastructure, permissions and security review.

Why did YC build QM for teams?

Y Combinator says QM grew out of an operational problem: a fleet of agents can be useful but difficult to manage consistently. The project's history describes earlier experiments with a Ruby agent loop and later more than 50 Hermes agents for individual employees before YC sought a system that retained flexibility while simplifying administration. The takeaway for an operator is to evaluate QM as fleet-management infrastructure, not merely as another chat interface.

QM's “multiplayer” model means that people can work with the agent in channels, group messages and projects without giving every conversation the same shared state. A personal scope can preserve an employee's own files and memory, while a room scope can hold the context of a project. That separation gives a business a concrete design question: which data and actions belong to a person, and which belong to a team space?

What can QM do in Slack and the web?

QM connects the same identity and configuration across Slack and a web application, so Slack is a work surface rather than a separate agent product. The QM repository lists shared channels, internal apps, inbox triage, scheduled work, repository tasks and project tracking among its example uses. The practical takeaway is to map each proposed workflow to a scope before enabling connectors or credentials.

QM also treats skills and background work as first-class parts of the workspace. Skills can be owned by a scope, shared by grant and promoted across the organization by an administrator; crons and watches can run unattended work. That combination makes QM more than a request-and-response bot, but it also means an operator must govern who can grant capabilities and which scheduled jobs can act without a person watching.

How is QM structured under the hood?

QM routes each turn through a central headless core that handles API access, identity, policy and scheduling, while an agent loop drives tools inside a per-scope sandbox. The repository describes Postgres as the persistence layer for user data, session history and other durable state, and identifies execute as a fixed-surface tool that runs commands in the scope's durable sandbox. For a deployment team, the useful architectural boundary is clear: the core coordinates policy and state; the sandbox performs work.

QM is also designed to swap the harness behind that core. The README names Pi, OpenCode, Codex and Claude Code as compatible harnesses, with the deployment selecting the model and harness combination. This is a meaningful portability claim, but it does not make deployments vendor-neutral by default: provider keys, model behavior, connector access, sandbox images and organization configuration still need separate review.

What does QM's security model actually guarantee?

QM provides three organization-level security postures, but the project does not present them as a complete security guarantee. Strict pauses harness tool calls for human approval, Auto screens supported provenance-labelled external data and tool results, and Dangerous removes those pauses and content screening. A predeclared command policy with hard denials for examples such as recursive deletes and destructive SQL applies in every posture, including Dangerous.

The QM security policy explicitly calls the software early and experimental and says it is not a hardened public or multi-tenant service boundary. It also lists limitations including bypassable command policy, browser actions outside some core gates, plaintext credentials while in use inside a sandbox, incomplete screening and privileged administrator access to sensitive content. The operational takeaway is to treat posture selection as defense in depth, not as a substitute for least privilege, network controls, audit review and deployment-specific testing.

How would a company deploy QM?

QM's deployment model keeps organization-specific configuration outside the published core. The repository says an organization-owned deployment repository can depend on the @yc-software/qm package, then use the qm CLI to materialize infrastructure, sign-in, connector, Slack and verification steps. Each deployment runs in the operator's own cloud account, and the project says initialization does not create deployment CI. A business evaluating QM should therefore budget for platform ownership, not only for agent configuration.

The MarkTechPost report describes the practical baseline as a cloud account, Postgres and someone comfortable with infrastructure, with Fly.io and AWS among the deployment targets. That does not define a universal sizing or support commitment; it describes the operating burden of the current release. Teams should prove one narrow workflow first, then expand scopes and connectors only after checking data boundaries, failure handling and audit records.

What should operators watch next?

QM's release matters because it makes the coordination layer around workplace agents more visible and deployable. YC is publishing a system for scopes, shared channels, durable workspaces, interchangeable harnesses and security postures rather than only exposing a single assistant experience. For readers comparing build-versus-buy choices for AI agents, QM is a concrete example of the “own the operating layer” path.

The limits are equally important. QM's own security policy says the software is experimental, and the project does not claim that its controls prevent every model error, data disclosure or operational failure. The next useful test is not whether QM can produce an impressive demo; it is whether a company can deploy one scoped workflow, explain every credential and tool boundary, observe the resulting actions and recover cleanly when the agent is wrong.

FAQ

Is QM a foundation model?

No. QM is an agent harness and deployment system. Its core coordinates identity, policy, scheduling, persistence and tool execution, while supported harnesses and model providers drive the agent loop. Y Combinator's release is therefore about making workplace-agent infrastructure inspectable and deployable, not about releasing new model weights. A team considering QM should review the harness, provider, model terms, credentials and connected services as separate layers. Background: Gemini API Managed Agents: 3.6 Flash, hooks, and more.

Does QM make every employee's data private from administrators?

No. QM scopes are designed to reduce cross-scope access between people and rooms, but the project's security policy says a scope-authorized administrator can read sensitive content such as transcripts, provider requests, documents, memory, connector metadata and skill bodies. The design provides boundaries and audit evidence; it does not promise that administrators are unable to access authorized organizational data. Companies should define administrator access, retention and audit procedures before deployment.

Can QM replace Slack or a company's internal tools?

No. QM adds an agent layer that can run in Slack and on the web, and it can support custom web apps and connected services. The repository's examples include searching internal information, triaging email, working in repositories and tracking projects. Those capabilities depend on the deployment's connectors, credentials, tools, sandbox and policies. QM should be evaluated as an orchestration and workspace layer around existing systems, not as a general replacement for them.

What is the safest way to evaluate QM?

Start with one narrow workflow in an operator-controlled cloud account, synthetic or low-risk data, scoped credentials and a disposable sandbox. Record the tools the agent can call, test ambiguous and failed requests, inspect audit records and verify how scheduled work behaves when nobody is watching. Then review the project's current security limitations and your own provider, network, retention and administrator-access assumptions before connecting production systems.