What YC's QM Teaches About Rolling Out AI Agents
YC open-sourced QM, the agent harness it uses internally. Here's how scoped memory, sandboxes and approval modes let one agent setup serve a whole company.
QM is an open-source, MIT-licensed "multiplayer agent harness for work" from Y Combinator. It runs one agent setup for a whole company in Slack and on the web, while each person and each room gets its own scoped memory, files, keychain view, permissions, crons, web apps and durable sandbox. YC says it uses QM internally across accounting, legal, events and engineering. You deploy it in your own cloud, with your own models and keys.
Most agent tools I use are built for one person. Claude Code, Codex and the MCP servers I've been building for well over a year all assume one operator with one set of credentials. That works on a laptop. It gets messy once you hand the same agent to every team and Slack channel in a company, including a finance team that should never see engineering's keys.
So when YC open-sourced the harness it runs internally, I read the README, the security policy and the memory docs end to end. The repo was created on July 29, 2026, and by October 21 it had 15,470 GitHub stars and 1,914 forks. Below is how it works and which parts I'd copy even if you never deploy it.
What is YC's QM?
The README describes QM as "a multiplayer agent harness for work. In Slack and on the web." When Y Combinator announced it on LinkedIn, it called QM "a multi-agent harness we use internally at YC" and said the team uses it "across accounting, legal, events, and engineering (including building QM itself!)." The same post calls it an experiment that is "early and has bugs." I'd take that at face value.
The README states the problem plainly: "Most agents are designed like personal assistants. You can make one work for a whole company, but it quickly gets complex." QM is aimed at startups. Each employee gets an isolated workspace, and people can also work with the agent together in channels, group messages and projects.
It isn't tied to one model vendor. Pi and Claude Code both drive the same core, and Pi runs models from many providers. Admins choose which harnesses and models are available. The latest release, v0.1.15 from October 20, 2026, removed the Codex and OpenCode harnesses, so check what your version supports before you plan around one.
Why do personal agents break when a whole company uses them?
Put a personal agent in a shared Slack channel and a set of questions shows up that has nothing to do with the model. Whose credentials does it run under? Who can see what it remembers? Who owns the scheduled job it set up last week? Who approved the thing it just did?
Before product, I spent years in test automation and RPA, including setting up the RPA Center of Excellence at Hudson's Bay Company and later working at Automation Anywhere. Automation programs have always had to answer those questions before bots go company-wide, and agents now have to answer them too. At Sprouts I drove company-wide adoption of Claude Code through Claude on AWS Bedrock, so this is close to home.
QM's answer is to give every person and every room its own scope and to have the core enforce the boundaries. Its security policy is explicit that "the agent and software it runs in a sandbox are not trusted to make authorization decisions."
How does QM keep each person's and each room's work separate?
Every turn goes through a central core: an API layer for identity, policy and scheduling, plus the agent loop. Postgres holds sessions, memory and the job queue. The README warns that without DATABASE_URL and SESSION_STORE=postgres, "sessions live in process memory and vanish on restart," so treat Postgres as required for anything real.
The agent gets a small, fixed set of tools. One of them is execute, which runs commands in the scope's own isolated sandbox, which the README calls "its durable computer, where installed tools stay installed." A person, a channel, a group chat and a project each get their own sandbox, files, crons and memory.
Memory is the most careful part of the design. Each turn carries at most 6,000 characters of memory, picked from the notebooks that conversation is allowed to read. With Postgres and an embedding model, facts are ranked by cosine similarity to the current message and recent dialogue. Without one, the newest facts come first. In my Ralph Wigum loop post I wrote that the fix for long agent runs was better state management. QM's cap keeps that state small enough to ride along on every turn.
You can also route memory by scope to external providers over MCP. The docs show org-level knowledge going to a company knowledge server with separate OAuth credentials for reads and writes, while QM still decides which scopes can read or write and passes along the acting user. As someone who builds MCP servers, I like that a company knowledge base can live outside QM and still respect who is asking.
Everything specific to one company (org config, custom tools, skills, the sandbox image and infrastructure) lives in a separate deployment directory, and the core stays generic.
How does QM handle security and approvals?
QM follows the model of local coding agents like Claude Code, Codex and OpenCode. The agent acts as the person it's working for, with their credentials and permissions, and everything it does is audited. An org picks one security posture, and narrower scopes can only tighten it:
Strict: every harness tool call pauses for human approval, except two turn-ending tools that have no effect.
Auto, the default: blocks private-network access.
Dangerous: no tool approval gates, and content screening only observes.
Content screening is a separate setting and is off by default. When it's on, it can either log verdicts or enforce them, and enforce mode quarantines flagged external content until someone approves its release. A predeclared command policy, with approval rules and hard denials for things like recursive deletes and destructive SQL, applies in every posture, Dangerous included.
Sharing has its own setting. Isolated, the default, keeps resources inside their scope unless someone shares them. Open lets a speaker's opted-in personal files, artifacts, skills and memory be read in an opted-in shared room, during a live, authenticated turn by that person.
The section of SECURITY.md I'd send to every team building agents covers three actions the agent can't take through its own API: changing admin grants, impersonating another person, and approving gated commands. Each of those, the policy says, "authorizes future agent behavior, so the decision itself must come from outside the agent." In Why the Agent Stack Is the Real Revolution I argued that you should treat SKILL.md as executable code and audit it. QM applies the same thinking to permissions. Skills are owned by a scope and shared by grant, promoting one to the whole org needs an admin, and skill packs can be imported from git repositories.
What can teams do with QM?
The README lists the work it's meant for:
Search internal notes, email, documents, databases and the web together.
Build internal apps, publish them to the right people, and keep their data current.
Learn your writing voice from past sends, then triage your inbox on a schedule, with labels and reply drafts.
Work in an existing repository: run tests, open PRs, monitor CI and check system logs.
Track a project in a shared channel and post updates and follow-ups.
Crons, watches and inbound webhooks keep working while you're away. There's also a swarms feature for durable pools of worker agents, which is off by default behind a per-person feature flag.
My QA years make me look twice at the repository item. An agent that runs tests, opens PRs and watches CI from a shared channel is useful, and somebody still has to own the test strategy and read what it did. That's why I'd start with the strictest posture and the audit log open.
How would I roll out QM-style agents at a company?
This is my sequence, not official QM guidance, and it works with any harness that has scopes and approval modes:
Start one team on Strict with Isolated sharing. Every tool call waits for a human. It's slow, and it shows you exactly what the agent tries to do.
Add one shared room for a real workflow, such as a project channel that posts a weekly status update, so that room's memory and jobs have a clear owner.
Promote only skills that someone has reviewed, from a pinned git pack, through the admin gate.
Move the org to Auto once the audit trail looks clean, and tighten finance or legal rooms back to Strict, since narrower scopes can only make the posture stricter.
How do you deploy QM?
The README's quickest setup is a sentence you give your coding agent: Let's deploy https://github.com/yc-software/qm. For a real org deployment, you create an organization-owned repository that depends on the @yc-software/qm package and initialize it for Fly.io or AWS:
npm exec --yes --package=@yc-software/qm@latest -- \ qm init . --org <slug> --target <fly-or-aws>npm installInitialization creates a deployment skill for an agent to follow. It walks through infrastructure, web sign-in, connector credentials, optional Slack access, deployment and a live check. Sign-in defaults to a built-in broker that emails a one-time link. Each deployment runs in your own cloud account, and QM doesn't generate deployment CI for you. If you'd rather not host it, the README links to a third-party hosted version.
What are QM's limits right now?
SECURITY.md is unusually candid. It calls QM "early, experimental software" and says it "is not a hardened public or multi-tenant service boundary." It assumes one organization of authenticated internal users. It also lists known limitations:
The command policy can be bypassed with obfuscation, encoding or a script written and then run. The policy calls it "a speed bump against mistakes and injection, not a sandbox boundary."
Actions inside the browser runner don't go back through command policy or human approval.
Credentials are plaintext inside the sandbox while they're in use.
In Open sharing, the model decides what private data ends up in a shared reply once access is authorized.
Breaking changes are still landing between releases, as the harness removals in v0.1.15 show. Contributions work differently too. The README says "We take contributions as human-written text, not code," so feature ideas go in as short notes in an adrs/ folder and the maintainers handle the implementation.
I wouldn't put QM in front of customers. For an internal pilot with one team, it's the most complete open-source answer I've read to the questions every company-wide agent rollout runs into. It also sits well next to the argument I made in The End of the Visual Web: agents work better with typed contracts and clear boundaries.
If your company gave every team an agent tomorrow, who would own the memory in each Slack channel?
Frequently asked questions
Is YC's QM free and open source?
Yes. QM is under the MIT license, except where the repo notes otherwise. You run it in your own cloud account with your own model keys, so your costs are hosting and model usage.
Does Y Combinator use QM internally?
According to YC's announcement, yes. YC said QM is a multi-agent harness it uses internally across accounting, legal, events and engineering, including to build QM itself.
Which models and harnesses does QM support?
Pi and Claude Code both drive QM's core, and Pi runs models from many providers. Admins choose which harnesses and models people can use. Release v0.1.15 removed the Codex and OpenCode harnesses.
Where can I deploy QM?
The qm init command targets Fly.io or AWS. On AWS, services run on ECS Fargate with Lambda MicroVM agent computers. On Fly, they run as Fly apps with Fly Machines for agent computers. Docker runs the services locally.
How is QM different from a personal coding agent?
A personal coding agent serves one person with one set of credentials. QM gives every person and every shared room its own scope with separate memory, files, sandbox and jobs, and adds org-level admin control over security posture, sharing, models and skills.
Can I contribute code to QM?
The maintainers prefer feature proposals as human-written text. You open a pull request that adds a .txt or .md file to the adrs/ folder. Bugs go in issues, and security vulnerabilities should be reported privately.
Sources
Stay in the loop
Get notified when I publish new articles and projects.
