Y Combinator has open-sourced QM, an MIT-licensed multiplayer agent harness that runs in Slack and the web. Designed for teams of 10-500, it delivers isolated workspaces, harness-agnostic orchestration, and a three-tier security model.
Y Combinator just made a major move in the open-source AI space. The accelerator has released QM, an MIT-licensed multiplayer agent harness designed to run directly inside Slack and the web. This isn’t another single-user chatbot wrapper. YC QM is organizational software built for teams of 10 to 500 people who want AI agents collaborating on real work in shared spaces.
While most agent frameworks focus on individual productivity, QM addresses a different question: what happens when agents need to work alongside teams, in shared rooms, with shared context and permissions? That shift - from personal assistant to multiplayer infrastructure - is what makes YC QM stand out.
Most agent frameworks treat AI as a personal assistant. QM flips that model. It’s a multiplayer agent harness where every person and every shared room gets its own isolated workspace. These workspaces include memory, files, a keychain view, permissions, crons, web apps, and a durable sandbox.
In practice, that means an agent working in a shared room can access the team’s context, run scheduled tasks, and execute commands safely - without bleeding into personal or other teams’ workspaces. Each scope is isolated, which is critical when AI agents start touching production infrastructure.
The ‘multiplayer’ framing matters. In Slack, for example, a room might be dedicated to a cross-functional project. QM gives that room its own agent workspace with its own memory and permissions. The agent doesn’t belong to any single person; it belongs to the room. Any room member with appropriate permissions can interact with it.
The project ships as early, buggy, experiment-scale software, per its own documentation. That’s an honest framing: QM is not yet a polished product. It’s a powerful foundation for teams willing to iterate.
QM’s design is deceptively simple. A central headless core handles the API, identity, policy, and scheduling. The core is backed by Postgres and per-scope sandboxes.
The agent itself exposes a small fixed tool surface. There’s really one key tool: execute. This tool runs commands inside the scope’s isolated sandbox. This minimalist approach keeps the attack surface small and the behavior predictable.
This architecture makes QM harness-agnostic. That’s a major design decision. Pi, OpenCode, Codex, and Claude Code can all drive the same QM core. So a company isn’t locked into a single vendor’s agent. You can switch, you can run multiple, you can choose the best tool for each task.
The implications are significant. Companies that adopt QM are not betting on a single LLM vendor or agent framework. They’re building on a substrate that can accommodate multiple. As the agent ecosystem evolves, QM can evolve with it by simply adding new harness support.
Security is where QM shows its maturity. The system defines three organization-wide security postures:
Every harness tool call is paused for human approval. Nothing happens without a human green light. Maximum safety, lower throughput.
External data and tool results are screened by a classifier that checks for prompt-injection and dangerous content. This posture balances automation with protection.
All screening and pauses are removed. Full-speed automation, intended for trusted environments only.
Notably, this isn’t all-or-nothing. A predeclared command policy with hard denials for destructive commands applies in every posture. So even in Dangerous mode, there are boundaries. That’s a sensible engineering choice.
The existence of a classifier for provenance-labelled external data suggests that QM treats prompt injection as an active threat. And it should. This is one of the most important security concerns in agentic AI. With agents reading web pages, emails, and documents, the risk of malicious instructions embedded in content is real and growing.
The three-posture model gives organizations a way to dial risk up or down based on their comfort level and the sensitivity of the work. A company doing exploratory research might run in Auto. A company making irreversible changes to production systems might prefer Strict.
Y Combinator isn’t shipping this as a cold open-source project. The organization reports using QM internally across accounting, legal, events, and engineering - including building QM itself. That’s dogfooding at the highest level.
Documented internal uses include:
These aren’t toy examples. They’re real workflows that touch sensitive data and production systems. If YC trusts QM with its own accounting and legal operations, that’s a strong signal of real-world viability.
The fact that YC uses QM to build QM is particularly notable. It suggests the tool has reached a level of maturity where it can support its own development. That’s a common milestone for serious infrastructure projects.
QM is not a desktop app. It’s deployable today as organization software. That comes with requirements:
The best-fit use case is a startup or mid-sized company of roughly 10 to 500 people. Smaller shops may not have the infrastructure appetite. Larger enterprises may require more governance machinery than QM currently ships.
Deployment happens via an org-owned repository that depends on @yc-software/qm, or via a private fork created by a plain clone (not GitHub’s Fork button). Each deployment runs in the operator’s own cloud account. This is deliberate: you own the infrastructure, you own the risk, you own the data.
For platform engineers, the deployment model will feel familiar. It’s essentially a modern web service with a Postgres backend. The operational burden is real but not exotic. Teams that have deployed Rails, Django, or Node.js applications should feel at home.
Before adopting QM, there are a few key considerations your team should run through.
Infrastructure readiness. Do you have the cloud resources and the engineering talent to run a Postgres-backed service? If your answer is no, QM will add operational burden rather than remove it.
Security posture selection. Starting with Auto is the default, but you should explicitly decide which posture fits your environment. Teams working with sensitive data may want Strict for certain rooms. Teams running internal automations in trusted networks may feel comfortable with more aggressive settings.
Harness selection. Which agent harnesses will you use? QM supports Pi, OpenCode, Codex, and Claude Code today. The right choice depends on your existing workflows, your team’s familiarity with specific tools, and the kinds of tasks you want to automate.
Scope design. Multiplayer harnesses shine when scopes are designed thoughtfully. Think about which rooms and teams need their own agent workspaces. Consider how permissions should be structured. The isolation model is powerful, but it requires intentional design.
QM’s release sits at the intersection of three rising trends:
These trends point to a maturing ecosystem. Companies increasingly want to own their AI infrastructure rather than being tied to a single vendor’s cloud agent. QM’s MIT license and Postgres-backed architecture make it an attractive option for teams that value control.
The open-source angle is particularly interesting. By releasing QM under the MIT license, YC is essentially saying that the tools for building agent infrastructure should be broadly available, not locked behind enterprise paywalls. That aligns with the broader movement toward open-weight models and open-source agent frameworks.
At the same time, QM is an experiment. The project’s own documentation is clear about its early, buggy status. Teams adopting QM today are not buying a polished commercial product. They’re betting on a foundation that they can shape to their needs.
Y Combinator’s open-sourcing of QM under the MIT license marks a significant moment in the evolution of agent infrastructure. It’s a multiplayer agent harness designed for real organizational use, with isolated workspaces, a headless core, harness-agnostic support, and a three-tier security model.
The key takeaway is that QM recognizes the reality of how agents will work in organizations: not as solitary assistants but as collaborative actors in shared spaces, running in the tools the organization already uses, with tight security boundaries.
For startups and mid-sized companies with platform engineering capacity, QM is worth a serious look. It’s a chance to build your agent strategy on an open foundation, free from vendor lock-in, with a security model that respects the complexity of production environments.
The roadmap is clear. The foundation is solid. And it’s MIT-licensed - so the only barrier to trying it is your own infrastructure.
YC QM is an MIT-licensed multiplayer agent harness from Y Combinator that runs in Slack and the web. Unlike frameworks focused on individual assistants, QM gives each person and shared room its own isolated workspace with memory, files, permissions, sandboxing, and scheduled tasks, so entire teams of 10-500 can collaborate with shared agents.
QM is early, experiment-scale software, so be prepared to iterate. The central headless core handles the API, identity, policy, and scheduling, with Postgres and per-scope sandboxes. Set up the core, connect it to your Slack and web environments, then create isolated workspaces for the rooms or teams you want agents to operate in.
QM uses a three-tier security model designed to prevent agents or users from crossing trust boundaries. Each scope has its own isolated sandbox, and the agent exposes a minimal tool surface—notably a single execute tool—to keep the attack surface small and limit what commands can access outside the sandbox.
QM is built to be harness-agnostic. It handles orchestration, identity, policy, and scheduling through its headless core while providing isolated workspaces per person and room, so you can connect different harnesses and route their agents through the same shared infrastructure.
Slack's built-in AI features are usually designed for personal assistance or simple chat summaries. QM forges persistent, shared agent workspaces for each room, with cross-team isolation, crons, keychain permissions, web apps, and durable sandboxes. That makes it suited for real production work where agents need shared context and controlled execution, not just chat answers.
