QM、職場エージェントを「共有アシスタント」ではなくスコープ付き作業空間へ

QMは、会社用agentを「個人アシスタントを全社に広げたもの」として扱わない。READMEで強調されているのは、各社員に独立したworkspaceを与えつつ、Slackチャンネルやプロジェクトではagentと共同作業できるroomを作る設計だ。ユーザーごと、roomごとにmemory、files、keychain view、permissions、crons、web apps、durable sandboxが分かれる。

ここで目立つのはモデル性能ではなく運用境界である。QMはPi、OpenCode、Codex、Claude Codeなど複数のharnessとmodelを同じcore上で動かせるとしている。特定vendorに縛られず、社内文書、メール、データベース、repositoryをまたいで検索し、テスト実行やPR作成、CI確認まで進めるagentを想定している。

構成もその考え方に沿う。Postgresがsessions、memory、queueを保持し、TypeScriptのheadless coreがidentity、policy、scheduler、agent loopを扱う。命令実行はスコープごとのsandboxで行われ、インストール済みツールや作業ファイルはその人またはroomに残る。Slack、web UI、admin panel、public portalはcore HTTP API上のpluginとして置かれる。

HNの議論では、「multiplayer」という言葉が実体を持つのかという疑問も出た。一方で、会社全体で使うassistantではper-person scopeとshared roomの分離が現実的な答えだという見方もあった。特にagentがcredentialsを持って実作業を行うなら、誰の権限で何を実行したのかを追える設計は避けて通れない。

QMの焦点は、agentをどう賢くするかだけではない。memoryとpermissionをどこで分け、background workを誰の責任で残し、危険なcommandをどう制御するか。職場でagentを常用する段階では、この地味な境界設計がそのまま製品価値になる。