The Computer That Belongs to a Conversation
QM's scope model does not end when the core has assembled a turn. It must also decide where the work runs, what survives the turn, and what is lost when a provider or process disappears. This chapter follows a scope-owned computer through its lifecycle, then separates four kinds of continuity—workspace files, memory, session history, and tape—so the reader can choose the right place for a fact, a process, or a durable deliverable.
A sandbox has an owner, a route, and a lifecycle
A QM sandbox is not simply “the machine the model uses.” It is an independently recorded resource with an owning scope, a provider, a backing identity, and a lifecycle state. That ownership matters because a computer can contain working files, logged-in services, running processes, and capability tokens. If QM treated the machine as an anonymous global pool, the scope boundary established during context resolution would disappear at execution time.
Creating a sandbox provisions a blank resource. It does not copy the scope's files, and it does not silently change which computer the scope uses by default. Selecting a default is a separate routing operation. This separation prevents a surprising side effect: an administrator or an agent can create capacity for a scope without moving future work onto it before someone has deliberately selected it.
The distinction becomes practical when a scope has more than one possible target. An execution can use the stored default, or it can name an authorized sandbox explicitly. The router resolves that request to a provider and keeps the resource identity attached to the resulting handle. If the configured backend is unavailable, QM refuses to substitute an unrelated computer. That refusal is important: a substitute machine might look operationally convenient while carrying the wrong files, credentials, or recovery history.
A running process also keeps its original target. Changing the scope's default does not move a process that has already started. This preserves a simple ownership rule across time: the default controls where future work is routed; it does not rewrite the meaning of work already in flight. Status, output, signals, and watches continue to refer to the resource on which the process began.
The lifecycle has several distinct transitions. A resource can be created, selected as a route, used for foreground or background work, inspected or restarted, and eventually retired. Retirement is not another way to provision or restore a machine. QM requires the scope's default to be cleared and its jobs to be stopped first, then deletes the working state for providers that support direct scope deletion. Durable results should therefore be published to a separate destination before retirement.
The available execution modes make the same trade-off visible. A scoped computer is the normal place for work whose files and state must remain available to later turns. A scratch computer is blank and invocation-only: it is useful for heavy, self-contained work that needs no workspace files, logins, or credentials, and it disappears after the turn. An owner-auth environment can provide the owner's credentials for a shared automation task while remaining invocation-only and separate from the shared room workspace. These are not three names for the same machine. They are three different answers to the question of what should persist and whose authority the process may use.
Imagine a team asking QM to transform a large public dataset. A scratch computer is appropriate if the input can be fetched again, no private files are needed, and the result is only a calculation. The same job belongs on the scoped computer if it must read the conversation's working files or leave checkpoints for a later turn. Owner-auth execution is a different case again: it may be justified when a shared automation needs the owner's login, but retaining that credential on a shared durable computer would make the authority outlive the invocation that needed it. The choice is therefore about the boundary of the work, not about which machine is fastest.
A route can also fail in ways that should remain visible. If a scope has no default, an execution that does not name a target cannot simply create one behind the user's back. If a selected provider lacks an operation, the router reports an unsupported capability instead of silently using a different backend. If a resource is being retired, new execution remains blocked while cleanup is retried or completed. These refusals make lifecycle state part of the interface: “not available here” is safer than an apparently successful action on the wrong computer.
Provider recovery adds another boundary. QM can record a checkpoint or use a provider's native pause and recovery behavior, but the guarantee belongs to that provider. A home checkpoint may preserve ordinary files while not preserving running processes, RAM, or system-wide package installations. Checkpoints can expire, and a capture taken while a process is writing is not an application-consistent database backup. Recovery is therefore best-effort working-state preservation, not an indefinite archive.
The transition matters most when a machine fails between two turns. A successful status report does not prove that the latest write has reached a durable checkpoint, and a checkpoint reference does not renew itself merely because someone later uses it. A failed or expired restore should stop with an explicit recovery error rather than replacing the home with an empty directory or silently selecting an older copy. The operator may then decide whether to retry, recover from a published artifact, or accept that the working state must be reconstructed.
This is also why “durable” should be read as a bounded promise. It means the scope and provider will attempt to retain working state according to their configured lifecycle; it does not mean every process, package, credential file, or in-memory transaction survives every restart. The boundary is useful precisely because it tells the team what to publish elsewhere before a machine becomes idle, expires, or is retired.
That is why important outputs need an independent durability path. Code can be committed to git; deliverables can be published to Files; a database can use the deployment's supported durable store. A recovered computer may restore the working environment well enough to continue, but it should not be the only copy of something the organization cannot recreate.
The diagram separates two paths that are often confused. A checkpoint returns the working computer to a usable state when provider conditions permit. Publication moves an important result to a destination whose purpose is to outlive that computer. The first is recovery; the second is durable delivery.
Continuity is divided among memory, files, sessions, and tape
The computer is only one continuity mechanism. QM's built-in memory is a small, scope-owned notebook for durable facts. It is line-oriented, deduplicated, and serialized per scope. The agent-facing contract treats it as the one place to read or change durable memory, not as a file that can be edited incidentally through shell commands. That design keeps a remembered preference or project identifier distinct from the working data to which it points.
The distinction is also about cost. Memory is loaded into future context, so every line competes for the model's attention. A queue, log, list of item statuses, or large research corpus belongs in workspace files or another data store. Memory can hold a short pointer saying where that state lives and what it contains. A fact such as “the team prefers weekly status summaries” is a reasonable notebook entry; the full status history is not.
Memory can be extended through scope-aware providers. A deployment may route recall, explicit writes, and automatic post-turn capture differently for different scopes. An external provider receives the acting user and can be configured as read-only. External routes may fail open so a provider outage does not block recall, but that behavior means continuity is not guaranteed by the route itself. The provider's availability, retention, and privacy remain deployment concerns. The scope still determines which memory may be read and written; routing changes storage location, not the authority model.
Workspace files serve a different purpose. They hold the changing material of a task: source checkouts, notes, generated artifacts, queues, and intermediate results. They can be read by later work on the same scoped computer and can be shared through explicit file grants. They are not automatically elevated into memory simply because the agent wrote them, and a pointer stored in memory does not grant another conversation permission to open the original path.
Session history is a third layer. A session records the conversation and its tool activity in durable entries, with scope labels and leases that coordinate concurrent work. It answers questions such as what happened in this conversation, which turn produced a result, or where an interrupted operation stopped. It is not the same as the notebook: history preserves the record, while memory preserves selected facts for future use.
The tape projection is the representation a harness can use to continue a conversation. QM can mirror entries for a harness without native tape support, fold context summaries, and repair an interrupted tool call with an explicit result rather than leaving an unfinished exchange. This makes compaction a projection operation. Older material may leave the active model window, but its scope labels and audience rules do not become irrelevant merely because the context was summarized.
Audience filtering is what keeps durable history from becoming universal history. When a session is viewed by several participants, entries whose scope labels are not entitled to the whole audience are removed from the model-facing projection. A hidden tool result is replaced with an interruption marker rather than being passed through as if its original contents were safe. The session can remain durable while the current audience receives only the portion they are entitled to see.
Session leases add a concurrency boundary to this projection. A turn or compaction operation must hold the appropriate lease before changing the record, and a competing operation may be asked to wait or may receive a busy response. This is not merely a performance detail. Without a lease, one turn could append a result while another compacts or retries the same conversation, producing an ambiguous order or duplicating an effect. The durable session is therefore both a history and a coordination point.
Tape mirrors make the same record usable across different harness capabilities, but they do not erase the distinction between canonical history and model context. A harness may receive a folded projection with a context summary while the session store retains the entries that produced it. If a tool call was interrupted, the projection can make that interruption explicit rather than inventing a successful result. If an audience changes, the projection can be filtered again. Continuity is thus reconstructed under current scope and audience rules, not copied blindly from the last prompt.
A realistic work episode therefore crosses several boundaries. An agent might use a scoped sandbox to inspect source material, save a draft in the workspace, publish the final artifact to Files, record one durable preference in memory, and leave the full conversation in session history. If the sandbox later expires, the published artifact and the selected memory fact can still be useful. If the actor opens the conversation from a different audience, the session projection may narrow even though the underlying record remains. If an external memory provider is unavailable, the working files do not become memory by accident.
These distinctions give the scope model a concrete lifecycle. The scope owns the work, the sandbox executes it, memory keeps a compact continuity signal, files hold working state, sessions preserve what happened, and tape projects only what the current harness and audience may use. No single layer is asked to provide every kind of durability. That separation lets a reader diagnose a failure more accurately: a lost process is not necessarily a lost artifact, a missing memory provider is not necessarily a missing file, and a filtered transcript is not evidence that the underlying session was deleted.