Kortix vs QM: both open source, one organizes work around rooms, the other around branches

QM is a serious bet that an AI colleague belongs to a person or a room. Kortix, the open-source CompanyOS, bets that work belongs to a repository, and that each session's result should be reviewed before it lands. Both are multiplayer, both keep state outside the model, and both hand the agent a real computer. What separates them is the unit of work a company organizes around.

QM details come from its main branch at f5d40e7, its README and spec at that commit, and the @yc-software/qm 0.1.15 package, published 2026-10-20. Kortix details come from its project docs. Both were checked in October 2026.

Rooms against branches

QM
person or room -> scope -> persistent memory + files + computer
               -> conversations, schedules, credentials, published apps

Kortix
git project -> session -> isolated computer + session branch
            -> agent work -> change request -> reviewed merge to main

For QM the unit is the scope. A person, a Slack channel, a group message or a project room each get a durable scope, and that scope owns memory, files, credentials, schedules, skills and a computer. Kortix's unit is the project, which is a git repository plus kortix.yaml. A session takes a branch and a sandbox, and durable work returns as a change request.

Continuity is QM's promise: a colleague that remembers the room. Auditability is Kortix's: a company where you can see which agent changed what, and who accepted it.

Persistence: a warm room or a readable repository

QM keeps sessions, memory, queues, grants and audit data in Postgres. Each scope also gets a durable workspace and home directory, so a resident computer keeps installed tools and CLI logins warm between turns. Artifacts cross from one scope to another only through an explicit grant.

Kortix splits that job in two. Supabase Postgres holds accounts, projects, sessions, sandboxes, triggers, grants, audit events, usage and gateway logs. The project repository holds the agents, skills, memory, policies and runtime configuration that people edit and review, and runtime state sits outside /workspace so it never mixes with the company's files.

So QM optimizes for continuity of a colleague and a room, and Kortix optimizes for diff, rollback and promotion to main. A room accumulates context that nobody reviews. A project can show the change and the person who approved it.

A computer per room, or a computer per session

QM assigns a durable computer to a scope. On Fly the core and each sandbox run as Machines in the operator's own organization, beside private object storage. On AWS the agent computers are Lambda MicroVMs, and a home snapshot is kept in S3. Tools installed once stay installed, which is what a daily colleague needs.

Kortix assigns a computer to a session. One isolated sandbox per session. Each session has its own isolated machine and branch. Platinum is the reference provider, and new sessions land there through a single provider interface. About 15 to 20 minutes after the last turn, Kortix stops the computer, keeps /workspace, the branch and the conversation, and a preview request or a new prompt wakes it again.

Neither lifetime is better in the abstract. A scope that stays warm spares an everyday colleague the setup ritual. A session that starts clean bounds the blast radius and gives concurrent work its own branch.

Screening content, or authorizing an identity

QM picks one posture per organization, and a narrower scope can only tighten it. Strict pauses every harness tool call for human approval. Auto, the default, blocks private-network access. Dangerous removes the approval gates and caps content screening at observe. Screening is a deployment setting of its own, securityScreen.mode, which stays off unless an operator turns it on, and the predeclared command policy applies in every posture, Dangerous included.

Kortix starts from identity. Authorization runs on the principal, the project, the session, the agent's grant and the action. Connector credentials are brokered server-side and never enter the machine. Project secrets are a different case: an explicitly granted secret is injected as a real environment value, and any command in that session can read it. Connector policies decide allow, ask or block, and session work reaches main through a change request. Merge is default-deny for agents.

QM spends its policy on what reaches the model and what a tool call may do. Kortix spends it on who is acting, and on whether durable work reaches the shared branch.

A swappable harness, or one contract for every client

QM treats the harness as an interface. Pi and Claude Code both drive the same core, and the spec says a turn can be fulfilled by either. An operator can change the model loop without touching identity, memory, delivery or the sandbox system.

Kortix spends that design budget on the client contract. Every client reads a session through the same session API, so the web app, the CLI, a mobile build and a white-label host share one surface. A client builds against that contract, and the harness sits behind it.

QM wins when harness interchangeability is the requirement. Kortix wins when many clients need one stable surface.

Side by side

Migration remaps the unit of work

There is no drop-in migration, because the two systems disagree about what the durable thing is. Leaving QM means turning scopes into projects, scope skills and memory into repo files, crons into triggers, keychain entries into connectors or secrets, and live work into sessions. The real decision is which room-local state belongs in version control and which should stay operational.

Going the other way is quicker to describe and harder to run. Projects and teams become scopes, agents and skills move into a deployment layer, triggers become crons, and app publishing replaces change-request promotion. The branch-per-session review gate disappears unless someone rebuilds it as a skill and a policy.

When the room is the product

QM is MIT-licensed, and Kortix is open source. Pick QM when the room is the product and continuity is the feature your people feel. Pick Kortix when the repository is the product and every durable change should arrive as a reviewable diff. Running both is possible in principle, with QM holding the conversational scope and Kortix running project sessions behind it, but that adapter has to carry identity, grants and delivery provenance across two systems. Treat it as a connector project, not a configuration flag.