Back to Home

YC Just Shipped the Anti-Personal-Assistant. It Validates Every Bet OpenClaw Made — From the Opposite Direction.

9 min read
Sumeet Zankar

Sumeet Zankar

AI Solutions Specialist & Full-Stack Developer

Two of the most opinionated agent harnesses in open source just agreed on the architecture of this layer and disagreed, hard, on who it's for. That disagreement is a better map of where agent infrastructure is heading than any model benchmark this quarter.

On July 31, 2026, Y Combinator open-sourced QM — the multi-agent harness they run the firm on. Accounting, legal, events, engineering. They even built QM inside QM. MIT license. github.com/yc-software/qm. Around 1.9k stars in the first day.

The interesting thing isn't the release. It's that YC's own README name-drops OpenClaw and Hermes as the reference points, then draws a line: "easy to customize like those, but built for a whole company."

That line is the whole story.

What QM actually is

Strip the announcement thread and the README says four things:

  1. Every person AND every room gets its own scope. Scoped memory, files, keychain view, permissions, crons, web apps, and a durable sandbox. Not just per-user — per Slack channel, per group DM, per project. Rooms are first-class citizens.
  2. The core is harness-agnostic. Pi, OpenCode, Codex, and Claude Code all drive the same TypeScript-on-Node core. Swap the coding loop behind one interface. Postgres holds sessions, memory, and the queue.
  3. The tool surface is deliberately small. One of the tools is execute, which runs commands inside the scope's durable sandbox — installed tools stay installed. Everything else is a plugin over the core's HTTP API. Slack (Bolt), web UI (Vite + Lit), admin, portal.
  4. Everything specific to your org lives in a deployment directory. Core stays byte-identical to upstream. Custom skills, sandbox image, infra config, secrets — all in deploy/layers/<org>/. Merges stay small.

There's a security posture switch — Strict, Auto, Dangerous — with a predeclared command policy that holds even in Dangerous mode. No rm -rf /, no destructive SQL, no exceptions. And there's a weird, telling detail: contributions are accepted as human-written prose in adrs/, not code PRs. YC implements aligned proposals internally.

That last point is not a quirk. It's the shape of the project telegraphing what YC thinks the harness layer needs: opinionated ownership, not community drift.

Where QM and OpenClaw actually agree

Before the fork in the road, note what they don't disagree on. Both bet the same way on the questions that actually matter:

  • The harness layer matters more than the model. Neither project is trying to be a model. Both assume you'll swap models — and, in QM's case, entire coding loops — behind an interface.
  • Skills are the primitive. OpenClaw's SKILL.md files and QM's scope-owned, grant-shareable, git-importable skill packs are the same idea with different packaging: capabilities as loadable, versioned, human-readable units.
  • Sandboxes are durable, not ephemeral. Both refuse the "fresh container per turn" pattern. State persists. Installed tools stay installed. The agent's computer is a real computer.
  • Cron and background work are core, not add-ons. Unattended runs are how these systems actually earn their keep.
  • Approvals are a first-class control plane. Not decorative safety theater — a switch operators tune.

If you've been reading OpenClaw's architecture as niche opinionation, QM's release is the second data point. It's not niche. It's where the harness layer is settling.

Where they fork — and why it's the interesting bit

The disagreement is one question: who is the user?

DimensionQMOpenClaw
Primary scopePerson AND room, as equalsPerson; agent as an extension of you
Deployment shapeCloud-first (Fly / AWS + Postgres)Local / gateway-first, own your substrate
Sharing modelGrant-based, admin-promotable, org-wide skill packsPersonal by default; sharing is deliberate
GovernanceAdmin postures, org-level policy planeOwner-operator; you are the admin
Contribution modelProse ADRs; YC implementsOpen PRs; community-shaped
Mental modelAgent as org infrastructureAgent as extension of self

QM treats the agent the way a company treats Slack: an environment employees log into, with room-level shared context that outlives any one person. OpenClaw treats the agent the way you treat your shell: yours, tuned, portable, boring to explain and impossible to give up.

Both are correct. They're solving different problems that happen to share an architecture.

The contrarian reading

The obvious take is "QM competes with OpenClaw." It doesn't. They compete for the same architectural bets and split the market cleanly.

The interesting reading: YC's release is the strongest external validation OpenClaw has gotten. Every bet OpenClaw made about the harness layer — durable sandboxes, skills as the primitive, harness-agnostic cores, crons as first-class, approvals as a switch — is now also the bet the most influential accelerator in tech is making. From the opposite end of the "who is the user" spectrum.

When two teams reach the same architecture from opposite starting points, it's usually not coincidence. It's the shape of the problem.

What to actually take from this if you're building

Three things worth stealing regardless of which harness you use:

  1. Separate core from deployment layers, byte-for-byte. QM's deploy/layers/<org>/ pattern — and its explicit warning against GitHub's Fork button (visibility inheritance, shared object network, commits pushed to a "private" fork of a public repo stay fetchable by SHA from the public side) — is the operational lesson most open-source-agent teams learn the painful way. Do the plain clone. Add upstream as a remote. Keep merges small.
  2. Pick your security posture before you pick your tools. Strict / Auto / Dangerous is a good default vocabulary. Predeclared hard denials that survive even the loosest posture are better than the "we'll ask nicely" pattern most agents ship with.
  3. Rooms are underrated. Most open-source harnesses model a user. QM modeling rooms as scopes with their own memory, files, and permissions is the design decision that makes the "agent in the shared project channel" pattern actually work. If you're building for teams, room-scope is not optional.

Where this leaves the space

The agent harness layer is real, it's opinionated, and the interesting projects in it have stopped pretending they're neutral platforms. QM says: agents belong to the company. OpenClaw says: agents belong to the person. Neither is wrong. Both are shipping.

The dead middle — "generic agent framework, bring your own opinions" — is the position that keeps losing. You don't want a framework. You want a harness that already decided who the user is and defends that choice with its architecture.

Pick your side. Both sides are good bets.

Sources

AI AgentsAgent HarnessY CombinatorOpenClawOpen Source

Enjoyed this article?

Connect with me on LinkedIn for more insights on AI, automation, and full-stack development.