QM makes the coding agent a swappable part

Y Combinator's QM made a quietly consequential choice when it was released under the MIT licence on July 31. Its README did not crown one coding agent. It named four—Pi, OpenCode, Codex and Claude Code—and said they could all drive the same core.

That sentence is more important than the launch traffic. Most agent products sell the runner as the product: choose our loop, our memory and our way of acting. QM puts the durable machinery somewhere else. The core owns identity, policy and scheduling; Postgres holds sessions, memory and queues; each person or room gets a scoped sandbox. The coding agent sits behind an interface.

My claim is that this inverts the usual agent decision. The runner becomes a replaceable tool only when the organisation can keep its state, permissions and operating record during the replacement. An adapter list suggests that possibility. It does not prove it.

The valuable boundary moved outward

The July 31 QM snapshot describes personal and shared scopes, with their own memory, files, keychain view, permissions, crons, web apps and durable sandbox. It also puts harnesses, session storage, sandboxes and memory behind interfaces, wired into a shared core. Version 0.1.4 was released that day, and the repository carried an MIT licence.

Read that architecture from the outside in. A person does not become a different employee because the runner changed. A room should not lose its files because a different loop handled the next turn. The approval posture should not loosen. The audit record should not split into two incompatible histories. If those properties belong to the core, a runner swap can become a bounded engineering change instead of an organisational migration.

This does not eliminate lock-in. It relocates it. The durable dependency becomes the harness contract: how scopes are represented, where state lives, which action policies are enforced, and whether the history can leave. That is healthier than coupling every layer to one model vendor, but it still deserves the same exit scrutiny. Portability has to include the learning layer, not just the executable loop.

This AI-narrated, AI-animated companion illustrates four coding-agent modules plugging into a shared core while memory, permissions, state and approval gates stay with the harness.

Four integrations do not equal interchangeability

It is easy to mistake “supports four harnesses” for “the four harnesses are interchangeable.” They are not the same statement.

Different runners can interpret instructions differently, request different tools, recover from failures differently and persist different details. One may ask before a risky write; another may attempt it and rely on a downstream policy to stop it. One may preserve a useful trace; another may compress away the evidence an operator needs. They can share an API boundary and still produce meaningfully different operational behaviour.

So runner portability is not a checkbox. It is a property you test against work that matters. The question is not whether runner B starts. The question is whether the organisation can move a real task from A to B without changing who can see what, what actions are allowed, what history remains inspectable, and how the failed change rolls back.

Prove it with a swap drill

Here is the acceptance test I would put into an architecture review. This is a proposed drill derived from QM's public contract; I did not execute it against a QM deployment for this article.

rendering diagram…

Start with one representative scope and copy its task, files, credentials boundary and approval policy. Run the same task through two supported runners. Then inspect five things: state visibility, denied actions, approval prompts, trace completeness and recovery after a forced failure. The outputs do not need to be word-for-word identical. The governed boundary does.

That distinction matters. Model variability is expected; policy variability is a defect. A different explanation can be acceptable. A runner silently seeing another room's files is not. A different plan can be useful. A missing approval on the same write is not.

Run the reverse swap as well. If the first runner cannot resume after the second has touched the shared state, you have one-way migration, not interchangeability. And force the losing case: cancel a turn midway, revoke one permission, then check whether the core—not the runner—remains the authority that decides what survives.

Buy the seam, then test the seam

The practical change is small. Stop asking teams to standardise on one coding agent before they have defined the boundary around it. Standardise first on the things that must survive a change: identity, scoped state, action policy, audit format, evals and rollback. Then let runners compete inside that boundary.

This is also how to evaluate QM or any similar harness. Do not settle for a model picker or a list of adapters. Ask for the swap drill with an existing workspace. Watch what happens to permissions and history, not just whether the second runner produces an answer. If the demo requires a fresh workspace, it has demonstrated installation—not portability.

The agent-harness-as-release-platform argument still holds: models are only one release input. QM adds a sharper test. If the harness is truly the durable layer, replacing the runner should be boring, observable and reversible.

Steal this for the next “which coding agent?” discussion: write down the five things that must not change, swap the runner, and make the team show the evidence. Preference is not architecture. A clean seam that survives a drill is.

A coding agent is only a swappable part after state, policy, audit history and rollback survive the swap.