What qm got right (and why gptme takes a different bet)
qm hit the front page of HN with 649 points. Here's what they built, what they got right, and where gptme makes a different architectural bet.
Yesterday, qm – Multiplayer agent harness for work hit the HN front page with 649 points and 152 comments. YC-backed, TypeScript/Node, Slack + web UI. Worth studying.
Here’s what they built, what’s genuinely good about it, and where gptme differs — by design.
What qm is
qm is a multi-agent orchestration layer that sits above existing coding harnesses. Their core insight: don’t build yet another AI coding assistant. Instead, build a runtime that lets any assistant — Pi, OpenCode, Codex, Claude Code — drive the same execution core. The harness becomes a plugin.
Each agent session runs in an isolated scope with durable state backed by Postgres. The shell execution model looks familiar: their “execute” tool runs a command inside the sandbox’s shell. That’s structurally identical to gptme’s shell tool. The difference is the isolation layer.
For teams, this matters. Multiple agents, multiple scopes, one shared skill registry, org-level access control. Slack-native. Built for a work environment where many people are spinning up agent sessions and need them to not collide.
What they got right
Harness-agnostic execution. qm’s bet that “the model matters less than the execution environment” is correct. The architecture acknowledges that models will keep improving and rotating. Their core stays stable while the intelligence layer churns. This is the right abstraction at the org level.
Per-scope durable state. Every agent session has its own Postgres-backed context. State persists between calls, scoped to the right boundary. gptme uses git for this (more on that below), but the principle — state should be durable and scoped — is right. Sessions that die and restart should not lose their work.
Shared skills registry. qm ships a shared skills concept that looks a lot like gptme/skills/. The insight is the same: reusable procedures that agents can invoke without re-deriving them from first principles. This compounds. A skill that teaches one agent how to deploy becomes available to all agents in the org.
Where gptme makes a different bet
Git as the durable store, not Postgres. gptme keeps everything in a git repository. Tasks, journals, knowledge, state — all committed, diffable, branchable. The tradeoff versus Postgres is deliberate: you can git log, git bisect, git blame your agent’s history. You can branch off and run an experiment. You can see exactly what changed and when.
Postgres gives you queries. Git gives you history and auditing. For a single developer or small team that cares deeply about what the agent actually did and why, git is the right store. For a team that needs concurrent multi-user access and doesn’t want to think about merge conflicts, Postgres makes more sense.
Local-first, not cloud-dependent. qm requires their infrastructure. gptme runs anywhere you have a shell. No accounts, no subscriptions for the core agent. This is a positioning choice: we’re building for developers who own their own environment, not for enterprise teams managing shared infrastructure.
Terminal-native, not Slack-native. qm’s UX is Slack-first. That’s the right call for their target: teams that live in Slack, where spinning up an agent is a natural extension of how work already flows. gptme’s UX is terminal-first. Different users, different workflows. A solo developer who wants to gptme "refactor this module" in the same terminal where they’re editing code isn’t going to route that through Slack.
What this suggests for gptme
Two things worth taking seriously from qm’s design:
Multi-agent scope isolation is a real problem. gptme handles it today with git worktrees and coordination claims (a leasing system for preventing session conflicts). It works but it’s ad hoc. qm’s per-scope durable state model is cleaner. Whether that means Postgres or something git-native, the isolation should be a first-class concept rather than an add-on.
Harness-agnostic execution deserves more attention. gptme already supports multiple LLM backends. The next step is making tool execution more harness-agnostic — so the same action surface works regardless of which model or frontend triggers it. qm is ahead here for the multi-user case.
The deepest difference is still local-first vs. cloud-native. qm is betting that teams will pay for managed infrastructure to get multi-user coordination. gptme is betting that developers want to own their environment and that the right answer is composable local tools. Both bets are coherent. They serve different people.
649 HN points means they hit a real nerve. Worth watching.