QM's Core Idea: Make Scope the Unit of Agency
QM is a multiplayer agent harness for work, available through Slack and the web. This opening examines the problem its architecture is trying to solve: how can an organization let many people work with agents without turning a personal assistant, a room, or a cloud computer into one shared and poorly governed account? The answer is QM's use of scope as the unit of agency. Understanding that choice gives the reader a practical model for judging how QM handles context, collaboration, durability, and control.
The organizational problem: one assistant is not one workplace
A personal agent can often assume a simple relationship. One person asks for help; the agent uses that person's files, credentials, preferences, and computer; the result comes back to the same person. The arrangement becomes different as soon as the agent works for a startup or another organization. A direct message, a project channel, and an administrator's task are not merely different screens. They have different participants, different histories, different files, and different authority.
If those contexts share one workspace, the practical failures appear quickly. A person may see another person's working files. A room may inherit credentials that belong to an individual. A useful memory from one project may surface in another conversation. A background task may continue with an audience that no longer matches the people who created it. Even a harmless command can become consequential when the agent is acting for a group rather than for one owner.
QM's design starts from this distinction. The repository describes it as a harness for multiplayer work: people get their own isolated workspaces, while people and agents can still collaborate in channels, group messages, and projects. A scope is the boundary around that work. It can represent a person, a channel, a team, a group conversation, or an organization. The point is not to create five labels for the same thing. The point is to give each kind of relationship somewhere to own state and authority.
Consider a product team using one agent in three settings. In a private conversation, a product manager may want help organizing notes that belong to them. In a project channel, the team may ask for a plan built from files intentionally shared with that room. An administrator may later inspect organization policy or audit activity. The model and interface could look similar in all three cases, but the legitimate context is different. A scope-centered system makes that difference a first-class input instead of expecting a prompt to explain it perfectly every time.
This also prevents a misleading idea about collaboration: sharing does not have to mean copying an entire workspace into a larger room. The useful unit can be one file, one published app, one memory source, or one read-only skill. The rest of the private context remains outside the turn. That selective boundary is what lets QM treat collaboration as a governed relationship rather than as the disappearance of privacy.
Scope makes agency local
In QM, a scope can carry memory, files, a keychain view, permissions, scheduled work, web applications, and a durable sandbox. That list matters because agency is not just the ability to generate text. An agent becomes consequential when it can read a file, use a login, run a process, remember a preference, publish an application, or act later without a person watching the screen. Putting these resources under a scope makes the question “whose agent is this?” more precise: which context owns the work, who is entitled to it, and what may cross into the current turn?
This also changes how to think about isolation. Isolation is not simply a container boundary around a process. It is a relationship among the actor, the conversation, the audience, the writable workspace, and the resources that the core makes available. A channel can have its own working state without becoming a place where every participant can read every personal resource. An organization can provide shared policy and tools without making the organization's entire memory writable from every room.
The same model supports collaboration. QM does not require all useful work to remain private. It provides grants and audience checks so a file, skill, memory source, or published application can be shared deliberately. In an open-sharing posture, selected personal resources may enter a live internal conversation as read-only, with their source scopes labelled and cross-context reads audited. A session can also be projected into a separate share with an explicitly chosen audience. Sharing is therefore an operation on a scoped resource, not an accidental side effect of placing several people in one chat.
That distinction is central to the rest of this series. A scope is not a synonym for “tenant,” and it is not merely a directory on disk. It is a unit that helps QM decide where context comes from, where state is written, which capabilities can be issued, how an action is delivered, and which events should be attributable. The mechanisms differ—memory, files, credentials, sessions, and sandboxes have different lifecycles—but they are interpreted through the same question of scope.
A map of the system
QM's core is headless: it sits between the surfaces where people interact and the agent loop that drives a model and harness. Slack and the web are ways to receive a request and deliver a result, not the final authority on what the request may do. The core resolves identity and policy, assembles context, schedules work, and coordinates the resources attached to the current scope.
The agent loop is replaceable. The repository names Pi, OpenCode, Codex, and Claude Code as possible harnesses that can drive the same core. This does not mean every harness has identical capabilities; the runtime still has to approve a compatible harness and model. It means that changing the driver should not silently change the underlying scope contract. The decision about who may read a file or use a credential belongs to the core, not to whichever model adapter happens to be active.
The computer is similarly treated as a resource of the scope rather than as the agent's identity. A scope may route work to a provider-backed sandbox, retain working state within that provider's recovery limits, and run background processes. The important outputs can be published to more durable destinations such as Files or git. This is a more honest model than pretending that every cloud machine is an eternal personal computer: compute has a lifecycle, while durable work needs its own storage path.
This separation gives an operator room to change infrastructure without silently changing ownership. The harness can change while the core still resolves the same actor and audience. A resource implementation can evolve while the core continues to interpret who may use it and where its results belong. The interfaces create portability, but the scope remains the place where the relationships are interpreted.
It also clarifies why QM contains both interactive and background capabilities. A person may start work in a conversation, leave work running, and receive a later update. That continuity is useful only if the activity and its destination remain attributable to the originating scope. The details belong to later chapters; the opening principle is that time does not erase ownership.
The map is deliberately compact. “Scoped resources” includes memory, files, credentials, and sandboxes, but those resources do not become interchangeable. “Sharing and audit” crosses the diagram because it affects both what the core assembles and how the resulting action is recorded. The next question is how QM turns this map into a concrete view for one request.
The tension QM cannot wish away
A scope-centered design improves the shape of the problem; it does not remove the problem. QM's own security policy says that the agent and the software running in its sandbox are not trusted to make authorization decisions. Core is intended to enforce identity, scope, grants, delivery, and deterministic effect gates around them. That is a strong architectural direction, but it is not a formal proof that the model will never disclose something it can see.
The distinction matters especially when collaboration is enabled. Authorization can make a personal file available to a shared turn, while the model still decides what to mention in its reply. Content screening can classify external text as suspicious, while screening remains heuristic and incomplete. Command policy can require approval for a destructive-looking shell command, while command policy is explicitly a speed bump rather than a sandbox boundary. Credentials can be kept out of the model's direct view, while a process using a credential can still expose it.
There are operational limits as well. Durable sessions require a durable store; sandbox recovery depends on the provider and can expire; administrators are privileged readers; and bearer links can be forwarded. QM is open about these boundaries because a system that records actions is not the same as a system that prevents every bad action. The repository calls the software early and experimental, not a hardened public or multi-tenant service.
That qualification does not make the architecture unimportant. It identifies what the architecture is for. QM makes the boundaries explicit enough to govern: a scope can own work, a turn can receive a bounded view, a resource can be shared with an audience, a capability can carry an actor and an expiry, and an action can leave an audit trail. Those controls give operators and teams something to configure and investigate instead of leaving authority implicit in a prompt or a process environment.
The value becomes clearest when legitimate needs pull in different directions. A team may want one shared source of truth while an individual needs private notes. A long-running task may need access to a service while the organization still wants the action attributable. An administrator may need oversight without becoming an invisible participant in every ordinary conversation. QM does not solve these tensions by declaring one universal setting. It separates the levers: scope establishes ownership, grants mediate selected sharing, posture sets screening and approval friction, and deployment configuration places responsibility with the operator. Because those levers remain distinct, their limits can also be examined distinctly.
The practical judgment supported by this series is therefore narrower and more useful than “is QM safe?” The questions are: which context does this turn belong to, what state will survive it, which controls govern its actions, who can receive its output, and which risks remain with the model, the provider, or the operator? To answer them, the next step is to follow a single request as QM resolves a conversation and its participants into a turn-local view.