qm

A multiplayer agent harness for teams. In Slack and on the web. Run it in your own cloud, with your own models and keys.

Deploy · How it works · Security model · Customize · Contribute · Documentation

Overview

Most agents are designed like personal assistants. You can make one work for a whole team, but it quickly gets complex. QM is designed for teams. Everyone gets their own isolated workspace, and can also collaborate with the agent in channels, group messages, and projects.

Each person and each room has its own scoped memory, files, keychain view, permissions, crons, web apps, and durable sandbox.

Agents are always on. Each one has its own computer and memory, and keeps working on schedules and webhooks while you're away. Hosted always-on agents like ChatGPT Dots and Grok Bot run in the vendor's cloud on the vendor's models. QM runs in yours.

It's built with open source in mind. Pick your own model and switch between models; Pi runs models from many providers, so a deployment isn't tied to any single vendor.

Setup

Tell your coding agent of choice Let's deploy https://github.com/yc-software/qm. From here, it should follow the deployment guide in this repo.

An easy way to run QM yourself is with DigitalOcean, E2B, or Render.

If you'd rather a fully hosted option, you can try Agent 37.

If you're an infra provider interested in offering a hosted version of QM, feel free to reach out.

If you're at a bigger company and are interested in a hosted version of QM, let us know here.

Features

• Personal and shared scopes. People customize the agent to be theirs, and still work with it collaboratively in Slack channels and projects.
• Slack and web. The same identity and configuration carries between Slack and the web app.
• Admin control. Set org-level configuration, security and sharing postures. Choose which models are available.
• Web apps. Spin up custom internal apps and publish them to the right people.
• Shared skills. Skills are scope-owned and shareable by grant, with admin-gated promotion to the whole org and skill packs imported from git repositories.
• Background work. Crons, watches, and inbound webhooks work while you're away.

What you can do with it

• Search internal notes, email, documents, databases, and the web together
• Build internal apps, publish them to the right people, and keep their data current
• Learn your writing voice from past sends, then triage your inbox on a schedule — labels and reply drafts included
• Work in an existing repository: run tests, open PRs, monitor CI, check system logs
• Track a project in a shared channel and post updates and follow-ups

Architecture

flowchart LR
  DB[("Postgres<br/>sessions · memory · queue")]

  subgraph CORE["Headless core"]
    API["API · identity · policy · scheduler"]
    LOOP["Agent loop<br/>(Pi)"]
    API <--> LOOP
  end

  SBX["Per-scope sandbox<br/>files · tools · logged-in services"]

  DB <--> API
  LOOP <--> SBX

Core requires Postgres: set DATABASE_URL. Tests need one too: DATABASE_URL=<disposable Postgres> npm test creates a throwaway database per test file and per test app. To exercise a branch against a real model and real Postgres, run npm run dev-instance:web for the web UI and settings or npm run dev-instance:slack for Slack. Use npm run dev-instance:both when testing both surfaces together. Bare npm run dev-instance defaults to web for new instances and preserves the surface on reload. Switch an existing instance with an explicit surface command.

How it works

Every turn runs through a central core, which can use a variety of models to generate the response. A Postgres persistence layer holds user data, session history, and other durable state. The agent has a small, fixed tool surface; one of those tools is execute, which runs commands in the scope's own isolated sandbox — its durable computer, where installed tools stay installed. Core also serves the public front door: sign-in, the optional built-in auth broker, and the web UI, whose browser bundle ships as a static release that qm ui publish can update without restarting core. These modules communicate with core over its HTTP API. See the core-hosted front door for configuration and migration; Slack is an optional in-process plugin that core starts and supervises through a direct service client.

The core runs TypeScript directly on Node and uses Fastify for HTTP. The Slack plugin uses Bolt; the web UI builds with Vite and renders with Lit.

The core itself is generic. Everything specific to one team — org config, custom tools and skills, sandbox image, infrastructure — lives in a deployment directory that the qm CLI validates and deploys. Every substrate (session store, sandbox, memory) sits behind an interface. Memory can also be routed by scope to external providers while retaining the built-in notebook.

This is the beginning of the README. Read the rest at the original. Read the full README ↗