qm

QM is a self-hosted platform for running AI agents across an entire organization instead of one person at a time. Most agent products are built like personal assistants — wiring one up for a whole company quickly turns into a tangle of shared state and stepped-on context. QM instead gives every person and every room (channel, group, or project) its own isolated scope: its own memory, files, credential keychain view, permissions, scheduled crons, web apps, and durable sandbox computer. People customize the agent to be theirs while still collaborating with it — and each other — in Slack channels, group messages, and shared projects.

The project is deliberately harness-agnostic: Pi, OpenCode, Codex, and Claude Code all drive the same core, so a deployment isn’t locked to one vendor’s coding agent or model. A headless TypeScript core built on Fastify handles identity, policy, and scheduling, backed by Postgres for durable session, memory, and queue state; the agent loop hands off to whichever harness a deployment configures, and every harness reaches its own per-scope sandbox for file access, tool execution, and logged-in services. Slack support ships as an in-process plugin (via Bolt) that the core starts and supervises, and the web UI and admin panel are built with Vite and Lit.

Security is modeled explicitly rather than bolted on. Every organization picks one security posture — Strict (every tool call pauses for human approval), Auto (blocks private-network access, optional content screening), or Dangerous (no pauses, no screening) — and a separate sharing posture that controls whether resources from one scope can be read in another. A predeclared command policy enforces hard denials (recursive deletes, destructive SQL) in every posture, including Dangerous. Background work — crons, watches, and inbound webhooks — runs independently of any open conversation, and admins get org-level control over which harnesses, models, and security settings are available to their teams.

QM ships as an npm package (@yc-software/qm) that organizations deploy into their own cloud account via a generated deployment repository and the bundled qm CLI, rather than as a hosted SaaS product — though a third-party hosted version exists for teams that don’t want to run their own infrastructure. Everything specific to one company — configuration, custom tools and skills, sandbox image, infrastructure choices — lives in that deployment repository, keeping the open-source core generic and upgradable.

What You Get

• Personal and shared scopes — every person and every room (channel, group message, or project) has its own isolated memory, files, keychain view, permissions, crons, web apps, and durable sandbox computer.
• Pluggable harness core — Pi, OpenCode, Codex, and Claude Code all drive the same headless core, so a deployment isn’t tied to a single agent vendor or model.
• Slack and web from one identity — the same configuration and identity carries between Slack channels/DMs and the standalone web app and admin panel.
• Explicit security and sharing postures — org-wide Strict/Auto/Dangerous approval postures and Isolated/Open sharing postures, enforced by a predeclared command policy with hard denials that apply in every posture.
• Background automation — crons, watches, and inbound webhooks let the agent do scheduled or triggered work without an open conversation.
• Agent swarms — a session can spawn a pool of worker sessions with their own durable transcripts, identity, and context, coordinated through a documented Agent API.
• Web apps and shared skills — deployments can spin up custom internal web apps and publish them to the right people, and skills are scope-owned, shareable by grant, with org-wide promotion and git-based skill packs.
• Durable by design — sessions, memory, queues, and audit data live in Postgres rather than in-process memory, so the system survives blue-green, multi-instance deploys.

Common Use Cases

• Cross-tool search — search internal notes, email, documents, databases, and the web together from a single agent turn.
• Internal app building — build small internal apps, publish them to the right people, and keep their underlying data current.
• Inbox triage — learn a person’s writing voice from past sends, then triage their inbox on a schedule with labels and reply drafts.
• Engineering workflows — work inside an existing repository: run tests, open pull requests, monitor CI, and check system logs.
• Shared project tracking — track a project in a shared Slack channel and post status updates and follow-ups automatically.

Under The Hood

Architecture QM runs a headless TypeScript core (src/) on Node with Fastify for HTTP, organized around a small set of cross-cutting modules — src/core/orchestrator.ts drives each turn through policy evaluation (src/policy/command-policy.ts), scope resolution, credential handling, and delivery, while src/harness/harness-router.ts dispatches to one of several interchangeable harness adapters (claude-harness.ts, codex-harness.ts, opencode-harness.ts, pi-harness.ts) and src/sandbox/ abstracts over a dozen sandbox backends (AWS microVMs, E2B, Modal, Porter, Docker, local). Everything company-specific — org config, custom tools/skills, sandbox image, infrastructure — is pushed out into a separate deployment repository validated and deployed by the in-tree qm CLI, and the core itself stays generic. Slack is not a separate service but an in-process plugin the core starts and supervises through a direct service client, while the web UI, admin panel, and portal are independent packages under plugins/ that talk to core only over its signed HTTP API via a shared plugins/chassis package — plugins deliberately keep local copies of anything they need from core rather than importing it directly. State that the system must read back later — sessions, memory, run/cron queues, audit logs — is required to live in Postgres rather than in-process memory, a rule enforced by convention (documented explicitly in the repo’s own contributor guide) because the core runs blue-green and multi-instance, where in-memory state is silently wiped on every deploy.

Tech Stack The project is a TypeScript/Node monorepo (Node >=24, npm workspaces-style layout with separate package.json files for cli/, each plugins/* package, and deploy/connector-sdk/) using Fastify for the core HTTP API, Zod and TypeBox for schema validation, pg/pg-boss for Postgres persistence and job queuing, and Vite plus Lit for the web UI and admin panel. Slack integration uses @slack/bolt, @slack/web-api, and @slack/socket-mode. Multiple sandbox providers are wired in as first-class options — AWS ECS/microVMs, E2B, Modal, Porter, and a local Docker-based sandbox — alongside deployment targets for Fly.io and AWS via dedicated fly/ and aws/ directories. The coding-agent harnesses themselves are pulled in as direct dependencies: @anthropic-ai/claude-agent-sdk, @openai/codex, @opencode-ai/sdk, and a custom-built @earendil-works/pi-coding-agent package.

Code Quality The repository ships with an unusually large test suite for its size — over 600 test files under test/, run with Node’s native --test runner (no third-party test framework), including a dedicated Postgres-backed suite (test:pg) that exercises leases, migrations, queues, and audit stores against a real database, plus a live-Slack end-to-end suite. CI (cicd.yml) runs a dedicated typecheck job and shards the test suite five ways with a shard-plan verification step before execution. Linting runs through ESLint (eslint.config.mjs) and additionally oxlint --deny-warnings, with knip configured to catch unused exports and dependencies, Husky pre-commit hooks via lint-staged, and strict TypeScript (typecheck, plus a separate typecheck:contract pass). The project’s own contributor guide enforces an unusual, strictly-worded convention: zero comments anywhere in the codebase, including TODOs and commented-out code, with intent expressed only through naming, structure, and tests — a discipline that shows in the sampled source files.

What Makes It Unique Most self-hosted agent projects assume a single user and a single conversation. QM’s core design bet is the opposite: it treats “one org, many scoped agents” as the primary problem, giving every person and every room independent memory, sandboxes, and permissions by default, with a deliberately narrow, audited mechanism (the Open sharing posture) for crossing those boundaries only on a live, authenticated human turn. Layered on top of that is a harness-neutral core that lets an organization switch between Pi, OpenCode, Codex, and Claude Code without re-platforming, plus an explicit, three-level security posture model (Strict/Auto/Dangerous) with hard-denial command policy that applies even in the most permissive mode. Agent swarms — spawning pools of worker sessions with their own durable identity and transcripts, coordinated through a documented self-service API — extend the same scoping model to multi-agent collaboration rather than treating it as a bolted-on feature.

Self-Hosting

Licensing Model MIT licensed — the full core, CLI, plugins, and runtime are available with no license keys, feature gates, or paid tiers in the source repository itself.

Self-Hosting Restrictions None found. There are no ee/, enterprise/, or pro/ directories, and no license-check or feature-flag gating in the source — every capability in the codebase (swarms, background work, admin console, memory providers, web apps) is available to a self-hosted deployment.

Cloud vs Self-Hosted QM is not offered as a first-party hosted SaaS. The project instead points to a third-party hosted version (agent37.com) run by an independent infra provider; the README explicitly invites other infra providers to offer their own hosted version. Every deployment — whether self-run or third-party-hosted — runs the same open-source core.

License Key Required No. No part of the pipeline requires a license key or account with the project maintainers to run.