From One Turn to an Operating System for Work
QM's scope model becomes more demanding when work continues after a person stops watching the conversation or when an operator changes the surrounding deployment. This chapter follows a scoped task through scheduled and background execution, then examines the deployment directory and governed skill layer as operator-owned extensions of the same boundaries. The reader should be able to tell what persists after a turn, what authority a trigger carries, and which guarantees belong to QM versus the deployment and its providers.
Automation carries scope into time
A scheduled task is not simply a message sent later. It is a standing instruction with an owner scope, a destination, a schedule, and a set of conditions under which a future turn may run. QM supports crons, watches, webhooks, background processes, and project-oriented loops. Each extends a scope into time, so the important question is not only “what should happen?” but also “under whose authority, in which audience, and with what continuity?”
A cron fire runs in a fresh thread. Its continuity comes from two explicit places: the stored task that every fire receives and durable workspace state such as notes, queues, or checkpoints. It does not receive a hidden conversational memory of the previous fire. That separation prevents a task from accumulating an unbounded private conversation merely because it runs repeatedly, while still allowing the task to maintain state deliberately in files or in the durable fire log.
The scheduler records each fire with a fire key, thread reference, timing, status, and, when relevant, a reply or note. Idempotency makes the fire key meaningful: a retry should not silently create a second effect for the same scheduled slot. Leader leases coordinate which scheduler instance claims the work. When too many tasks become due together, bounded fan-out keeps one tick from creating an uncontrolled burst. These are reliability mechanisms, but they are also authority mechanisms. A duplicate fire can send a duplicate message, mutate a resource twice, or spend a credential twice.
A busy session does not have to be treated as a failure. QM can defer a scheduled fire and record that it will be retried later. Stranded running fires are swept and closed, and old fire records are eventually collected. The result is a visible state machine rather than an invisible background loop: pending work becomes claimed, running, completed, deferred, refused, or failed. A team can investigate what happened without inferring it from a process that may already have disappeared.
The trigger carries more than the stored task. It carries an owner scope and a destination, and may carry current membership, recipient consent, and unattended grants into the turn request. This matters when the destination is a channel or group. The people who were allowed to receive a result when the cron was created may not be the people who are entitled to receive it when it fires. The authorization decision must therefore be resolved at execution time, not frozen at creation.
Recipient consent and unattended grants express different kinds of authority. Consent answers whether the people who will receive recurring work have agreed to that mode of delivery. An unattended grant supplies a bounded permission for a trigger to do something without a person approving every individual turn.