Y Combinator has open-sourced QM, a company-oriented AI agent harness designed to run persistent, scoped agents across Slack and a web interface—and its most important feature is not a new model, but the operational boundary around one. The code is publicly available under the MIT License, giving IT teams a chance to inspect, modify, self-host, and commercially deploy the system rather than accept an opaque hosted-agent platform on trust.
Startup Fortune first highlighted the release, while Y Combinator’s own QM project page confirms that the accelerator built the software after operating internal fleets of agents. YC describes QM as a system for giving employees and projects their own OpenClaw-like agents as needed. The underlying repository characterizes it more plainly: a “multiplayer agent harness for work.”
That wording matters. QM is not trying to replace Claude Code, Codex, OpenCode, or Pi with a new assistant. It is an attempt to provide the organizational runtime around those tools: identity, policy, session state, credentials, scheduling, shared workspaces, sandboxing, auditing, and delivery through collaboration surfaces that employees already use.
A personal coding assistant can live on a developer’s desktop and inherit that developer’s context. A company-wide agent system faces a much less forgiving problem: who can see what, who can authorize what, and where does an action actually run?
QM’s answer is to treat every person and every collaboration space as a separate scope. According to the project README, each scope receives its own memory, files, keychain view, permissions, cron jobs, internal web apps, and durable sandbox. An employee’s agent, a Slack channel’s agent, and a project’s agent may all exist in the same deployment without being one shared bucket of prompts and credentials.
For Windows administrators and developers, that structure should sound more familiar than the surrounding AI vocabulary. It resembles the distinction between a user profile, a team share, a service account, and a workload sandbox. The hard part is not making a model generate text. The hard part is ensuring that a useful automation system does not turn a finance Slack channel, an engineering repository, and a marketing mailbox into one sprawling, over-privileged source of context.
YC says it initially used a basic Ruby agent loop with access to internal data, then expanded it with cron jobs and webhook triggers. It later provisioned more than 50 Hermes agents as personal assistants for employees. The company says managing a fleet even at that scale became difficult, helping drive the design of QM.
The project’s name is shorthand for “quartermaster,” the person responsible for keeping a ship supplied and organized below decks. It is an apt framing. QM is not primarily the intelligence layer; it is the administrative machinery that determines where that intelligence gets data, what it can invoke, and what durable artifacts it leaves behind.
That is more consequential than it first appears. Enterprise AI projects often begin as a simple integration, then become dependent on one vendor’s tool semantics, identity approach, memory format, pricing model, or API behavior. Replacing a model later is not just an inference-quality decision if the model layer has become entangled with how internal work is stored and executed.
QM separates the central control plane from the execution layer. The core manages its API, identity, policy, and scheduler. Postgres stores sessions, memory, queue data, and other persistent state. The actual agent loop interacts with a per-scope sandbox, where commands can run and installed tools remain available over time.
The implementation is conventional enough to make the project more interesting, not less. QM runs TypeScript on Node.js, uses Fastify for HTTP, uses Postgres for durable data, and offers Slack as an optional plugin. The web interface is also optional rather than inseparable from the system’s core.
That means a capable Windows-focused IT team can evaluate QM as software infrastructure rather than as a prescribed SaaS experience. The deployment flow targets an organization-owned AWS or Fly.io environment, and the repository emphasizes that production runs in the operator’s own cloud account. There is no implication that this is a Windows-native desktop product, but the distinction is still relevant to organizations built around Microsoft 365, Teams, Active Directory or Entra ID, and Windows endpoint management: QM offers an inspectable integration layer, but it does not eliminate the work of adapting identity, data connectors, and approval flows to an existing environment.
But those examples can obscure the real change. The Slack bot is simply one surface through which a scoped agent can be reached. The same configuration and identity can carry into the web application. Crons and watches can run background work when nobody is actively chatting with the agent.
That turns the software from a reactive assistant into an automation platform. A periodic job could inspect a build pipeline, identify a failing test, gather relevant logs, and prepare a report for a channel. A project agent could monitor follow-up items and surface stale issues. An internal operations agent could generate a lightweight tool for a limited group of employees.
Each of those is useful precisely because it is not just a chat response. It creates a persistent system with data retention, authentication, side effects, and a growing body of internal context. That is also why it demands more caution than a prompt box attached to a public model API.
For organizations already running Microsoft-centric collaboration, QM’s Slack-first design is a practical limitation rather than a minor cosmetic detail. The project does provide web access and a generic core, but it does not currently present itself as a drop-in Microsoft Teams, SharePoint, or Power Platform equivalent. Teams considering it should view the source code as a foundation for an integration project, not assume that open source translates to turnkey compatibility.
That is appropriate language for a system that can execute model-generated commands in durable sandboxes holding usable credentials. QM says the agent acts with the credentials and permissions of the person it is serving, while actions are audited. In practice, that provides familiar attribution but also means the agent’s possible blast radius can closely resemble that of its human operator.
The project defines three security postures:
Other known limitations are equally concrete. The security document says sandbox credentials can be readable by processes in a sandbox while in use; not all external input paths are covered by screening; data such as memory, sessions, model request captures, and file artifacts can persist longer than users expect; and administrators can read sensitive scoped content, with auditing but without additional user approval.
That does not make QM uniquely unsafe. It makes its risks legible. Many closed agent platforms offer a friendlier administrative dashboard while leaving customers to infer the underlying trust model. QM gives defenders and platform engineers the chance to examine it directly—and the obligation to do so before connecting it to production systems.
For smaller teams, the temptation will be to jump directly to broad permissions because that is where agents appear most impressive. QM’s own documentation argues against that shortcut. Start with a narrow scope, limited connectors, non-destructive actions, and strict approvals; then observe actual behavior before extending autonomy to inboxes, repositories, financial systems, or customer data.
Y Combinator has supplied a real artifact rather than a polished claim about autonomous work. The next milestone is not whether QM can produce a compelling Slack demonstration. It is whether early adopters can deploy it with boundaries strong enough that a fleet of agents becomes manageable infrastructure rather than a fleet of privileged, persistent exceptions.
That wording matters. QM is not trying to replace Claude Code, Codex, OpenCode, or Pi with a new assistant. It is an attempt to provide the organizational runtime around those tools: identity, policy, session state, credentials, scheduling, shared workspaces, sandboxing, auditing, and delivery through collaboration surfaces that employees already use.
The agent problem shifts from prompting to containment
A personal coding assistant can live on a developer’s desktop and inherit that developer’s context. A company-wide agent system faces a much less forgiving problem: who can see what, who can authorize what, and where does an action actually run?QM’s answer is to treat every person and every collaboration space as a separate scope. According to the project README, each scope receives its own memory, files, keychain view, permissions, cron jobs, internal web apps, and durable sandbox. An employee’s agent, a Slack channel’s agent, and a project’s agent may all exist in the same deployment without being one shared bucket of prompts and credentials.
For Windows administrators and developers, that structure should sound more familiar than the surrounding AI vocabulary. It resembles the distinction between a user profile, a team share, a service account, and a workload sandbox. The hard part is not making a model generate text. The hard part is ensuring that a useful automation system does not turn a finance Slack channel, an engineering repository, and a marketing mailbox into one sprawling, over-privileged source of context.
YC says it initially used a basic Ruby agent loop with access to internal data, then expanded it with cron jobs and webhook triggers. It later provisioned more than 50 Hermes agents as personal assistants for employees. The company says managing a fleet even at that scale became difficult, helping drive the design of QM.
The project’s name is shorthand for “quartermaster,” the person responsible for keeping a ship supplied and organized below decks. It is an apt framing. QM is not primarily the intelligence layer; it is the administrative machinery that determines where that intelligence gets data, what it can invoke, and what durable artifacts it leaves behind.
A runtime designed to outlast today’s model choice
QM makes a deliberate architectural bet: the organization should not be permanently coupled to a particular model provider or coding-agent interface. Its core can work with Pi, OpenCode, Codex, and Claude Code, while the repository says the major substrates—harness, session store, sandbox, and memory implementation—sit behind replaceable interfaces.That is more consequential than it first appears. Enterprise AI projects often begin as a simple integration, then become dependent on one vendor’s tool semantics, identity approach, memory format, pricing model, or API behavior. Replacing a model later is not just an inference-quality decision if the model layer has become entangled with how internal work is stored and executed.
QM separates the central control plane from the execution layer. The core manages its API, identity, policy, and scheduler. Postgres stores sessions, memory, queue data, and other persistent state. The actual agent loop interacts with a per-scope sandbox, where commands can run and installed tools remain available over time.
The implementation is conventional enough to make the project more interesting, not less. QM runs TypeScript on Node.js, uses Fastify for HTTP, uses Postgres for durable data, and offers Slack as an optional plugin. The web interface is also optional rather than inseparable from the system’s core.
That means a capable Windows-focused IT team can evaluate QM as software infrastructure rather than as a prescribed SaaS experience. The deployment flow targets an organization-owned AWS or Fly.io environment, and the repository emphasizes that production runs in the operator’s own cloud account. There is no implication that this is a Windows-native desktop product, but the distinction is still relevant to organizations built around Microsoft 365, Teams, Active Directory or Entra ID, and Windows endpoint management: QM offers an inspectable integration layer, but it does not eliminate the work of adapting identity, data connectors, and approval flows to an existing environment.
Slack is only the front door
The initial appeal will be obvious to teams that already organize operational work through Slack. QM can search internal notes, email, documents, databases, and the web; it can triage inboxes, draft replies, monitor CI, inspect system logs, open pull requests, track project work, post updates, and produce internal web apps.But those examples can obscure the real change. The Slack bot is simply one surface through which a scoped agent can be reached. The same configuration and identity can carry into the web application. Crons and watches can run background work when nobody is actively chatting with the agent.
That turns the software from a reactive assistant into an automation platform. A periodic job could inspect a build pipeline, identify a failing test, gather relevant logs, and prepare a report for a channel. A project agent could monitor follow-up items and surface stale issues. An internal operations agent could generate a lightweight tool for a limited group of employees.
Each of those is useful precisely because it is not just a chat response. It creates a persistent system with data retention, authentication, side effects, and a growing body of internal context. That is also why it demands more caution than a prompt box attached to a public model API.
For organizations already running Microsoft-centric collaboration, QM’s Slack-first design is a practical limitation rather than a minor cosmetic detail. The project does provide web access and a generic core, but it does not currently present itself as a drop-in Microsoft Teams, SharePoint, or Power Platform equivalent. Teams considering it should view the source code as a foundation for an integration project, not assume that open source translates to turnkey compatibility.
QM’s documentation is candid about security gaps
The most valuable part of the release may be the project’s willingness to state what the controls do not guarantee. QM’s security policy calls the software early and experimental, explicitly warning that its scope-isolation goal is neither a certification nor a promise that data cannot leak.That is appropriate language for a system that can execute model-generated commands in durable sandboxes holding usable credentials. QM says the agent acts with the credentials and permissions of the person it is serving, while actions are audited. In practice, that provides familiar attribution but also means the agent’s possible blast radius can closely resemble that of its human operator.
The project defines three security postures:
- Strict mode pauses every harness tool call for human approval, apart from two no-effect end-of-turn operations.
- Auto mode, the default, screens provenance-labeled external data and supported tool results before they reach the model.
- Dangerous mode removes content screening and pauses between tool calls, although preset rules still block or require approval for certain destructive commands.
Other known limitations are equally concrete. The security document says sandbox credentials can be readable by processes in a sandbox while in use; not all external input paths are covered by screening; data such as memory, sessions, model request captures, and file artifacts can persist longer than users expect; and administrators can read sensitive scoped content, with auditing but without additional user approval.
That does not make QM uniquely unsafe. It makes its risks legible. Many closed agent platforms offer a friendlier administrative dashboard while leaving customers to infer the underlying trust model. QM gives defenders and platform engineers the chance to examine it directly—and the obligation to do so before connecting it to production systems.
The deployment decision is the product decision
YC’s release is best understood as a blueprint for a particular way of operating agents: own the deployment, preserve the control plane, isolate work by scope, and keep the model layer replaceable. The code being MIT-licensed means organizations can fork and adapt it, but production use will still demand cloud infrastructure, connector management, secret handling, logging, incident response, and a well-defined approval policy.For smaller teams, the temptation will be to jump directly to broad permissions because that is where agents appear most impressive. QM’s own documentation argues against that shortcut. Start with a narrow scope, limited connectors, non-destructive actions, and strict approvals; then observe actual behavior before extending autonomy to inboxes, repositories, financial systems, or customer data.
Y Combinator has supplied a real artifact rather than a polished claim about autonomous work. The next milestone is not whether QM can produce a compelling Slack demonstration. It is whether early adopters can deploy it with boundaries strong enough that a fleet of agents becomes manageable infrastructure rather than a fleet of privileged, persistent exceptions.