qm gives teams separate workspaces for AI agents
August 31, 2026

qm connects AI agents to Slack and a web interface. Separate workspaces, permissions and audit trails aim to make shared agent work more controllable for startups.
What this is about
qm is an open-source agent system for teams. Instead of serving one personal assistant, it gives employees and shared rooms separate work environments. Access is available through Slack or a web interface. The project appeared in July 2026 and released version 0.1.5 on August 17, 2026.
The practical difference is not a new language model. qm organizes existing coding harnesses such as Codex, Claude Code, OpenCode or Pi as shared infrastructure. This is relevant for small companies that want to use agents with their own files, services and recurring tasks rather than merely test them.
What qm actually does
According to the project documentation, each person and shared room receives its own scope for memory, files, keychain access, permissions, schedules and a durable sandbox. A central core manages identity, policies, queues and agent runs. PostgreSQL stores sessions and memories, while the work itself runs in separate computers or sandboxes.
Teams can use this setup to search internal notes, email, documents and databases, deploy small internal applications, work on repositories or run scheduled tasks. Skills can be shared selectively. Administrators decide which models and harnesses are allowed. The software is available under the MIT license and is deployed in the organization's own cloud account on Fly.io or AWS.
For risky actions, qm provides three security postures. In strict mode, every effective tool call waits for human approval. The default mode screens external content with a classifier. Dangerous mode removes that screening but, according to the documentation, retains hard denials for certain commands. Actions are intended to be audited.
Why it matters
A personal agent and a team agent have different security problems. Once several people use the same instance, memories, files and credentials must not accidentally cross project boundaries. qm treats this separation as a basic building block rather than an added role list.
Portability also matters: according to the README, a team can use different harnesses and models behind the same core. Changing a model provider therefore does not necessarily require changing the interface, memory structure or permission system. Version 0.1.5 added full-text search across visible conversations, custom model endpoints, administrator-managed HTTP MCP tools, and additional permission and credential checks.
In plain language
Think of qm as an office building. Each person has an office, each project has a meeting room, and administrators decide which key opens which door. The AI agent is not a messenger roaming freely; it works in the room where it was assigned. The building still does not replace house rules or security staff: configuration errors remain possible.
A practical example
A startup with twelve employees operates three product teams. Team A connects one repository and a support mailbox, Team B connects only its own repository, and management creates a shared market-monitoring room. At 8 a.m. each weekday, an agent drafts a report about open bugs and failed CI runs.
A developer then asks the agent to investigate a bug. qm starts the work in her sandbox, uses only credentials approved for that scope, and exposes the steps in the audit trail. If a change is to be published, the organization can require approval in strict mode. Before real deployment, the team should test this process with an unimportant repository, two test accounts and artificial credentials.
Scope and limits
First, qm is young infrastructure. A large GitHub star count is not an independent long-term audit, and version 0.1.5 indicates an early development stage. Second, operations remain demanding: teams must securely configure and update cloud resources, PostgreSQL, identity, Slack access, sandboxes and secrets.
Third, scope isolation cannot prevent harmful decisions inside a correctly authorized scope. Prompt injection, excessive permissions and faulty automation remain real risks. Dangerous mode in particular does not belong in an environment containing real customer data. qm is therefore no substitute for least privilege, approvals, backups, monitoring and regular security reviews.
SEO & GEO keywords
qm, multiplayer agent harness, AI agents for teams, Slack AI agents, team sandbox, agent permissions, self-hosted AI, Codex, Claude Code, OpenCode, MCP, agent security
💡 In plain English
qm is a self-hosted work environment for AI agents in teams. People and projects receive separate files, memories, permissions and sandboxes, accessed through Slack and a web interface.
Key Takeaways
- →qm separates people and shared rooms with dedicated memory, files, permissions and sandboxes.
- →The system supports several harnesses and models, including Codex, Claude Code, OpenCode and Pi.
- →Version 0.1.5 added full-text search, custom model endpoints and administrator-managed HTTP MCP tools.
- →The MIT-licensed software runs in the organization's own cloud account but requires experienced operations.
- →Scope isolation reduces risk but does not replace least privilege, approvals and security reviews.
FAQ
Is qm its own AI model?
No. qm is infrastructure for existing models and agent harnesses such as Codex, Claude Code, OpenCode or Pi.
Where is the data hosted?
The documentation describes deployment in the organization's own cloud account on Fly.io or AWS. Actual security depends on the specific configuration.
Is qm suitable for sensitive customer data?
Not without a dedicated risk assessment and hardening. The project is young; broad permissions and Dangerous mode increase risk in particular.
What does qm cost?
The source code is available under the MIT license. Cloud resources, models, Slack integration and ongoing operations still create costs.