qm – A Multiplayer Agent Harness for Work

qm is a multiplayer AI agent harness designed not as a personal assistant but to support the work of an entire startup organization. It uses the same agent identity and configuration on Slack and the web, providing independent workspaces for each user, channel, and project.

Each scope is assigned its own memory, files, keychain access scope, permissions, cron, web apps, and persistent sandbox. Users can use the agent personally while also collaborating in Slack channels, group messages, and projects.

Key features include the following.

• Slack–web integration: uses the same identity and configuration on both
• Admin controls: manage organization settings, security policies, and available harnesses and models
• Web app creation: build internal apps and publish them to target users
• Shared skills: share skills at the scope level, with organization-wide deployment after admin approval
• Background tasks: run tasks via cron and watch without the user needing to supervise them
• Work automation: internal documents, email, database and web search, repository testing and PR/CI monitoring, inbox triage and reply drafting, and more

The core stores persistent state such as sessions, memory, and queues in Postgres, and connects the agent loop with each scope's isolated sandbox. The sandbox serves as a persistent working computer that includes tools and logged-in services.

The agent loop supports multiple harnesses including Pi, OpenCode, Codex, and Claude Code, designed so that deployment isn't locked to a specific model or vendor. Each harness, session store, sandbox, and memory is abstracted behind an interface and can be swapped out via wiring configuration in the deployment directory.

The core runs in TypeScript on Node, using Fastify for the HTTP server, Bolt for Slack integration, and Vite and Lit for the web UI. The web UI, admin panel, and public portal are provided as optional plugins on top of the core HTTP API, while Slack operates as a plugin managed directly by the core.

Security policy is set at the organization level, and child scopes can only be made stricter.

• Strict: requires human approval for all harness tool calls except no-op turn-ending tools
• Auto: the default mode, where a classifier inspects external data and tool results marked with provenance before passing them to the model

The agent performs tasks using each user's own credentials and permissions, and all activity remains subject to audit.