Kortix vs QM: two open agent platforms, two different units of work

QM and Kortix look similar from thirty thousand feet. Both are open agent platforms for teams. Both put agents in isolated computers, persist work beyond one chat, support Slack and the web, and let an operator run the system in their own cloud. But they are not two implementations of the same product. They choose a different unit of work, and that decision changes almost everything below it.

Compared here:

QM by yc-software

This comparison is based on QM main at `7f2c916`, its published @yc-software/qm 0.1.4 package, and Kortix main at 3006838 on August 2, 2026. We read the runtime, deployment code, security model, storage paths, tests, and operator runbooks. This is a source comparison, not a feature-page comparison.

The shortest accurate explanation

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

QM starts with the social graph. A person, Slack channel, group message, or project room gets a durable scope. That scope owns memory, files, credentials, schedules, skills, and a computer. Kortix starts with the work graph. A project is a git repository and kortix.yaml; each session receives a sandbox and a branch, and durable changes return through a change request.

What they genuinely share

• Multi-user by design — neither system is a single-user desktop agent stretched into a team product.
• Durable work — both keep state outside the model context and survive process restarts.
• Real computers — agents execute commands in isolated Linux environments instead of a narrow function-call sandbox.
• Slack and web surfaces — people can work from a browser or the collaboration surface they already use.
• Background work — QM has crons and watches; Kortix has cron and signed-webhook triggers.
• Model choice — both can use multiple model providers instead of binding the whole platform to one lab.
• Operator ownership — both can run in infrastructure controlled by the customer.

Side by side

Runtime: QM chooses portability; Kortix chooses one deep contract

QM treats the agent harness as an interface. Pi, OpenCode, Codex, and Claude Code can drive the same core. That is real architectural portability: an operator can change how the model loop runs without changing the surrounding identity, memory, delivery, or sandbox system.

Kortix makes the opposite trade. Every session exposes one OpenCode REST runtime through the sandbox daemon. @kortix/sdk owns session startup, runtime resolution, SSE, files, errors, and the mapping between a Kortix session and its native OpenCode conversation. Web, mobile, CLI, and white-label clients use the same contract.

QM wins if harness interchangeability is the requirement. Kortix wins if every client needs one stable, typed, deeply integrated runtime surface. Kortix still routes many model providers through its gateway; it standardizes the agent runtime, not the model vendor.

State: a durable scope versus a versioned company

QM stores sessions, memory, queues, grants, audit data, and other control-plane state in Postgres. A scope has a durable workspace and home. On its resident-computer path, installed tools and login state remain warm between turns. Shared artifacts resolve through grants between scopes.

Kortix separates operational state from authoritative company configuration. Supabase Postgres stores accounts, projects, sessions, sandboxes, triggers, grants, audit events, usage, and gateway logs. The project repo stores the agents, skills, memory, policies, and runtime configuration people are expected to edit and review. OpenCode state lives outside /workspace, so runtime internals do not pollute the company repo.

The practical consequence is important. QM makes continuity of the colleague and room the default. Kortix makes reproducibility, diff, rollback, and promotion to main the default. A QM room can keep accumulating local context. A Kortix project can show exactly which agent changed the company and which person accepted it.

Isolation and lifecycle

QM assigns a durable computer to a scope. Its Fly path uses a persistent home volume and replaces the root filesystem independently during upgrades. Its AWS path uses Lambda MicroVM agent computers and durable object storage. That design favors a warm, laptop-like environment that remembers installed tools and native CLI logins.

Kortix assigns a computer to a session. Daytona, Platinum, E2B, and the experimental local-Docker provider implement one provider interface. The session branch and sandbox share the session identity. The control plane extends a bounded sandbox deadline when it observes a turn start, gateway LLM activity, or authenticated preview traffic. A terminal turn shortens that deadline to the idle grace period. Passive traffic from an open conversation tab cannot keep the sandbox alive, and one continuous running stretch is capped at 24 hours. A stopped session can resume on the same provider identity or recover through the provider-specific path.

Neither lifecycle is universally better. A persistent scope avoids repeating setup for an everyday colleague. A per-session computer provides a clean blast radius and a natural branch for concurrent work. The right choice depends on whether continuity or isolation is the stronger invariant.

Security: provenance screening versus reviewed change

QM selects one organization security posture. Strict pauses harness tool calls for human approval. Auto screens provenance-labelled external data before it reaches the model. Dangerous removes that screening and the per-tool pause, but the command-policy floor still denies or gates declared destructive commands. Narrower scopes can tighten the organization posture.

Kortix centers authorization on the principal, project, session, agent grant, and action. Connector credentials are brokered server-side and do not enter the sandbox. Project secrets are different: an explicitly granted secret is injected as a real environment value and can be read by commands in that session. Connector policies decide allow, ask, or block, and durable repo changes still face a deny-by-default merge boundary.

APIs and product surfaces

QM has a headless Fastify core, an HTTP API, and optional Slack, web, admin, auth, and portal plugins. Its supported npm programmatic contract is deliberately narrow: deployment-directory parsing, validation, and provider metadata. The web surface uses Lit; Slack uses Bolt.

Kortix treats @kortix/sdk as a public product boundary. createKortix({ getToken }) returns one client for project and session lifecycle, files, streaming, runtime health, previews, and errors. React hooks, a TypeScript server entry, the real kortix CLI, mobile, desktop, and the web app build on that package. The API and OpenCode transport are implementation details for host applications.

This is one of the clearest selection criteria. Choose QM when you primarily deploy and operate the included collaboration product. Choose Kortix when you also need to embed the platform, build another host, automate it from a CLI, or expose project/session primitives to customers.

Deployment and operations

QM initializes a separate deployment repository pinned to @yc-software/qm. The operator chooses Fly or AWS, supplies identity and model-provider credentials, publishes the agent-computer image, deploys, and proves the real computer from outside the transcript. QM intentionally does not generate deployment CI. Its Docker target is documented as an evaluation path, not the recommended production topology.

Kortix offers a managed multi-tenant cloud and a self-hosted Docker Compose distribution. The self-hosted stack includes the frontend, API, LLM gateway, Caddy, and the pinned Supabase distribution. Daytona remains outside the box by default, so a persistent public callback domain or tunnel is required. Managed production uses GitOps on EKS, while the web ships separately.

QM gives the operator a cleaner per-organization cloud boundary, at the cost of provisioning more infrastructure. Kortix gives smaller teams a shorter Compose path and a hosted product, at the cost of a broader platform stack. Both still depend on external model billing, and both use external sandbox compute on their recommended paths.

How to deploy and test QM

For a real organization, QM recommends Fly or AWS. Start in a new organization-owned deployment repository. The initializer pins the exact @yc-software/qm package version and writes the provider-specific config, runbook, skill, secret schema, and Slack manifests. Docker exists for a local test drive, but QM does not present it as the production path.

npm exec --yes --package=@yc-software/qm@latest -- \
  qm init . --org <slug> --target <fly-or-aws> --model-provider <provider>
npm install

npm exec qm -- check
npm exec qm -- doctor
npm exec qm -- infra build-image   # AWS
npm exec qm -- plan
npm exec qm -- up --yes
npm exec qm -- check --live
npm exec qm -- conformance
npm exec qm -- outputs --json

• check validates config, computed secret names, tools, skills, and plugins without network access.
• doctor performs read-only checks against the selected cloud, identity, model, and deployment prerequisites.
• plan renders the mutation before deployment. up --yes applies it. AWS builds the Lambda MicroVM image first; Fly publishes its agent-computer image.
• check --live detects drift in the deployed workloads and sandbox pins. conformance compares the static contract with the core’s resolved deployment layer.
• The acceptance test is external — sign in through the real web URL, send one message, receive a real model response, ask the agent to write a fresh UUID into /root/workspace/qm-computer-proof.txt, then verify that UUID through the provider outside the transcript. If Slack is enabled, mention the bot in a test channel and require a real response.
• For source contributors — run npm test, npm run typecheck, npm run lint, and npm --prefix cli run test:all. Postgres and live-provider suites are separate because they require their real dependencies.

Scaling, observability, and performance

• QM scaling — durable Postgres stores, background queues, leader leases, multi-instance-safe state, and one computer per active scope. The admin plane exposes sessions, model requests, errors, cost, egress decisions, and audit data.
• Kortix scaling — provider-balanced sandbox creation, per-account concurrency limits, control-plane-observed sandbox deadlines, idle and orphan reapers, EKS/GitOps for the managed control plane, and one computer per active session. Provider events, boot timelines, gateway request logs, audit events, and compute metering are durable.
• No honest benchmark winner yet — the projects publish different tests and target different lifecycles. QM should be faster on repeated tool use in one warm scope. Kortix should isolate parallel work more cleanly and amortize boot through provider snapshots and resume. Those are architectural expectations, not an apples-to-apples measured result.

Licensing is not a footnote

QM is MIT-licensed. You can modify it, redistribute it, and build a hosted service from it under the MIT terms. Kortix uses the Elastic License 2.0. You can inspect, modify, and self-host the source, but the license restricts providing the software to third parties as a competing hosted or managed service. Some enterprise functionality also requires a license entitlement.

If your goal is to create a commercial hosted fork, QM has the more permissive license. If your goal is to run the system for your own organization, both support that deployment model. Read QM’s license and Kortix’s license before making a product decision.

Can you migrate between them?

There is no drop-in migration because the ownership models differ. A practical QM-to-Kortix migration maps scopes to projects, scope skills and memory to repo files, crons to triggers, keychain entries to connectors or secrets, and active work to sessions. The hard part is deciding which room-local state belongs in version control and which should stay operational data.

A Kortix-to-QM migration maps projects or teams to scopes, imports agents and skills into a deployment layer, converts triggers to crons, and replaces change-request promotion with QM’s scope storage and app-publishing model. That direction loses the automatic branch-per-session review boundary unless you rebuild it as a skill and policy.

When to pick which

They could coexist, but no supported integration exists today. QM could own the conversational scope while Kortix runs project sessions and change requests behind it. That adapter would have to preserve identity, grants, delivery provenance, and idempotency across both systems. Treat it as an integration project, not a configuration flag.

The real conclusion

QM is one of the more serious new open agent architectures because it starts from multiplayer identity instead of adding team features after the fact. Its scope model, harness portability, resident computers, and provenance-aware security are worth studying.

Kortix makes a different bet: the company should be a git repository, agents should work on isolated session branches, and durable changes should pass through review. That gives up some room-local continuity and harness flexibility. In exchange, it makes ownership, embedding, parallel work, rollback, and institutional learning explicit parts of the product.