Inside QM: We read Y Combinator’s company-wide agent runtime

Why it matters

QM turns YC's experience operating more than 50 internal agents into a self-hostable control plane, making permissions, persistent workspaces and fleet administration the core infrastructure problem.

Code reviewed: yc-software/qm at commit 7f2c916, the source revision recorded in npm package @yc-software/qm@0.1.4

Two days after Y Combinator published QM, the project had already drawn 6,600 GitHub stars, 700 forks, 68 pull requests and 14 open issues. That attention makes sense. QM is one of the first open-source attempts by a prominent organization to turn the local coding-agent pattern into shared company infrastructure.

The short description—“a multiplayer agent harness for work”—undersells the amount of machinery involved. QM is a durable, scoped operating layer for agents. A model loop is one replaceable component. Around it sits identity resolution, a permission graph, file and memory boundaries, credential brokering, command policy, human approvals, content screening, background scheduling, app publishing, audit logs and cloud-specific sandbox lifecycle management.

This is our follow-up to RuntimeWire’s launch report. We downloaded the public repository and npm package, pinned both to the same revision, read the runtime and deployment code, generated a fresh deployment directory and ran the package’s CLI test suite. The result is a source-level map of what QM does, where its strongest ideas live and which security promises should still be treated as experiments.

The short version

• “Multiplayer” means people and rooms get isolated scopes. A direct message resolves to a personal scope; a channel or group message resolves to shared state. Context from a previous turn is retained only when every member of the current audience is entitled to see it.
• The durable computer is the central product idea. Each scope gets files, installed software and long-lived processes inside a sandbox. The model can change while the workspace survives.
• QM supports Pi, OpenCode, Codex and Claude Code. They implement one harness interface, though their capabilities differ. Codex, Claude and OpenCode expose native child-agent roles; Pi, the recommended default, runs the scoped turn loop without that native subagent layer.
• The npm package is a deployment CLI. It contains no QM runtime. It generates a deployment repository and pins six prebuilt container images by SHA-256 digest.
• Memory is plain text with model-assisted maintenance. Durable facts live as bullets in memory/MEMORY.md; recall uses case-insensitive substring matching, capped context and optional model consolidation. There is no vector database in the default path.
• Security is a control plane, not a hardened isolation claim. Command rules, approvals, credential grants, audience floors and screening add useful friction. YC’s own threat model says command policy is bypassable, credential material is visible in sandboxes, screening is incomplete and the system is intended for a single trusted organization.
• One security warning is already stale. SECURITY.md says published apps can be reached through bearer capability links. The pinned implementation deletes those query tokens, refuses to mint the associated cookie and tests that the link “grants nothing.” Built-in subdomain ingress now requires a portal session plus ACL membership, with a separate short-lived owner link for management.

What we actually inspected

The public repository’s history begins on July 29 with a commit called “Fresh repo history.” The latest package at reporting time was 0.1.4, published July 31 at 18:03 UTC. Its npm metadata points to commit 7f2c916360f1797a8ff2a77ce2ce40c5fabab087. That is the revision used throughout this piece.

The 74,814-line figure describes the TypeScript runtime under src, not the whole repository and not hand-authored logical lines. It is a reproducible filesystem count, useful mainly as a measure of surface area. The largest files include the 2,841-line orchestrator, the 2,483-line common tool layer and the 2,047-line Pi adapter.

We did not deploy QM into Fly.io or AWS, connect a live Slack workspace, supply real model credentials or execute the full Postgres-backed root suite. The repository’s own CI is broader: five root-test shards, Postgres durability tests, typechecking, four plugin builds, image smoke tests, several linters, dead-code checks, packaged-artifact tests and deployment-contract tests. Our independent execution covered the published CLI path.

Why YC built it

YC’s release note gives a compact history. The organization began with a simple Ruby agent loop and a few internal-data tools, added crons and webhook triggers, then provisioned more than 50 Hermes agents as personal assistants. The individual agents were useful; administering the fleet became the problem. YC wanted the flexibility of that setup, the simplicity of the earlier loop and infrastructure it could host itself.

The name is short for quartermaster: the person coordinating work below decks. That metaphor fits the code. QM spends much more effort deciding whose computer, memory and authority a turn receives than it spends defining model prompts.

The public history tells us less about how the system evolved than a normal open-source repository would. SECURITY.md says public source releases intentionally start with fresh history and that private-history hashes are unsupported. The 40 visible commits cover July 29 through July 31. They show release preparation and rapid fixes; they cannot support a forensic account of the earlier internal system.

What ships when you install QM

The first surprise is that the npm package is not the runtime. cli/README.md says this directly: the package is a release and deployment CLI. It validates config, renders infrastructure, pushes secrets, coordinates upgrades and shells out to tools such as Docker, Fly, AWS, Terraform and Git. It has no JavaScript runtime dependencies of its own.

Running qm init creates an organization-owned deployment directory. In our Docker-target test it produced:

• qm.config.jsonc, a package file pinned to 0.1.4, lockfile inputs and digest-pinned image manifests;
• .env.example containing secret names, plus an empty, ignored .env rather than credential values;
• operator documentation and an AGENTS.md file;
• a deployment skill for Codex, with runbooks for setup, checking, deployment and verification;
• sample directories for organization-specific skills and sandbox tools.

The release process builds six images—core, web UI, admin, portal, auth and sandbox base—then signs each exact digest with Sigstore. The npm publishing workflow replaces placeholder image references with those six digests and invokes npm publish --provenance. The package we downloaded contained the same digests produced by that release. This design gives an operator immutable first-party artifacts while keeping organization-specific deployment state in a separate repository.

It also creates an important review boundary. Reading the npm tarball alone tells you how deployments are generated. The runtime behavior lives in the container source at the linked Git revision. A security review needs both.

The useful mental model: one scope, one durable computer

QM’s top-level architecture has three durable pieces:

1. Postgres holds sessions, messages, memory revisions, jobs, grants, audit records and other control-plane state.
2. The core API resolves identity and scope, applies policy, schedules work, invokes the selected harness and records the result.
3. A per-scope sandbox supplies files, commands, processes and installed software.

Slack runs as an optional in-process plugin. The web UI, admin interface, authentication service and portal are optional HTTP services around the headless core. The runtime is TypeScript executed directly by Node; Fastify serves the API, Slack Bolt handles Slack, and the browser client is built with Vite and Lit. The repository README provides YC’s own concise diagram.

A normal turn proceeds roughly like this:

1. The Slack or web surface authenticates the sender and describes the current audience.
2. Resolution maps the conversation to a scope and computes mounted scopes, instructions, ACL grants, command policy, security posture and egress floor.
3. QM loads only the history and memory the full audience may see.
4. The selected harness receives a common turn object and fixed set of QM tools.
5. Tool calls run through policy wrappers. Commands execute inside the scope’s sandbox; credential use passes through the keychain and broker rules.
6. Results and provenance can be screened before re-entering the model context.
7. The reply is delivered, the turn is persisted and memory extraction runs asynchronously.

That ordering matters. QM does not ask each model vendor to implement company isolation. It calculates company context before invoking the model and wraps the tool surface around the model afterward.

“Multiplayer” is an authorization graph

The public description says every employee and project gets an agent. In code, an agent is better understood as a resolved scope plus durable state. src/types.ts defines five scope kinds:

The resolution service turns a DM into the actor’s personal scope and a room into shared channel or group state. The current scope is mounted read-write. Organization and relevant team layers can be mounted read-only. Organization instructions sit above lower-scope instructions; local customization cannot loosen the organization’s security or approval floor.

The sharpest implementation detail is the audience filter. context-filter.ts retains an item of history only when every person in the current audience is entitled to it. If a private interaction becomes a shared one, the model does not automatically inherit the private transcript. Egress rules use the same conservative shape: allowed hosts are intersected across the audience and denied hosts are unioned.

Sharing is backed by an ACL graph. Managers grant or revoke access; a recipient cannot transitively reshare an object unless the policy separately allows it. For an audience-owned file handle, the checks consider both the owner and the entitled recipients. This is real authorization logic, not a prompt telling the model to be careful.

YC’s threat model still records a gap: provenance labels do not yet cover every source path, and the ambient Slack judge does not perform a complete internal audience check. The audience floor is one of QM’s strongest ideas. Its own maintainers do not present it as complete information-flow control.

Memory: a notebook, an extractor and a janitor

QM’s default memory system is pleasantly inspectable. Each writable scope has a memory/MEMORY.md file containing up to 300 bullet facts. Recall is capped at roughly 6,000 characters. memory-service.ts deduplicates exact facts, drops the oldest when the notebook is full and answers memory queries with lowercase AND-substring matching.

There is no semantic index or embedding store in the default implementation. The model supplies the intelligence around a plain-text ledger.

After a burst of activity—by default, up to ten turns separated by no more than three quiet minutes—the per-turn strategy asks a model to extract durable preferences, identifiers and project facts. Its prompt excludes secrets and system mechanics. Facts said in a channel or group may also be copied into the speaker’s personal notebook with provenance such as “said in #channel”; facts from DMs are excluded from that copy path.

After ten new facts, a consolidation pass can rewrite the notebook through ADD, UPDATE and DELETE operations. The prompt says an explicit “remember this” instruction must not be weakened or deleted and provenance should survive. The database keeps revisions, so memory can be restored. Because extraction and consolidation happen after the answer, new memory is eventually consistent rather than guaranteed to appear within the just-completed turn.

Two alternate strategies are present. agent-only leaves maintenance to explicit agent actions. scratch-promote writes dated scratch logs, recalls the last two days by default and periodically asks a model to promote durable items into the notebook. The strategy is selectable behind an interface; per-turn is the default.

This approach is easy to audit and edit. It also makes the model part of the retention policy. A faulty extraction can record the wrong fact, and durable material may persist indefinitely unless a user or administrator removes it. QM acknowledges that risk.

The sandbox implementations are materially different

The sandbox interface covers process execution, durable disk, scratch environments, suspension, hydration and optional egress capabilities. The available backends do not provide identical isolation.

The AWS defaults are four vCPUs, 8 GB RAM, an 8 GB disk and an eight-hour maximum session, with rotation at 7.5 hours. Before suspend or rotation, the scope’s home directory is packed and written to S3; the next VM hydrates it. This is how “installed tools stay installed” survives an ephemeral compute substrate.

QM also creates scratch sandboxes for narrow tasks. Scratch environments are credential-free, mount only organization-global context and are destroyed after the turn. That makes them useful for processing untrusted material with a smaller blast radius.

The phrase “durable computer” should not be read as a universal network sandbox. The deployment descriptor accepts egress configuration, yet docs/deploy-directory.md says version one validates that descriptor without claiming runtime enforcement. The security document says conditional egress is backend-dependent. Local Docker and AWS explicitly report no native egress support through this interface.

Four harnesses, one core—and uneven capabilities

QM pins four model-agent integrations at this revision:

All four implement the HarnessAdapter contract. That lets the same scope resolution, policy, persistence and tool ledger surround different agent loops. Model and harness can be selected globally and overridden by scope within operator limits.

The common tool surface is small: execute, read, write, publish, memory, history and background, with cron, sharing, guidance and turn-ending tools added when the control plane allows them. In read-only mode, only memory recall, history and a silent turn end survive. Strict posture wraps every effectful tool call in human approval.

Codex, Claude and OpenCode then expose their own constrained child-task machinery. Claude’s hook prevents child agents from contacting people, scheduling, changing standing configuration or suppressing the parent’s reply. Codex maps app-server task events into QM’s run and limits child tools. These are genuine subagents, distinct from YC’s broader “fleet” language. The fleet is primarily the set of persistent people and room scopes; child agents are temporary workers inside some harnesses.

The Pi dependency deserves a footnote. YC publishes qm-pi-coding-agent-0.82.0-security.2 from its yc-software/pi repository. Comparing that tag with upstream Pi 0.82.0 showed changes in seven files: a brace-expansion override moved from 5.0.7 to 5.0.8 in lock/package metadata, and an MIT license was added to the package. We found no behavioral agent-loop fork in that diff. The custom tag is a narrow packaging and supply-chain patch.

Credentials: strong brokerage until materialization

QM’s keychain stores encrypted credential records. The implementation uses AES-256-GCM with keys derived through HKDF. Grants bind a credential to a scope, person and mode; they may be one-time or standing, and can expire. A person can grant credentials from their own personal scope. Standing grants and broader sharing remain subject to operator rules.

For supported HTTP use, the credential broker is the best path. The core verifies caller headers and entitlement, requires HTTPS, matches the destination hostname and optional subdomain rule, limits methods and path prefixes, injects the secret inside the core, and caps request and response sizes. The sandbox command sees the broker endpoint rather than the underlying token.

That protection ends when a credential is materialized into a sandbox for a CLI or other tool that cannot use the broker. SECURITY.md says material is plaintext and readable by software in that sandbox. A grant’s purpose field is recorded and shown to the model; it is not enforced authorization after materialization. One-time means one atomic materialization, not one downstream API operation.

That distinction is essential. QM has a serious credential control plane. It cannot make an arbitrary logged-in command-line client keep a token secret from the agent controlling that same computer.

Three security postures, plus an always-on command floor

An operator selects one organization posture; narrower scopes can tighten it:

All three retain a command-policy floor. The default rules require approval for recursive deletion, force pushes, destructive SQL and shell-piped downloads; filesystem formatting and a fork bomb are denied. The scanner recursively expands nested shell payloads to a depth of eight.

This is useful protection against accidents and obvious attacks. It is not a shell security boundary. The maintainers say encoding a payload or writing and executing a script can bypass the rules. The model and sandbox are explicitly treated as untrusted, while the operator, core host and database remain privileged.

The automatic screening layer similarly has limits. It gathers provenance-labelled external content, caps what it sends to the classifier and can quarantine content when the classifier returns a strict verdict. Some unavailable or unsupported screening paths fail open with a warning marker and audit event. The ambient Slack judge and OpenCode sidecar have paths that do not all pass through the same model gateway. Browser actions sit outside the command/HITL policy, and browser-provider network access does not necessarily follow sandbox egress.

YC’s security document is refreshingly direct about the intended environment: an internal, single-organization deployment with a trusted operator. It is not presented as hardened public multi-tenancy, a certification or a proof of confinement. Administrators are privileged content readers, model and browser providers receive data sent to them, and durable sessions, audit records, files and memory may remain indefinitely.

The app-link documentation drift

Our most consequential code-versus-documentation finding concerns published apps.

The threat model says an owner can distribute a bearer capability link and that anyone holding it can reach the app. That was apparently true in an earlier design. At the pinned release, built-in subdomain ingress behaves differently.

deployments.ts removes ?access= from the URL, deletes stale capability cookies and declines to mint a replacement. Ordinary app access requires a valid portal session and an ACL check. Owners can request a separate signed management link with a five-minute expiry. The corresponding test is named “a capability link grants nothing — reach is the ACL alone,” and asserts that stale query and cookie credentials fail.

The accurate conclusion is narrow: bearer visitor links are disabled on the built-in subdomain gateway in 0.1.4; SECURITY.md has not caught up. Custom plugins or externally exposed app endpoints need their own review.

Launch-week bug reports

The public issue tracker is moving quickly. At reporting time, 14 issues were open. Several are detailed, code-referenced reports rather than feature requests. They include a fresh Fly deployment failing to request and push SPRITES_TOKEN (#130), a pinned GitHub CLI RPM no longer available to the AWS MicroVM build (#122), an attachment-only Slack message being lost during mid-run steering (#48), and delivery acknowledgement occurring before a Slack reply is successfully posted (#44).

We did not reproduce those four operational paths. They should be read as open reports, not confirmed vulnerabilities. Their specificity is still useful evidence about maturity: 0.1.4 is a launch-week release, and cloud and delivery edge cases are being discovered in public.

Background work: crons, watches and a webhook-shaped gap

QM’s background system has two clear mechanisms.

Crons support cron expressions, time zones, interval schedules, first-fire times, run-as identity and a destination. Each firing creates a fresh thread while the task definition, workspace and fire log persist. Postgres-backed jobs use pg-boss; singleton identifiers and leases limit duplicate work. A scheduler sweep is available as recovery. The default cron-fire concurrency is four.

The background tool can also leave a process running in the sandbox and register a watch on its output, exit, matching text or other conditions. The monitor poller uses a three-minute heartbeat by default, enforces a minimum interval, caps stored events and wakes the original conversation through the security-screened turn path. A watch expires and process sessions have hard time-to-live rules; event fan-out is capped.

YC’s release note says its historical Ruby agent acquired webhook triggers. The open runtime contains webhook as a provenance/session-origin type and the deployment documentation shows proxyable webhook-shaped endpoints. We did not find a general built-in webhook receiver that creates ordinary turns at this revision. That capability may be expected from an organization plugin or external integration. Crons and process watches are the complete, directly traceable background paths in the public core.

Internal app publishing

The publish tool turns scope-owned code into a versioned internal app. Deployment records bind an app to its owner and scope, keep versions, support updates and rollback, and attach view/manage grants. Apps are owner-only until shared through ACLs. Git access uses signed, expiring, principal-bound authorization and checks revocation.

QM treats app code as a separate trust boundary. The core does not review generated application code for safety. Credentials or environment values supplied to an app are explicit, and ambient author credentials are kept out of the app runtime. The built-in gateway adds portal identity and ACL checks, as described above.

This feature makes QM broader than a chat assistant. A conversation can produce a small operational surface, publish it to a team and continue updating its data in the background. It also widens the application-security workload: every generated app becomes software an operator must monitor, patch and eventually retire.

Deployment and rollback

The supported targets are local Docker, Fly.io and AWS. Fly combines applications with Sprites/Machines. AWS renders ECS Fargate services, RDS, S3 and the MicroVM sandbox layer. Slack uses Socket Mode inside core; the portal is the intended public entry point.

The generated directory is a contract between an organization and the CLI. Configuration and secret names live there; secret values stay in the operator environment and provider secret store. An organization can add tools, skills, a custom sandbox image and plugins without modifying core. The release images remain pinned by digest.

Rollbacks have different meanings by target. The Fly path restores the previous sandbox pin. Docker teardown can be destructive when purge is requested. AWS takes an RDS snapshot before a mutating deployment; code and config rollback do not themselves restore database contents, so the CLI prints the restore point for operator action.

The default project contains no live production deployment workflow. Terraform and cloud actions remain operator-run. That avoids quietly granting CI broad infrastructure privileges, though it also means repeatable change control is the adopter’s responsibility.

Organizations that want core and private customizations in one repository are told to create a standalone private clone, never a GitHub fork. GitHub forks share an object network and public forks cannot become private; a commit pushed into that network can remain fetchable by hash. QM places private material under deploy/layers/<org>/ and supplies skills for merging upstream and preparing scrubbed upstream patches. The core is expected to stay byte-identical to public QM.

A codebase built by agents, governed through prose

QM’s contribution policy is as interesting as the runtime. CONTRIBUTING.md says coding agents write most of the underlying code. External contributors are asked to submit informal, human-written text proposals under adrs/; maintainers then use their own agents and context to implement accepted ideas. The public directory was empty apart from a placeholder at the reviewed revision.

The internal AGENTS.md is strict: avoid comments and docblocks, never self-review, use an independent agent for review, run affected tests, perform live Slack QA when relevant, capture screenshots for visible changes and preserve the private/public repository boundary.

This helps explain the code’s shape. Interfaces are explicit, tests are abundant and names carry more explanatory weight because comments are discouraged. It also creates an unusual governance model: contributors propose intent, maintainers spend the inference budget, and an agent performs an independent review. The quality of that review depends on prompts, context and execution discipline that are only partly visible in Git.

What QM gets right

The scope is the durable unit, rather than a vendor-specific conversation. That decision gives QM a coherent answer to several hard problems at once: shared work, personal customization, persistent computers, model switching and permission-aware context.

The audience-wide context filter is particularly strong. Many workplace agents bolt access control onto retrieval and then leave conversation history as ambient context. QM re-evaluates history against the whole current audience. Its intersection/union rule for egress applies the same idea to action.

The deployment split is also disciplined. A small provenance-bearing CLI creates an organization repository and pins signed images. Organization details can remain outside the public source tree. Reproducibility and privacy have concrete mechanisms instead of relying on a README promise.

Finally, the threat model is useful because it names the failures operators are likely to misunderstand. Plaintext credentials inside a controlled computer, bypassable shell pattern rules, incomplete provenance, browser side channels and privileged administrators are the actual fault lines of an internal agent system.

Where the model still leaks through the abstraction

The harness interface makes vendors interchangeable at the control-plane level. They are not behaviorally equivalent. Steering, provider-managed sessions, thinking modes, image handling and child-agent support vary by adapter. A company changing harnesses should expect different task quality, latency, cost and failure modes even when permissions remain stable.

Memory consolidation and content screening both delegate judgment back to models. The surrounding code bounds their inputs and records outcomes; it cannot guarantee correct classification. The default memory query is also literal enough that useful facts can be missed unless the current wording overlaps the stored bullet.

Egress is the least uniform infrastructure control. Some backends can force domain routing through a proxy; others expose no native enforcement through QM. Browser providers and app runtimes add separate network boundaries. An operator needs a deployment-specific data-flow diagram before treating “egress policy” as a universal guarantee.

Operational maturity is the final constraint. The source contains a substantial test program and careful release machinery. The package is days old, public history is deliberately shallow, and launch-week cloud bugs are open. Those facts can coexist.

The verdict

QM is a credible reference architecture for company-wide agents. Its defining contribution is the combination of scoped authority and durable computers: each person or room receives a persistent working environment, while the core recalculates context and permissions for every audience and action. The model loop can then be Pi, OpenCode, Codex or Claude without becoming the source of organizational truth.

The project is ready to study, prototype and adapt inside a trusted organization with experienced operators. Production adoption calls for a threat model tied to the chosen sandbox, identity provider, connectors, model vendors and retention obligations. Strict posture can pause actions; it cannot repair an unsafe generated command after a human approves it. Auto screening can reduce exposure; it cannot prove that prompt injection is contained. A durable workspace raises capability and retention risk together.

The public release matters because it exposes the hard parts. QM’s most valuable code is found around the agent: the audience filter, resolution service, ACL store, credential broker, run ledger, scheduler and sandbox lifecycle. That is the layer workplace-agent discussions have often skipped. YC has now put a serious implementation on the table, along with enough caveats to show how unfinished the category remains.

Reproduction notes

# Pin the reviewed source
git clone https://github.com/yc-software/qm.git
git -C qm checkout 7f2c916360f1797a8ff2a77ce2ce40c5fabab087

# Download the reviewed package
npm pack @yc-software/qm@0.1.4
sha256sum yc-software-qm-0.1.4.tgz

# Inspect package metadata and provenance pointer
npm view @yc-software/qm@0.1.4 version time dist --json

# Generate a local deployment directory without putting secrets in config
npm exec --yes --package=@yc-software/qm@0.1.4 -- \
  qm init ./qm-deploy --org example --target docker

RuntimeWire’s tarball SHA-256 was 51593f853eade42ed04f10e96e1c8ddffca876c5be0ee98d753636018ee5e473. Readers should expect npm’s published integrity field to remain stable for the same immutable version.

Primary source index

1. YC’s QM release note
2. QM repository and reviewed commit
3. README and system architecture
4. Threat model and known limitations
5. CLI and deployment contract
6. Scope resolution and audience filtering
7. Memory service and memory strategies
8. Sandbox interface, local Docker, Sprites and AWS
9. Harness interface and adapters
10. Security postures, command policy and keychain
11. Published-app ingress and capability-link test
12. CI workflow, signed image workflow and npm provenance workflow
13. Contribution policy and agent instructions

Disclosure: RuntimeWire performed a static source and package review plus local CLI tests. This was not a penetration test or a production deployment audit. Repository and issue counts are a snapshot from August 2, 2026.