QM (multiplayer agent harness) is an open-source framework designed to deploy intelligent agents within startup environments by transitioning from a "personal assistant" model to a collaborative, multi-tenant workspace architecture. It provides isolated, scoped environments for individual employees while enabling shared access to organizational tools, memory, and communication channels (Slack and web).

Core Methodology and Architecture

The system employs a "Headless Core" architecture built on Node.js and Fastify, designed to be model-agnostic. It separates the agent’s logic from the specific AI harness (e.g., Pi, OpenCode, Claude Code) through a modular interface system. The technical stack is structured as follows:

1. Persistence and State: A central Postgres layer manages session history, user memory, and queueing. This allows the agent to maintain durable state across different interactions.
2. Sandbox Isolation: Each scope (user or project) operates within its own durable sandbox. The core uses an execute tool to run commands within these environments, ensuring that tools installed by a user remain available and isolated from other scopes.
3. Core Control Loop:
   • API: Manages identity, policy enforcement, and task scheduling.
   • LOOP: Executes the agentic reasoning process by interfacing with selected LLM harnesses.
   • SBX: Represents the isolated compute environment.
   • Relationship: $\text{DB} \leftrightarrow \text{API} \leftrightarrow \text{LOOP} \leftrightarrow \text{SBX}$
4. Plugin System: Interfaces like Slack (via Bolt) and the Web UI (via Vite/Lit) are treated as optional, in-process plugins that interact with the core via a unified HTTP API.

Security and Governance

QM operates on the principle that the agent acts as the user, inheriting their credentials and permissions. To manage this, it enforces an organization-wide security posture:

• Strict: Requires human approval for every tool call (excluding end-of-turn operations).
• Auto (Default): Utilizes a classifier to screen provenance-labeled external data and tool outputs before they reach the model.
• Dangerous: Disables content screening and inter-tool pauses.

Regardless of the posture, a predeclared command policy is applied, which programmatically prevents destructive actions (e.g., recursive deletions or unauthorized SQL execution).

Deployment and Customization

The framework supports two deployment strategies:

1. Standard Deployment: Users initialize a deployment-specific repository using the qm CLI, which generates infrastructure code and config files targeting cloud environments like AWS or Fly.io.
2. Private Forking: For organizations requiring deep customization, QM supports a "clone-based" private fork. This method involves creating a standalone repository that tracks the upstream qm core. By maintaining a strict boundary—where organizational logic resides exclusively in $deploy/layers/<org>/$—the system ensures that updates from the upstream core remain simple to merge while keeping proprietary tools and infrastructure configurations private.

The system utilizes specialized internal skills, such as update-qm and upstream-pr, to facilitate bidirectional synchronization between the private implementation and the upstream repository while preventing the leakage of organization-specific identifiers.