On July 31, the public yc-software/qm repository was published alongside Y Combinator's statement that it already uses QM across accounting, legal, events, and engineering. The launch promises are broad—cloud-first, Slack- and web-native, MIT-licensed, and able to run Pi, OpenCode, Codex, or Claude Code. The source makes a narrower and more useful fact visible: the address of a conversation becomes a tenancy decision before a harness runs.
The message chooses who owns the computer
QM's resolution service turns a direct message into a personal scope, a group message into a group scope, and a channel into a channel scope. It then assembles two primary workspace layers: organization state mounted read-only, and the active scope mounted read-write. In a direct message, team layers can also be mounted read-only. Grants add explicitly shared handles. Organization policy composes with narrower scope policy before the agent gets a command surface, network rules, or approval modes.
That is a small amount of code carrying a large product claim. The same person can ask an agent a private question in a direct message, continue a shared project in a channel, and enter a group conversation without those rooms being treated as labels on one undifferentiated transcript. The scope types extend beyond chat history to workspace layers, grants, sessions, background triggers, delivery provenance, command policy, and egress policy.
The model loop comes later. QM defines a typed harness contract for turn execution, model utilities, tool naming, transport shape, and capabilities such as abort, steering, images, fast mode, and provider sessions. Its router chooses an approved harness and model using organization and scope configuration, refuses an unapproved requested pairing, and resets adapter-specific session state when a conversation switches harness.
The selected harness sees a small core tool surface. The consequential tool is execution inside the scope's agent computer. QM's sandbox interface separates provisioning, file movement, process sessions, backup, teardown, persistence style, and egress enforcement from the agent loop. The public deployment path supports local execution, Fly Sprites, and AWS MicroVMs. Sessions, memory, queues, audit data, configuration, and background activity have Postgres-backed implementations because the core expects blue-green and multi-instance operation rather than one immortal Node process.
The result is closer to an organization runtime than a chatbot. A room can own files, memory, credentials, skills, cron jobs, web apps, and a computer that is still there when the next person returns. A person can have a separate version of the same affordances. QM's wager is that this ownership map—not the chosen model—is what turns a useful personal agent into shared infrastructure.
The loop is the replaceable part
QM is not a clean substitute for Buzz, a personal-agent harness, or a workflow framework. Those systems start with different durable objects: a collaboration network, one operator's session, or an application-defined job. QM starts with an organization plus personal and shared-room scopes. That difference tells an operator where risk accumulates: not only in a model response, but in cross-scope leakage, ambient credentials, offboarding, and which computer remains reachable after a conversation ends. The company becomes the environment the agent must not flatten.
The source is candid about how far the answer has to go
QM's strongest trust signal is not a claim of security. It is the specificity of its security policy. The document says the software is early and experimental, is not a hardened public or multi-tenant service boundary, and does not protect a deployment from a malicious or compromised operator. Organization admins are privileged content readers. Model and browser providers receive the data sent to them.
It also lists implementation gaps that matter directly to the thesis. Command policy can be bypassed by obfuscation or by writing and running a script. Browser actions do not pass through every core command and approval gate. Credentials are plaintext while a sandbox process uses them. Purpose text attached to a credential is not enforced confinement. Security screening is heuristic and incomplete. Audience-floor filtering lacks complete origin labels. Egress enforcement depends on the backend. Durable artifacts can outlive user expectations. Some provider paths bypass the intended model gateway, and governance changes are not uniformly versioned or revertible.
The three named postures should therefore be read as operating tradeoffs, not magic safety levels. Strict pauses almost every harness tool call for approval. Auto screens supported provenance-labelled external content before it reaches the model, but the project documents missing surfaces. Dangerous removes those pauses and screening while retaining predeclared denials. The command-policy code recognizes recursive deletion, destructive SQL, filesystem formatting, and pipe-to-shell patterns, but the threat model explicitly calls that a speed bump rather than a sandbox boundary.
There is encouraging engineering beneath the caveat. A fresh model-picker change did not stop at the UI; it closed alternate runtime-configuration and stale-override paths and added an application-level test. The new release workflow records image digests, handles partial publish recovery, and documents remaining races after an adversarial review. A public playground mode was tightened around anonymous identity, rate limits, cookie domains, apps, proxies, secrets, and IPv6 budgets. These are receipts for engineering habits, not proof that every boundary is correct.
What to expect if you try it
Expect infrastructure, not a desktop toy. The supported path creates an organization-owned deployment directory, pins the QM CLI version that interprets it, computes the secret set, builds or selects a sandbox substrate, deploys core and optional services, and runs live checks. Docker is the local path; Fly and AWS are the public cloud paths. A real harness expects HTTPS, Postgres, identity, model credentials, and a deliberate sandbox and egress posture.
Expect to pilot it inside the boundary the project actually claims: one organization of authenticated internal users. Do not treat a green deployment as proof of non-interference. Start with disposable or low-sensitivity scopes, make the admin read model explicit, test what crosses from a personal message into a shared room, exercise offboarding and revocation, inspect model-request capture and retention, and verify the effective backend's network enforcement.
Also expect unevenness between harnesses. A shared interface cannot manufacture a capability that an adapter or model path does not have. Abort, steering, provider sessions, thinking controls, tool names, compaction, and replay differ. QM makes those differences visible in profiles, but a company still has to decide whether switching harnesses mid-conversation preserves enough meaning—and whether the operator can tell what changed.
Most of all, expect the difficult work to move from prompting into policy. Once the same system can read internal notes, draft email, investigate production, publish an app, and wake on a cron, the interesting configuration is no longer “Which model is smartest?” It is “Which scope owns this capability, which audience can see the result, and what evidence survives?”
The contribution opening is judgment, not generated code
QM's most provocative design choice may be social rather than technical. Its contribution guide asks outsiders not to send implementation pull requests. Because coding agents write most of the underlying code, the maintainers want concise, human-written text under the repository's ADR directory: explain the change as you would to a coworker, align on it, and let the project spend its own tokens implementing it.
The Hacker News thread predictably split on that request. Some readers saw absurdity or an invitation to write prompts for the maintainers. Others with open-source experience preferred a clear bug report or design statement to a drive-by generated diff. The practical lesson for builders is sharper: this repository rewards problem selection, boundary design, and falsifiable examples more than typing speed.
A contribution that stands out could take one documented limitation and make its invariant testable:
- Show a minimal cross-scope history case that the incomplete origin labels cannot filter correctly, then state the audience rule that must hold.
- Define a backend-independent egress conformance test so a deployment cannot claim a stronger network posture than its sandbox enforces.
- Specify retention and deletion semantics for transcripts, model-request captures, artifacts, and offboarded principals.
The winning ADR would be short, specific, and slightly adversarial. Name the affected scope, the authority that should apply, the failure that currently slips through, the observable acceptance test, and the recovery behavior. Do not inflate it into a vision document. In a codebase where agents can produce implementation quickly, the scarce contribution is a better boundary.
QM is worth watching for the same reason it is not yet safe to romanticize. It has moved the company-agent question out of the demo and into the machinery of ownership. The next signal is not another connector or model logo. It is whether the project can make “who owns what” remain true under migration, offboarding, background work, browser actions, shared credentials, and a real incident.