qm

Purpose

QM is a multiplayer agent harness for work, usable in both Slack and Web interfaces. It is designed for startups: most agents are built as personal assistants and struggle to serve an entire company; QM instead gives every employee a fully isolated agent workspace of their own, while supporting collaboration in channels, group messages, and projects.

Main capabilities

• Personal and shared scopes: Every person and every room (channel/project) has its own scoped memory, files, keychain view, permissions, scheduled tasks, web apps, and persistent sandbox. Employees can personalize their own agents while collaborating in Slack channels and projects.
• Unified identity across Slack and Web: The same identity and configuration remain consistent between Slack and the Web app.
• Admin controls: Set organization-level configuration, security and sharing posture, and choose available harnesses and models.
• Web apps: Create custom internal apps and publish them to the right people.
• Shared skills: Skills are owned by scope, can be shared through authorization, can be promoted to the entire organization after admin approval, and support importing skill packages from git repositories.
• Background work: Scheduled tasks (crons), watches, and inbound webhooks keep working even when you are away.
• Examples of executable tasks: Federated search across internal notes, email, documents, databases, and the web; build and publish internal apps; learn your writing style and triage your inbox on a schedule (with labels and reply drafts); work in existing repositories (run tests, submit PRs, monitor CI, inspect system logs); track projects in shared channels and post updates and follow-ups.

How to use

Deployment process: Create an organization-owned deployment repository that depends on @yc-software/qm . Initialization generates a deployment skill for an agent and guides you step by step through infrastructure, Web login, connector credentials, optional Slack access, deployment, and live verification, without checking out source code. Each deployment runs in the operator's own cloud account; initialization does not generate or enable deployment CI, and the repository has no production deployment workflow.

Quick start commands:

• Tell your coding agent: "Let's deploy https://github.com/yc-software/qm”，它会遵循仓库中的部署指南。
• You can also try a third-party hosted version.

Development and running:

• After checking out from source, install dependencies with npm ci and use the in-repo CLI.
• For persistence, set DATABASE_URL and SESSION_STORE=postgres.
• For testing against real models and a real Postgres branch: run npm run dev-instance:webfor Web/admin, run npm run dev-instance:slackfor Slack, and run npm run dev-instance:bothto test both together.
• With no arguments, npm run dev-instance defaults to web for new instances and preserves the current interface on reload.
• When modifying the CLI itself, use the CLI from that checkout and explicitly specify --build-from; otherwise the normal deployment path will select the published image.

Architecture: Every conversation turn goes through a central core, which can use multiple models and harnesses to generate responses. The Postgres persistence layer stores user data, conversation history, and other persistent state. Agents have a fixed, small tool surface; one of those tools is execute, run commands in the scope's own isolated sandbox (a persistent computer where installed tools remain present). The Web UI and admin panel share one service; the portal and the optional built-in authentication proxy share another service. These modules communicate with it through the core HTTP API. Slack is an optional in-process plugin, started and supervised by the core through a direct service client.

Applicable scenarios

• Providing each employee with an isolated agent workspace within a startup or organization
• Multi-person collaborative agent use in Slack channels and projects
• Organizations that need administrators to uniformly control models, runtimes, security, and sharing settings
• Teams that want to self-host in their own cloud account, using their own models and keys

Security and key model

QM's approach is consistent with local coding agents such as OpenCode, Codex, and Claude Code: the agent acts as the person it serves, using their credentials and permissions, and all operations are audited. The organization chooses a security posture, and narrower scopes can only tighten it:

• Strict: every runtime tool call pauses for human approval, except for two side-effect-free turn enders.
• Auto (default): blocks private network access.
• Dangerous: no tool approval gate, and content screening only observes.

Content screening is a deployment setting,securityScreen.mode optional off(default),observe or enforce，securityScreen.classifier choose a built-in model or an external proxy. When enabled, it classifies external content under every posture.observe only records the verdict in the audit log;enforce quarantines flagged content and waits for release approval, and under Dangerous the screening ceiling is observe.

Pre-declared command policies (approval rules and hard denials, such as recursive deletion or destructive SQL) apply under all postures, including Dangerous.

Sharing postures are independent:

• Isolated (default): resources remain within their scope unless explicitly shared.
• Open: during live authenticated internal human turns, the speaker's opted-in personal files, artifacts, skills, and memories can be read in opted-in shared rooms.

SECURITY.md contains the threat model, operator assumptions, and known limitations.

Limitations

• When DATABASE_URL and SESSION_STORE=postgres are not set, sessions exist only in process memory and are lost on restart.
• Initialization does not generate or enable deployment CI; this repository has no production deployment workflow.
• After modifying source code, if --build-fromis not used, the normal deployment path will still select the published image, and editing source code will not change the deployed runtime.
• Using git push --mirror as a seed copies unrelated upstream branches and tags, implicitly preserves the default branch selection, and may delete target-unique references on subsequent pushes, so it is not recommended.
• A GitHub Fork of a public repository cannot be made private; private work should be placed outside that network.
• Contributions are submitted as human-written text, not code.

Customization

• Configuration, tools, skills, and services: use the deployment repository above, which pins the @yc-software/qm version and uses that version's runtime image, without copying source code.
• Modifying QM itself: keep your own source branch (public or private), and you can modify any part of the core, including the runtime, plugins, CLI, documentation, and CI. Contributing changes back upstream is optional.

Creating a private source branch: create an independent private repository, outside GitHub's fork network, seed only main and explicitly set it as the default branch. Do not use git push --mirror Seeding. Upstream remotely provides source updates without copying those references into your repository.

In the source branch, keep deployment configuration, tools, skills, plugin images, and infrastructure in a private deploy/layers/<org>/ , or in a separate private deployment repository when the source is public. Never commit secrets. See deploy/layers/README.md for initialization and layout.

Stay updated: the source branch uses update-qm to merge upstream changes while preserving intentional local behavior. Keep the merge lineage intact when merging sync PRs; never squash or rebase. Conflicts are expected maintenance work, not a reason to discard customizations. Use upstream-pronly when you want to contribute general changes.

Package deployment: upgrade the exact @yc-software/qm dependencies and lockfiles, review contract changes and generated assets, then verify and deploy. There is no upstream source history to merge.

Documentation and Licensing

• docs/getting-started.md: first run, end to end
• cli/README.md: qm CLI and deployment directory contract
• docs/deploy-directory.md: the complete deployment directory
• docs/principal-links.md: one person, multiple logins: linked principals
• docs/porter.md: running qm on Porter
• docs/superserve.md: using Superserve as an agent sandbox
• .env.example: every configuration item, documented in place
• docs/swarms.md: persistent agent pools, scoped messages, and blank Modal workers
• docs/model-gateway.md: discovering and routing models through the gateway
• plugins/: the various interfaces (Slack, Web UI, admin, portal)

Unless otherwise stated, QM is licensed under MIT.