Personal agents get useful by learning one person. A company agent has a harder job: it has to remember enough for people to work together without treating the whole company as one person with one permission set.
That’s the problem QM is trying to solve. Y Combinator has open-sourced QM after learning what it takes to manage a fleet of agents at work. YC says it provisioned more than 50 Hermes agents as personal assistants for employees, then found managing even that size of fleet challenging. QM is its next attempt: an open-source “multiplayer agent harness for work,” built for Slack and the web.
Picture that agent joining a company. Useful context belongs to different people and places, and sharing everything with everyone would be a serious design failure.
That is the company-agent problem.
A company isn’t one person with a very long chat history#
An agent sits in your company’s Slack. An employee asks it to summarize a customer conversation. A project room asks it to prepare a release checklist. Finance gives it access to one set of credentials, while engineering gives it another. A direct message contains personal context that shouldn’t drift into a team channel. When an employee leaves, their authority needs to leave with them.
A normal chat model can answer those prompts. The harder questions surround the model. Who is asking? Which room owns the work? Who should see the answer? What memory belongs to the individual, the project, or the wider organization? Which tools and credentials are available here, and who can approve their use?
QM makes that shape explicit. Its code recognizes personal, channel, group, team, and organization scopes. Five named scope kinds don’t prove that every resource is independently isolated at every scope. But they do show that QM isn’t modeling a company as one enormous conversation. The code has a vocabulary for asking where work belongs and who belongs there.
A company agent needs shared continuity and boundaries. A project room should remember how its release process works without absorbing every private conversation in the company. People should be able to collaborate through the same agent without becoming one undifferentiated user.
The agent loop isn’t the company#
QM’s architectural choice is to keep the organizational responsibility out of any one agent loop.
QM acts as a durable control plane around familiar harnesses. Its application wiring includes Pi, OpenCode, Codex, and Claude Code as adapters. One of those harnesses can perform the loop for a turn: interpret the request, call tools, work through the task, and produce a result. QM keeps the organizational context around that turn consistent.
In plain language, QM works out who is speaking, which audience and scope apply, and what shared state belongs there. Then it enforces the policies and approvals that govern the request and decides where the work should run. It also provides the surrounding machinery for schedules, audit records, and scope-specific workspaces. Its harness router checks the deployment’s approved harnesses, respects the harness and model configured for the scope, and routes the turn to the matching adapter.
That separation matters more than the harness list. An organization can choose an approved harness and model without leaving its people, permissions, shared state, and working context buried in that harness’s chat history. The loop does the turn. The control plane keeps track of the organization in which the turn means something.
This is an architectural boundary, not magic portability. It doesn’t mean a company can switch a live workload between harnesses with no loss, behavioral change, or operational work. Different harnesses and models have different capabilities and assumptions. QM gives the shared operating context somewhere deliberate to live instead of asking one agent transcript to be the company’s memory, policy system, and org chart.
Why this is interesting from a Hermes perspective#
I read QM from the perspective of someone accustomed to Hermes Agent. That is a useful contrast, not an objective product comparison.
Hermes makes intuitive sense as a personal agent. Its value compounds around one person’s tools, memory, preferences, skills, and recurring workflows. Over time, the agent can become more useful because those pieces reflect how that person actually works. Continuity is personal, and that is part of its power.
QM asks what happens when continuity has to compound for a group.
A team wants work to get easier over time, too. A project room should retain useful procedures, materials, and scheduled work so the next request can begin from a maintained place. But it can’t flatten every employee, direct message, project, permission, and credential into one context.
So the questions change. With a personal agent, I care whether it understands my intentions and can carry them across tools and time. With a company agent, I also need to know whose intention it is carrying, which space supplied the context, who can change the setup, who can approve an action, and where the result should remain visible.
Hermes shows why continuity can become valuable. QM is exploring the harder version: shared continuity without erasing the people and spaces that give company work its structure. That’s the connection I see between them.
Boundaries deserve grown-up attention#
QM is ambitious, early software, so operators should take its boundaries seriously. The project’s own security document says its isolation goal isn’t a promise that data can’t leak, a certification, or a substitute for a deployment-specific security review. That isn’t evidence of a compromise. It is a sensible warning about the work still required around a powerful system.
Auto is QM’s default security posture, and when content can’t be screened, QM’s core can allow it onward with an explicit unscreened notice. Strict pauses for human approval on every harness tool call except two no-effect turn enders. Its name still shouldn’t replace reading its behavior.
Sandbox choices also carry different enforcement properties. Local Docker and the default AWS backend don’t enforce QM’s domain egress allowlist. That doesn’t mean AWS provides no network isolation. It means operators shouldn’t confuse broader infrastructure controls with this specific application policy. Brokered organization credentials remain server-side and are inserted into constrained HTTPS requests.
Persistent shared memory brings familiar questions about retention, deletion, audit access, and legal obligations. That is a governance concern, not a claim that QM has leaked data. A system that remembers on behalf of a group needs clear rules for what it keeps and who remains responsible for it.
The idea is bigger than this implementation#
QM will probably change quickly. The harness list may change. The security model may mature. Some of today’s implementation choices may disappear.
But the problem won’t. A shared agent isn’t merely a personal agent with more users in the room. It needs an explicit theory of people, spaces, authority, memory, and responsibility.
QM has put that problem in the foreground. It separates the agent doing a turn from the organizational control plane that gives the turn context and limits.
That gives us something concrete to watch: whether QM can make scope, authority, and memory usable in ordinary work, not just visible in an architecture diagram. If it can, the company agent starts looking less like one enormous chat and more like shared infrastructure. Even if this implementation isn’t the final answer, that shift is worth paying attention to.