QM
“A multiplayer agent harness for work. In Slack and on the web.” From yc-software (Y Combinator), MIT-licensed, TypeScript. Created 2026-07-29 and 8,967★ within five days — the fastest-rising artifact in this corpus.
Its framing is a direct rejection of the shape every other agent product here takes:
Most agents are designed like personal assistants. You can make one work for a whole company, but it quickly gets complex. QM is designed for startups.
See agent-scope-isolation for the mechanism that follows from it.
Architecture
A headless core (TypeScript on Node, Fastify) holds identity, policy and the scheduler, with Postgres for sessions, memory and the queue. Every turn routes through core; the agent loop is pluggable — Pi, OpenCode, Codex and Claude Code all drive the same core, which the README sells as vendor independence rather than as a feature of any one harness.
The tool surface is deliberately small and fixed. One of those tools is execute, which runs
commands in the scope’s own durable sandbox — “its durable computer, where installed tools stay
installed.” Surfaces are optional plugins over core’s HTTP API: web UI (Vite + Lit), admin panel,
public portal, and an in-process Slack plugin (Bolt) that core supervises.
Everything company-specific lives in a deployment directory validated and deployed by the qm
CLI, and every substrate — harness, session store, sandbox, memory — sits behind an interface that
swaps via one wiring file. Deployments run in the operator’s own cloud (Fly or AWS).
The security posture ladder
An org picks one posture; narrower scopes may only tighten it:
- Strict — every harness tool call pauses for human approval, except the two no-effect turn enders.
- Auto (default) — a classifier screens provenance-labelled external data and tool results before they reach the model; a deployment can point that at its own screening proxy.
- Dangerous — no content screening, no pauses.
The predeclared command policy — approval rules and hard denials for recursive deletes, destructive SQL and the like — applies in every posture, Dangerous included. So the ladder governs review, while a floor governs effects, and the floor is not user-selectable. That structure is what agent-guardrails has been circling.
The limitations list is the document worth reading
SECURITY.md is 9.9 KB and most of it is what the product does not guarantee. That is unusual
enough to be the reason this repo earns a page beyond its star count.
The architectural commitment is stated plainly, and it is the containment position:
The agent and software it runs in a sandbox are not trusted to make authorization decisions. Core is intended to enforce identity, scope, grants, delivery, and deterministic effect gates around them.
Then the admissions. On its own command policy:
Command policy is bypassable. It classifies shell text and catches configured or common dangerous forms, but obfuscation, encoding, or writing and then executing a script can evade it. It is a speed bump against mistakes and injection, not a sandbox boundary.
That is constraint-evading-behavior written by the vendor about its own control. Others in the same list:
- Credential purposes are not enforced authorization. The stated purpose “travels with the credential as an instruction to the model and an audit field; core does not determine whether a later command stays within that purpose.”
- Sandbox credentials are plaintext while in use — readable by any process in that sandbox, and scope isolation “does not stop a compromised agent process from spending or exfiltrating usable credentials.”
- Screening is heuristic and incomplete — command output, opaque or multimodal results and raw webhook payloads aren’t all covered, and “classifier approval is not authorization and cannot guarantee prompt-injection resistance.”
- Browser actions sit outside some core gates — they don’t re-enter command policy or human-in-the-loop approval, and exit through the browser provider rather than QM’s egress proxy.
- Published-app capability links are bearer authorization — anyone holding the link reaches the app, ACL changes don’t revoke existing holders.
- Admins are privileged content readers, audited but not consent-gated, across transcripts, memory, documents and skill bodies.
- Durable data outlives expectations — request capture on by default, file artifacts with no expiry and no reclamation implemented.
And the line that generalizes past this product: “An approval means a human accepted the displayed action under the information available at that time, not that the resulting behavior is safe.”
Two governance choices worth copying
Dependency cooldown. min-release-age=7 in .npmrc — newly published npm versions must age
seven days before entering a lockfile, aimed squarely at the compromised-maintainer window where
a malicious version is published and yanked within hours. CI uses npm ci from committed lockfiles
and is unaffected; urgent fixes can be pinned explicitly past the window. A concrete supply-chain
control, and the first one in this corpus.
Contributions as prose, not code. CONTRIBUTING.md asks for a .txt or .md file in adrs/
describing the change informally — “just run your idea by us in the same way you would a coworker
or friend” — and the maintainers implement it: “we’re happy to burn our tokens on the underlying
implementation.” Explicitly, “please do not have AI artificially expand what you’d like to do into
a formal proposal.” Given that coding agents write most of the code, the scarce reviewable artifact
becomes human intent, and the PR reverts to being a conversation.
One small detail with a citation attached
The repo’s CLAUDE.md is nine bytes — the string AGENTS.md. A pointer, not a second copy.
Worth noting beside context-files-ablation-paper, which measured AGENTS.md-style context and
found no correlation with correctness: a project this careful about its instruction file still
treats it as one artifact with one home, and the file it points at is mostly process (review
depth, where helpers live, what to run locally) rather than repository facts.
Its AGENTS.md includes a rule this hub’s own practice rhymes with: never merge without a
fresh-context adversarial pass, “the context that produced a diff already believes it is correct,
and that belief is the bias review exists to defeat” — with review depth scaled by blast radius
judged from callers, not file count, and the reviewer rather than the author setting that depth.
Tier
T1 — primary artifact: the source, the licence, the threat model and the config are all inspectable. Everything about how well it works is self-description; there are no benchmarks, no deployment evidence beyond YC’s own, and the repo is five days old with 109 open issues. The security document is candid about design intent, and candour about limitations is not the same as their absence. Its own first sentence: “It is early, experimental software: that design goal is not a promise that data cannot leak, a certification, or a substitute for a deployment-specific security review.”
Related
agent-scope-isolation · agent-guardrails · constraint-evading-behavior · agentic-coding-harness · agent-orchestration · agent-memory · agent-skills · agents-md · context-files-ablation-paper · cloud-run-sandboxes · synthesis