← Back to all posts
Tools

Y Combinator Open-Sourced Its Agent Harness. Send Prose, Not Code.

August 1, 2026 · 03:12 UTC · Tools
Y Combinator Open-Sourced Its Agent Harness. Send Prose, Not Code.

TL;DR

Y Combinator has open-sourced QM, the agent harness it runs its own company on, under the MIT license. It is not another personal coding assistant. It is the org-shaped version: every employee and every project gets its own scope, with its own memory, files, credentials, permissions, crons, and a durable sandbox, all reachable from Slack and a web UI. The harness itself is a slot, so Pi, OpenCode, Codex, and Claude Code all drive the same core. The repo cleared 2,200 stars in its first days and 486 points on Hacker News. And the contributing guide asks you to send human-written text instead of code.


What YC actually shipped

QM is short for quartermaster, which YC's own writeup glosses as "the person on a ship who coordinates belowdecks to keep things in order." That is a fair description of the job. Most agent harnesses assume one human and one machine. QM assumes a company.

The stack is deliberately boring, which for infrastructure is a compliment. TypeScript running directly on Node, Fastify for HTTP, PostgreSQL for sessions, memory and the work queue, a web UI built with Vite and rendered with Lit, and Slack wired in as an optional in-process plugin over Bolt. The web UI, the admin panel, and the public portal are all optional plugins over the core's HTTP API, so a headless deployment is a supported shape rather than an accident.

You do not check out the source to run it. You generate an org-owned deployment repo that depends on the published package:

npm exec --yes --package=@yc-software/qm@latest -- \
  qm init . --org <slug> --target <fly-or-aws>

Targets are Fly or AWS, and every deployment runs in the operator's own cloud account. The README is blunt that initialization does not generate or enable deployment CI, and that the repository ships no production deployment workflow. You own the pipeline.

one core, a swappable harness, one sandbox per scope Slack + web UIone identity headless coreidentity . policy . cron scope sandboxdurable, per person postgres: sessions . memory . queue harness slot: pi | opencode | codex | claude code swap the model vendor without touching the core
The agent has a small fixed tool surface. One of those tools runs commands inside the scope's own sandbox.

The harness slot is the whole pitch

The line in the README that matters most to anyone who has been burned by a vendor is this one: "Pick your own harness and model and switch between them." The repo backs it up in code, with four adapters sitting behind one interface in src/harness: pi-harness.ts, opencode-harness.ts, codex-harness.ts, and claude-harness.ts, plus a mock for tests.

Every substrate is treated the same way. Harness, session store, sandbox, and memory each sit behind an interface, and production implementations swap in through a single wiring file. Company-specific material (org config, custom tools and skills, the sandbox image, the infrastructure) lives in a deployment directory rather than in a fork of the core.

The practical upshot: when the price of your current provider moves, or its rate limits do, the blast radius is a config change rather than a rewrite of everything your accounting team has come to depend on.

Scopes: a durable computer per person

The concept doing the heavy lifting is the scope. Each person and each room gets its own scoped memory, files, keychain view, permissions, crons, web apps, and sandbox. The sandbox is explicitly durable: installed tools stay installed between turns.

Think of it less like a rental car you return spotless after every trip and more like a workbench in a shared shop. You bolt a vise to yours, and next week the vise is still there, still yours, and nobody else has to look at it.

Skills are scope-owned and shared by grant, with admin-gated promotion to the whole org and skill packs importable from git repos. That is the part that decides whether a deployment like this survives contact with a real company: whether the useful thing one person taught their agent can reach everyone else without an admin becoming a bottleneck.

Three postures, and the guardrails that survive all of them

QM's security model follows local coding agents: the agent acts as the person it works for, with their credentials and their permissions, and everything is audited. An org picks exactly one posture, and narrower scopes may only tighten it.

org-wide posture (scopes can only tighten it) Strictevery harness tool call pauses for human approval Autodefault: a classifier screens external data first Dangerousno screening, no pauses between tool calls hard denials (recursive deletes, destructive SQL) apply in all three
Even the posture named Dangerous keeps the predeclared command policy. Someone on that team has been paged before.

In Auto, the default, a classifier screens provenance-labelled external data and tool results before they reach the model, and a deployment can point that screening at its own proxy. That is a direct answer to the prompt-injection problem: label where the bytes came from, then check them at the boundary rather than hoping the model stays skeptical.

The detail worth stealing even if you never run QM is that the predeclared command policy, the approval rules and hard denials for things like recursive deletes and destructive SQL, applies in every posture including Dangerous. Guardrails you can turn off are not guardrails.

How YC got here

The writeup is unusually candid about the road. First came a basic agent loop in Ruby with tools that could reach internal data: easy to get value from on day one, narrow in what it could do. YC extended it with crons and webhook triggers. Then the launch of OpenClaw pushed them in a new direction, and they provisioned over 50 Hermes agents as personal assistants, one per employee.

Managing a fleet of even that size, YC says, became challenging. QM is the attempt to keep Hermes-grade flexibility with the administrative simplicity of the first system, on infrastructure they own.

four generations of internal agents at YC ruby agent loopinternal data crons, webhooksstill narrow 50+ hermeshard to manage qmone core, MIT the fleet problem arrived at 50 agents, not 5,000
YC's own account of what broke at each step. The fourth attempt is the one they open-sourced.

The contributing guide is the most interesting file in the repo

QM does not want your pull requests. From CONTRIBUTING.md: "Given that coding agents write most underlying code now, we'd prefer PRs in the form of human-written text." You describe the change informally, the way you would pitch it to a coworker over Slack, as a .txt or .md file in the adrs/ folder. If YC agrees with the direction, they will, in their words, burn their own tokens on the implementation.

There is an explicit anti-slop clause too: "Please do not have AI artificially expand what you'd like to do into a formal proposal." A repo maintained by a company that runs on agents has decided the scarce input is judgment, not diffs.

Whether it works is an open question. At the time of writing, the adrs/ folder contains exactly one file, and it is .gitkeep. The prose is, for now, aspirational.

What the room made of it

The Hacker News thread ran to 486 points and 105 comments and was not a coronation. The recurring questions: what does "multiplayer" actually buy you, and how is this different from the assistant products already shipping from the labs. One commenter's verdict, "It's not very novel," collected agreement. Others read the whole thing as a solution hunting for a problem.

The counter-argument is in the repo rather than the thread. Not many open-source projects hand you a company-wide deployment with per-user credential isolation, an admin-set security posture, scoped skill sharing, and a vendor-neutral harness slot, under MIT, with no hosted tier upsell attached. Novelty is not the claim. Ownership is.

Should you run it

If you are one person with one laptop, no. Your existing coding agent is a better fit and you will not miss Postgres.

If you are a small team that has quietly grown a fleet, one agent per person, credentials scattered across everyone's dotfiles, and no idea who approved what, this is aimed squarely at you. Budget for real infrastructure: a Postgres instance, sandboxes, a Slack app, and a cloud account you are prepared to keep patched. The repo is three days old, carries 29 open issues, and includes a pointed warning against using GitHub's Fork button for a private customization (a fork of a public repo cannot be made private, and shares an object network with the public side). Read SECURITY.md before you point it at anything that matters.

Key Takeaways

  • Y Combinator open-sourced QM, the multiplayer agent harness it uses internally, under the MIT license, with self-hosted deployment to Fly or AWS in your own cloud account.
  • Four harnesses (Pi, OpenCode, Codex, Claude Code) drive one core through swappable adapters, so changing model vendors is a wiring change rather than a migration.
  • Each person and room gets an isolated scope: scoped memory, files, keychain view, permissions, crons, web apps, and a durable sandbox where installed tools persist.
  • Three org-wide security postures (Strict, Auto, Dangerous), and the predeclared command policy against things like recursive deletes applies in all three.
  • Contributions are accepted as human-written prose in the adrs/ folder, not code, with an explicit request not to have AI inflate the idea into a formal proposal.
  • The repo passed 2,200 stars and 200 forks within days and drew 486 points on Hacker News, where the loudest critique was that the differentiation from existing assistants is not obvious.

Sources: yc-software/qm on GitHub, Y Combinator, "QM", Hacker News discussion, StartupHub.ai

AIAgentsOpen SourceY CombinatorSelf-HostedDeveloper ToolsSlackTypeScript
CONSOLE
$