What QM Makes Possible—and What It Still Cannot Guarantee

QM is best judged not as a collection of agent features, but as an answer to one organizational problem: how can people share useful agent work without sharing every context, credential, process, and hidden assumption? This final synthesis reconnects scope, context, state, security, collaboration, automation, and deployment to answer that question. It also separates what the core can enforce from what depends on an operator, a provider, or the model's discretion, so the resulting judgment is useful rather than promotional.

Scope is the organizing answer

QM's strongest architectural choice is to make scope the unit that coordinates agency. A model can generate a reply, but it does not own the conversation. A surface can receive a message, but it does not determine the full authority of the turn. A sandbox can run a process, but it does not decide who may use the process or receive its output. Scope connects those decisions.

A person or room resolves to a scope. The core adds organization and, where appropriate, team context as bounded layers. The current conversation provides a writable home. The actor and full audience influence grants, sharing, egress, and delivery. The turn-local view selects memory, files, skills, and other resources for the present request. A scoped computer executes the work without becoming the identity of the agent. Session and tape projections preserve a conversation under audience rules. Crons and background processes carry the scope into time. Deployment configuration determines which providers, secrets, tools, and skills make those capabilities real.

Seen together, these are not independent features. They are different expressions of one relationship: who owns the work, which context may enter it, what may change, who may receive the effect, and what remains afterward. That is why scope is stronger as an organizing unit than a model, interface, or machine. Those components can change while the ownership questions remain.

Consider an internal team using QM to prepare a product launch. A product manager's private notes remain personal. The project channel has its own writable workspace and audience. A deliberately shared research document can enter one live turn as a read-only source. The agent runs in the channel's scoped computer, writes a draft there, and publishes a final artifact to a durable destination. A short preference may go into the relevant memory notebook; the conversation and tool activity remain in session history; a later audience receives only the projection they are entitled to see.

The scenario works because each transition has a boundary. Personal access does not automatically become channel access. A file grant does not become a credential grant. A visible prompt fragment does not become permanent memory. A process does not become a new owner when it runs in the background. A harness change does not redefine the actor. A deployment change does not turn a static validation result into runtime enforcement.

That coherence is the real product value. QM makes it possible to ask precise questions about agent work that otherwise remain implicit: Which scope is writable? Which resources were carried from elsewhere? Which audience will receive the reply? Which token authorizes the external request? Which state survives a sandbox failure? Which operator chose the provider and retention policy? When the answers are visible, collaboration can be governed as a system rather than negotiated anew in every prompt.

The scope model is not a proof of isolation. Read-only layers do not ensure that a model will never repeat a private fact. Audience checks do not repair a mistaken grant. A durable session can preserve information longer than a user expects. But the model gives those risks a location. A failure can be discussed as a scope-resolution problem, a disclosure problem, a provider-recovery problem, or an operator-configuration problem instead of being hidden inside the vague claim that “the agent has access.”

The design trades control against convenience

QM does not eliminate trade-offs; it makes them configurable and observable. The first is isolation versus useful sharing.