YC open-sourced qm, the agent harness it runs internally

Y Combinator open-sourced the agent system it runs on its own staff. The repository, called qm, surfaced publicly on Hacker News at 18:04 UTC this evening and had 437 stars inside the first hour. It is MIT-licensed TypeScript, it lives in Slack and in a browser, and its whole reason for existing is a problem most agent tooling ignores: what happens when an entire company, not one developer, shares an agent.

The pitch is in the first line of the README. Most agents are built like personal assistants, and you can stretch one to cover a whole company, but it gets messy fast. qm splits the difference by giving every employee an isolated workspace and letting those same people pull the agent into shared channels and projects when the work is shared. Each person and each room carries its own memory, files, keychain view, permissions, cron jobs, published web apps and durable sandbox.

RelatedDeepSeek V4 Flash claims 82.7 on Terminal-Bench 2.1

• qm is self-hosted by design. Every deployment runs in the operator's own cloud account, initialised with a single qm init command targeting Fly or AWS.
• The harness is pluggable: Pi, OpenCode, Codex and Claude Code all drive the same core, so the deployment is not tied to one model vendor.
• Isolation is per scope, not per user. A Slack channel gets the same treatment as a person, with its own memory and its own credential view.
• The security document is unusually blunt about what the design does not guarantee, including that the agent is not trusted to make authorization decisions.

What did Y Combinator actually ship?

The core is TypeScript running directly on Node with Fastify handling HTTP, and Postgres underneath holding sessions, memory and the job queue. The Slack integration is a Bolt plugin that the core starts and supervises. The web UI is built with Vite and rendered with Lit. None of that is exotic, and that seems deliberate: the interesting engineering is in the boundaries, not the stack.

The agent gets a small, fixed tool surface. One of those tools is execute, which runs commands inside the scope's own sandbox, described in the docs as a durable computer where installed tools stay installed between sessions. That single choice explains a lot of the rest of the design. If the agent's real power comes from running shell commands in a persistent machine, then the machine has to belong to somebody specific, and the credentials inside it have to be that person's credentials.

Everything company-specific lives in a separate deployment directory rather than in a fork of the source: org config, custom tools and skills, the sandbox image, the infrastructure. The CLI validates that directory and deploys it. For companies that want the whole codebase in one place instead, YC recommends a private clone rather than a GitHub fork, and explains why in a paragraph worth reading if you have ever tried to make a fork private: forks inherit the visibility of the repo they came from, and they share an object network, so commits pushed to the fork stay fetchable by SHA from the public side.

Why does giving everyone an agent change the architecture?

A single-user coding agent has an easy security story. It runs as you, on your laptop, with your keys, and if it does something stupid the blast radius is your working directory. Move that to a company and the easy story stops working. Two employees have different access to the CRM. A Slack channel with a contractor in it should not inherit a full-time engineer's database credentials. A cron job that fires at 3am has to act as somebody.

qm answers that by resolving a principal and a scope on every turn, then separating workspaces along that boundary and recording the actions. Skills are owned by a scope and shared by explicit grant, with promotion to the whole org gated behind an admin. Published internal apps are their own trust boundary: an owner can hand a capability link to somebody outside the company, and holding that link buys access to the app and nothing else, not a login and not the agent.

What does the threat model admit?

This is the part of the release that deserves the most attention, because it is the part vendors normally bury. qm's security policy opens by calling itself early, experimental software and says the isolation goal is not a promise that data cannot leak. It then goes further than most: the agent and the software it runs in a sandbox are not trusted to make authorization decisions. The core is supposed to enforce identity, scope, grants and delivery around them.

Read that as an engineering position, not a disclaimer. It says the model will eventually be talked into something it should not do, so the enforcement has to sit somewhere the model cannot reach. The same document notes that an org admin is a privileged content reader and not only a policy administrator, that surface and connector inputs are untrusted data even when the sender is authenticated, and that the controls are not a guarantee the model cannot disclose data.

The posture system in Fig 2 follows from that. Auto is the default because it is the compromise: a classifier screens external content before it reaches the model, and a deployment can point that screening at its own proxy. Strict makes the agent nearly unusable for background work by design, since every tool call waits on a person. Dangerous is named the way it is on purpose. The predeclared command policy, the approval rules and hard denials for things like recursive deletes and destructive SQL, sits under all three and does not switch off.

Why is YC asking for text instead of pull requests?

The contributing file inverts the usual open-source deal. Instead of code, YC wants an informal written description of the change, dropped into an adrs/ folder as a text or markdown file, phrased the way you would explain it to a coworker over Slack. If they agree with the idea, they write the implementation themselves. The file adds one specific instruction: do not have AI expand your suggestion into a formal proposal.

RelatedClaude Code Adds a Built-In Browser That Reads the Live Web

That policy took over the early Hacker News thread, and the reaction split in a way that says something about where open source is right now. Several maintainers called it obviously better than receiving an unexplained agent-written diff. Somebody pointed out that SQLite has refused outside patches for years, for different reasons. Others found it funny that a project built with coding agents is asking humans to write the prose. All of those reads are fair. The policy is a bet that in a world where generating a large PR costs almost nothing, the scarce input is a well-formed idea, and review time is the thing worth protecting.

1. Jul 29, 2026Repository created on GitHub yc-software/qm
2. Jul 31, 18:04 UTCPosted to Hacker News, front page within the hour 57 points, 22 comments
3. Jul 31, ~19:00 UTC437 stars, 36 forks, 2 open issues first-hour pickup
4. NextFirst outside deployments report back on the sandbox boundary the real test

Who should actually deploy this?

Companies already running a fleet of always-on agents and feeling the seams. The Hacker News thread was full of those people describing what they use internal agents for: first responder on production alerts, automatic fixes for simple CI failures, drafting incident reports from alerts, webhook-triggered jobs against internal systems. Every one of those workloads needs an identity, and most homegrown setups solve it by giving one shared bot account access to everything, which is exactly the arrangement qm is built to replace.

It is a worse fit if you want a managed product. Somebody has to own the Postgres, the object storage, the identity provider and the sandbox backend, and the security policy states plainly that qm does not protect a deployment from a compromised operator. It is also explicitly not a hardened public or multi-tenant boundary, so building a customer-facing service on top of it would be reading the docs backwards.

Our take

The multiplayer framing is good marketing, but the scoping is the actual product. Anyone can wire an agent into Slack in a weekend; the hard part is that the second employee to use it should not inherit the first one's access, and almost nobody solves that before it bites them. qm shipping with that boundary already drawn, plus an audit trail, is worth more than any feature on the list.

The security policy is the reason to take the release seriously. A company that wanted stars would have written a paragraph about enterprise-grade isolation. YC published a threat model that names its own limitations, tells operators what they are responsible for, and admits the model can still leak data. That is a document written by people who expect to be held to it, and in a category currently full of confident claims about agent safety, it is the rarer artifact.

Original analysis by GenZTech. Release first surfaced via Hacker News.