yc-software/qm: a multiplayer agent harness that gives every employee their own scope

The problem QM solves: one agent per company does not scale to a team

Personal assistant agents assume a single user. The README is explicit about the failure mode: "You can make one work for a whole company, but it quickly gets complex." QM takes the opposite position. It is built for startups, where employees each get an isolated workspace and work independently, and can still collaborate with the agent in channels, group messages and projects.

The unit of isolation is the scope. The README states that each person and each room has its own scoped memory, files, keychain view, permissions, crons, web apps and durable sandbox. That is a stronger claim than multi-tenancy in a chat wrapper: the sandbox is described as the scope's own isolated computer, where the agent's execute tool runs commands and installed tools stay installed. Two people in the same Slack workspace therefore do not share a filesystem or a credential view by default.

The intended user is a small company that already lives in Slack and wants an internal agent that can search notes, email, documents and databases, build internal apps, triage an inbox on a schedule, or work inside an existing repository. QM is not a consumer chatbot and not a single-developer coding tool. Its identity model is organizational: an org picks a security posture and a sharing posture, and narrower scopes can only tighten them.

Inside the headless core: one turn, one sandbox, Postgres behind it

The architecture diagram in the README shows a Postgres instance holding sessions, memory and a queue, a headless core containing the API with identity, policy and scheduler plus the agent loop, and a per-scope sandbox holding files, tools and logged-in services. The core talks to Postgres and to the sandbox; the loop does not talk to Postgres directly.

The second architecture section adds the details that matter operationally. Every turn runs through a central core, which can use a variety of models and harnesses to generate the response. The agent has a small, fixed tool surface, and one of those tools is execute, which runs commands in the scope's own isolated sandbox. The core is TypeScript running directly on Node with Fastify for HTTP. The Slack plugin uses Bolt and is an optional in-process plugin that core starts and supervises through a direct service client. The web UI builds with Vite and renders with Lit, and shares one service with the admin panel, while the portal and the optional built-in auth broker share another; those modules reach core over its HTTP API.

The vendor-independence claim is structural rather than marketing. Pi, OpenCode, Codex and Claude Code all drive the same core, and every substrate (harness, session store, sandbox, memory) sits behind an interface. Memory can be routed by scope to external providers while retaining the built-in notebook. Everything specific to one company, meaning org config, custom tools and skills, sandbox image and infrastructure, lives in a deployment directory that the qm CLI validates and deploys. That separation is the most interesting design decision in the project: the repository is a generic core plus a CLI contract, not a configured product.

Installing QM: let an agent deploy it, then boot a dev instance

The README does not give a conventional install sequence. Its setup instruction is to tell your coding agent of choice: `Let's deploy https://github.com/yc-software/qm`, after which the agent is expected to follow the deployment guide in the repository. There is also a third-party hosted version linked at agent37.com/qm, and an invitation for infra providers who want to offer a hosted version.

So the practical path for a self-hosted evaluation is the repository itself. Node 24.15.0 or newer and npm 11.10.0 or newer are required by the engines field in package.json. The dev script runs the core with an optional .env file and a file watcher:

npm run dev

The repository's own end-to-end path is dev-instance, which the README describes as exercising a branch against a real model and real Postgres across core, Slack, web, admin and portal. There is a variant that skips Slack:

npm run dev-instance
npm run dev-instance:no-slack
npm run dev-instance:status
npm run dev-instance:down

Configuration is environment-driven, and .env.example is the reference. It sets the harness, the two postures, an org id and a port, and the secrets core needs:

HARNESS=pi
HARNESS_SECURITY_POSTURE=auto
HARNESS_SHARING_POSTURE=isolated
ORG_ID=acme
PORT=8080
CORE_SIGNING_SECRET=
CAPABILITY_SECRET=

For durability, the README is blunt: set DATABASE_URL and SESSION_STORE=postgres, because without it sessions live in process memory and vanish on restart. That single pair of variables is the difference between a demo and something you can leave running. The .env.example also carries rate limits and budgets (RATE_LIMIT_PER_WINDOW, RATE_LIMIT_WINDOW_MS, BUDGET_USD_PER_WINDOW, ORG_BUDGET_USD_PER_WINDOW, BUDGET_WINDOW_MS), which is a useful signal that cost control was considered part of the core rather than an afterthought.

Security posture and sharing posture are two different dials

QM follows the model of local coding agents: the agent acts as the person it is working for, with their credentials and permissions, and everything it does is audited. The org picks one security posture, and narrower scopes can only tighten it.

Strict pauses every harness tool call for human approval, except the two no-effect turn enders. Auto, the default, blocks private-network access and uses a content screener when the deployment configures one; model screening is off by default, and a deployment must either use an external proxy or explicitly opt into the built-in model classifier. Dangerous removes content screening and the pauses between tool calls. The predeclared command policy, which covers approval rules and hard denials for things like recursive deletes or destructive SQL, applies in every posture including Dangerous.

Sharing posture is independent of that. Isolated is the default: resources stay in their scope unless explicitly shared. Open is the interesting one and worth reading closely. On a live authenticated internal human turn, the speaker's opted-in personal files, artifacts, skills and memory may be read in an opted-in shared room. In the speaker's DM, files and skills from up to 25 recent shared contexts where they are still a member become available. Included memories are loaded into the prompt in full with source-scope labels and are also searchable, and the README states plainly that relevance ranking is not applied. The candidate window is limited to 100 recent sessions and file discovery to 200 files. Binary files still require explicit sharing before entering another conversation's computer, and cross-context memory search is available only through the active turn's memory tool; reusable sandbox API tokens keep their original memory scope.

The README is unusually candid about the residual risk: Open can still reveal private information in a shared reply, which is why cross-context reads are provenance-labelled and audited. It also lists what Open does not do, including mounting a personal workspace into a room, carrying credentials or message history, widening writes, running in automation or ambient turns, crossing organizations, adding a teammate's entitlement, or weakening screening, approvals or egress. If your organization's answer to data governance is "keep everything separate until someone asks", Isolated is the correct default and Open is a deliberate, auditable exception.

Where QM is the wrong tool

The strongest limitation is the deployment burden. QM is a headless core plus a deployment directory contract, not a product you install and use. The README points at a deployment guide, deployment.md and docs/combined-services.md for configuration and migration, and the repository ships directories for aws, fly, porter, local and deploy. Someone has to own Postgres, a sandbox substrate, secrets (CORE_SIGNING_SECRET, CAPABILITY_SECRET, PORTAL_IDENTITY_SECRET, CONNECTOR_SECRET_KEY, SKILL_SIGNING_SECRET) and the org's posture choices. A team that wants a hosted agent with a signup page is not the audience, and the README's own escape hatch for that case is the third-party hosted version rather than a self-hosted install.

A second boundary is the local-development credential path. .env.example notes that CODEX_AUTH_FILE, a Codex CLI auth.json on the machine, is a local-dev fallback only and is not allowed in production; the production path is a keychain credential id that core refreshes centrally and hands to harnesses as ephemeral derived material. That is good design, but it means a self-hosted deployment has to solve credential custody before it can run harnesses at all.

Third, the release history is short. The published releases are v0.1.9, v0.1.10 and v0.1.11, all in September 2026, and package.json still carries version 0.1.0. The README does not document rollback, and no upgrade procedure appears beyond the migration pointer in docs/combined-services.md. Treat this as software you evaluate on a branch, not something to put in front of a whole company on day one. Anyone expecting a stable operations story should wait for the documentation to catch up.

How QM differs from single-user harnesses and from chat-only bots

The closest comparison is a single-user coding harness such as OpenCode, Codex or Claude Code. QM does not replace them; it uses them. Those tools drive QM's agent loop, and the README states that all of them drive the same core so a deployment is not tied to a single vendor. The difference in approach is where state and identity live. In a local harness, the agent runs as you, on your machine, with your shell and your home directory. In QM, the same class of loop runs inside a scope-owned sandbox, and the identity, memory, keychain view, permissions and crons belong to a scope that may be a person or a room. That is what makes collaboration with the agent possible without handing everyone the same filesystem.

The other comparison is a chat-only assistant bot bolted onto Slack. A bot of that kind typically has one memory and one credential set for the whole workspace, so a question in a public channel and a question in a DM resolve against the same context. QM separates them by default through Isolated sharing, and when Open is enabled the widening is bounded by explicit opt-ins, a 25-context limit, a 100-session candidate window and a 200-file discovery cap. Whether those numbers fit your organization is a policy question, but they are at least stated.

Licence, upgrade cost and what to check before adopting

QM is MIT-licensed, stated both in the repository metadata and in the license field of package.json. That is permissive and places few obligations on a company that deploys it internally or modifies it. It is not legal advice, and it is worth noting that the licence covers the code in this repository, not the third-party harnesses, models or hosted services a deployment connects to; those carry their own terms, and the .env.example references Anthropic, OpenAI and OpenRouter API keys as options.

The upgrade cost is the part the README understates. Releases are frequent and close together, and the persistence layer is Postgres with a documented migration pointer in docs/combined-services.md, but the README does not describe a supported upgrade sequence or a rollback. In practice that means pinning to a release, reading the diff, and taking a database backup before applying migrations. The qm CLI validates a deployment directory, so schema and config drift between a deployment repository and the core is at least checkable rather than silent.

What to verify first is narrow and concrete. Confirm that DATABASE_URL and SESSION_STORE=postgres are set, because the README says sessions otherwise vanish on restart. Confirm that npm run dev-instance completes against a real model and real Postgres before you touch a production environment. Read SECURITY.md for the threat model, operator assumptions and known limitations, since the README defers to it rather than restating it. Finally, decide your postures deliberately: Auto with model screening off by default is the shipped default, and Open sharing loads opted-in memories into the prompt in full without relevance ranking.

Editorial conclusion

Adopt QM if you are a small company that wants one agent identity per person and per channel rather than a single shared assistant, and you have someone who can own a deployment repository, Postgres and a sandbox substrate. Do not adopt it if you want a hosted product you can sign up for, if nobody on the team wants to read SECURITY.md and deployment.md, or if you need a documented rollback path before you start. Before committing, verify three things in your own deployment: that DATABASE_URL and SESSION_STORE=postgres are set so sessions survive a restart, that npm run dev-instance brings up core, Slack, web, admin and portal against a real model and real Postgres, and that your chosen harness credential path (a keychain credential id rather than CODEX_AUTH_FILE) is one your org can actually operate.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. yc-software/qm on GitHub