qm: An Open-Source Project That Treats AI Agents as Employees
There is an open-source repository whose contributing guide is unusually blunt: do not send pull requests with code. If you want a feature, write a short paragraph in plain language describing the change you want, and the maintainers will burn the tokens to implement it themselves.
The project is called qm, originated from a YC-affiliated team, and named after "queuing machines." Its tagline reads: a multiplayer agent harness for work. It is licensed under MIT, ships over 37,000 lines of TypeScript, includes 377 test files, and received commits as recently as the day before this review.
What It Actually Does
Most AI tools assume the "personal assistant" model: one agent helping one user, maybe stretched across a few chat windows. qm reframes the agent as a newly hired employee provisioned with a full environment.
Key properties:
- Each agent gets an isolated workspace with its own memory, files, secrets, permissions, cron jobs, and sandbox.
- Each room, channel, and project has its own scope.
- Agents can collaborate with humans and with each other in Slack channels, groups, and project scopes.
- Strict: every harness tool call pauses for human approval, except two side-effect-free turn-ending tools.
- Auto (default): a classifier screens data before it reaches the model to detect injection attempts (redirecting the agent, stealing credentials, exfiltrating data), and may redirect to its own screening agent.
- Dangerous: no content filtering, no inter-tool pauses.
- It treats agents as coworkers, not tools, so it gives each one a full workstation.
- It expects model vendors to change, so the engine is pluggable.
- It accepts that AI-written code needs human scrutiny, so it redefines the contribution format.
- It refuses to promise safety, so it publishes the threat model on the first page of the docs.
- qm is an MIT-licensed, ~37,000-line TypeScript multi-agent harness from a YC-affiliated team, with 377 test files and active commits.
- The architecture is a headless core (Node + Fastify + Postgres) with a pluggable harness layer supporting Pi, OpenCode, Codex, and Claude Code.
- Each agent runs in an isolated, persistent sandbox with its own memory, secrets, cron jobs, and tools; rooms, channels, and projects have their own scopes.
- The project refuses human-written code PRs and prefers plain-language feature requests that maintainers (and their coding agents) implement.
- A zero-comment policy, mandatory fresh-context review, and "fix all similar instances" convention are enforced via
AGENTS.md. - Security is expressed as three selectable postures (Strict / Auto / Dangerous) plus a non-negotiable destructive-command policy and publicly documented threat model.
- Deployment is a versioned, forkable directory interpreted by the
qmCLI, with target support for Docker, Fly, ECS Fargate on ARM64, and Lambda MicroVMs. - Private forks use a
deploy/layers/<org>/convention to keep all customization isolated from upstream.
In the team's own words: *Most agents are designed like personal assistants. You can make one work for a whole company, but it quickly gets complex. QM is designed for startups.*
Architecture: A Headless Core with Four Swappable Brains
qm's core is headless. TypeScript runs directly on Node, Fastify handles HTTP, and Postgres stores sessions, memory, and queues.
The differentiator is the harness layer. qm supports four harnesses — Pi, OpenCode, Codex, and Claude Code — all driving the same core. A deployment picks one, so no vendor lock-in; swapping is a configuration change.
Every conversation turn flows through the central core, which exposes a small, fixed tool surface. One of those tools is execute, which runs commands inside an isolated sandbox scoped to the agent. The sandbox is persistent: tools installed there stay installed — the agent's "always-on computer."
Schedulers, cron jobs, and monitors keep background work moving. The web UI, admin dashboard, and external portal are optional plugins layered on top of the core HTTP API. Slack runs as an in-process plugin internally supervised by the core.
The architectural philosophy, in one line: the core stays generic; everything company-specific lives in the deployment directory.
Three Counter-Intuitive Design Choices
1. Zero Comments, Anywhere
AGENTS.md states the rule plainly: no explanatory comments, no TODOs, no lint suppressions, no commented-out code. Intent must be expressed through naming, structure, and tests. Reasons go into commit messages and PR descriptions. The team is essentially forcing the code itself to be self-explanatory.
2. Contributions Accepted Only in Human Prose
The contributing guide says: since most of the underlying code is already written by coding agents, PRs are preferred as natural-language descriptions of intent — casual, like messaging a teammate on Slack. Implementations are handled by the maintainers. They even add: do not use AI to expand your idea into a formal proposal.
This signals a clear division of labor: humans decide what should exist; agents decide how to write it.
3. No Self-Review
AGENTS.md mandates a hard rule: before any change merges to main, it must pass a fresh-context review performed by an independent reviewer agent that did not watch the code being written. The bias to defeat is the author's own sunk-context belief that the code is correct. A green CI is not a review, and self-review is not a review.
There is also a convention: when fixing a bug, fix every similar instance across the repository, not just the reported one. Leaving four untouched copies of a known bug is a landmine.
Security: Posture, Not Promises
An organization chooses a security posture; smaller scopes may only tighten, never loosen.
A pre-declared command policy — recursive deletes, destructive SQL, and similar — is enforced across all postures, including Dangerous. Audit logs enable post-hoc investigation but do not block action.
SECURITY.md is unusually honest: it describes the software as early-stage experimental and states that the design goal is to isolate each user's data and activity, not to guarantee that data will never leak. The threat model and known limitations are listed plainly.
Deployment: A Whole Company as a Directory
qm's deployment model is unconventional. Instead of a single docker-compose file, every deployment is a committable, portable directory.
qm init generates it, populating configuration, sandbox Dockerfiles, tools, skills, a Slack manifest, and deployment docs. The qm CLI is the sole legitimate interpreter of that directory — validating inputs and rendering containers, task definitions, and secret routing.
Targets include local Docker, Fly as Fly apps, on AWS run as ECS Fargate on ARM64 tasks pinned by digest, and agent computers as Lambda MicroVMs.
Organizations that need deep customization can fork privately: a separate private repo whose history begins from a clone of qm, with everything organization-specific inside deploy/layers/<org>/ and everything outside that directory kept byte-identical with upstream. Two skills enforce the boundary: update-qm merges upstream changes, and upstream-pr pushes back fixes that are unrelated to the organization — without ever carrying deploy/layers/ content upstream.
The core stays generic. Differences collapse into one layer. The layer is the company; the core is the product.
Is This Cargo Cult?
Does the project ship, or does it merely look correct while the airplane never lands? Restating what it actually does:
The ability to state those four points plainly suggests the project is not vaporware. The 37,000-line codebase likely contains issues the team itself has not found, and the project is openly labeled early experimental software.
The direction, however, is real: the hardest part of putting AI inside an organization is not making any single agent smart enough — it is giving each agent a desk, a memory, a permission set, and the ability to attend meetings and collaborate like a person. Treating agents as employees may be the most important organizational shift of the next decade.