Quartermaster (QM): YC's Open-Source Multiplayer Agent Harness

YC open-sourced QM (Quartermaster) in July 2026. Its launch note describes starting with a Ruby agent loop that could reach internal data, adding crons and webhooks, and later giving individual employees more than 50 Hermes personal agents. Those agents were flexible, but managing the fleet became difficult.

QM is the result of that experience. It aims to retain the flexibility of a personal agent while giving an organization a way to manage models, permissions, and the runtime. Slack direct messages, channels, group DMs, and projects resolve to different scopes; collaboration happens inside those scopes rather than by handing one person's environment to the entire company.

The management problem YC ran into

The first Ruby loop was easy for employees to use, but it could do only so much. Adding crons and webhooks let agents continue working when nobody was there. As personal agents multiplied, the management work shifted to their permissions, configuration, and runtime.

YC wanted Hermes-level flexibility and the simplicity of its original system. The launch note also says it wanted to own and host the system itself. QM is built for startups around that choice: it gives people and projects their own workspaces, then supplies shared rules for collaboration and organizational control.

How scopes organize personal and shared work

QM represents work boundaries as scopes. Personal, channel, team, organization, and group work each have a scope; projects use a group-style scope. Slack DMs resolve to personal scopes, ordinary channels to channel scopes, and multi-person DMs to group scopes. A project can also be linked to a Slack home channel: channel members become project members, and the channel becomes the default delivery audience for scheduled work and reports.

Scope determines who can enter an environment, which file layers are visible, how credentials are granted, and which durable sandbox receives a command. A personal scope does not bring another employee's files or credentials into a run by default; channel and group scopes provide a shared collaboration boundary for their members. Organization, current-scope, and personal-scope layers can all take part in resolution, with different read/write boundaries.

A skill belongs to one scope and moves to another only through a grant; promotion to the whole organization is an administrator decision. Personal experience, channel collaboration, project work, and organization-wide assets therefore have different owners and routes for reuse.

The organization keeps a distinct responsibility as well. It controls which harnesses and models are available, chooses a security posture, and manages skills that are visible across the organization. Administrators do not have to treat personal credentials and private context as public resources; files, skills, and access relationships intended for sharing must be explicitly granted between the relevant scopes.

A generic core and organization-specific work

The runtime follows those boundaries. QM's headless core handles the API, identity, policy, scheduler, and agent loop; Postgres stores durable state. Commands enter the sandbox for the relevant scope through execute. Tools installed there persist, making that sandbox the scope's long-lived working environment.

QM separates its generic core from organization-specific work. Org configuration, custom tools and skills, sandbox images, and infrastructure live in a deployment directory that qm init deploys to the operator's cloud account. The README also describes a private-fork workflow: an organization keeps private material in deploy/layers/ while keeping core identical to upstream; update-qm merges upstream and opens a sync PR, while upstream-pr sends organization-neutral fixes back to QM. This lets a team maintain its own agent environment without giving up the upstream project.

The web UI, admin panel, and portal are plugins over the core HTTP API; core starts and supervises Slack directly. For users, identity and configuration carry between Slack and the web. For operators, identity, policy, and auditing remain in one control point.

Limits stated in the documentation

QM remains early, experimental software, not a hardened public or multi-tenant service boundary. Its command policy can stop some dangerous commands, but obfuscation, encoding, or write-then-execute patterns can still evade it. Credentials in active use inside a sandbox are plaintext, and content screening is incomplete. Admin reads of sensitive content are audited, but do not require a separate consent step.

That defines where QM fits. It offers a way to manage personal agents and shared work; it does not replace a deployment's own security and operations review. Browser-runner actions also do not re-enter command policy or human approval, so operators need to assess that path separately.

Sources

• YC's QM launch note
• QM README at 1a6b0e4
• Scope types and resolution at 1a6b0e4 and scope membership
• SECURITY.md at 1a6b0e4