Keep longer work safe and recoverable

Outcome

Decide whether a follow-up should change the current run or wait until it finishes. Before stepping away, record the task, approved inputs, owner, permitted actions, time limit, stopping condition, and checkpoint needed to resume.

Some environments may support approved remote review, scheduled tasks, or unattended execution; others may not. Verify what is actually available before planning around it. Optional overnight work begins only after a person approves that specific plan and its resource limits.

When to use it

Use this pattern for a clearly defined analysis, non-destructive test run, local draft, evidence review, or other work that may span an interruption. Begin only when the owner, approved sources, expected result, and review boundary are known.

Prefer an ordinary manual checkpoint when the task needs frequent judgment, relies on unavailable connections, or could affect another person. Consider an approved scheduled or overnight run only when the actual environment supports it and the job can fail safely.

Do not assume a task follows you to another device, a connection stays available, or a background process keeps working. Verify the execution surface and recovery path independently.

Queue vs steer

While a run is underway, choose whether your next message should change the current work or wait.

• Steer adds a correction or direction to the current run. For example: “Use this corrected workbook instead.”
• Queue saves a follow-up for the next run. For example: “When you finish, draft the email for my review.”

In the desktop app, choose the default under Settings → General → Follow-up behavior. That setting also shows the shortcut for using the other behavior for one message. Queued messages appear above the composer, where you can edit, reorder, or remove them.

These controls do not enable tools or expand access. Sending or publishing still needs your approval. See the official Queue and Steer guidance.

Operating pattern

If local work needs your Mac to stay awake, you can turn on Prevent sleep while running in settings, where available. Keep the Mac plugged in and connected to any network the task needs. Save a checkpoint and a clear stop condition before stepping away, then review the result. See the long-running work guide.

Use one existing work owner and one bounded execution plan:

1. Name the job. Record the desired result, intended audience, existing project, and human owner.
2. Verify the starting state. Read the approved source, current checkpoint, connected-tool availability, and exact work authorization.
3. Define the boundaries. List permitted files, tools, resource limits, review gates, and actions that remain prohibited.
4. Preserve recovery. Write a concise restart card before the first meaningful step and update it at material milestones.
5. Approve optional unattended work. Present the exact objective, duration, permitted actions, stop condition, and expected report. Start only after explicit approval.
6. Check real progress. Compare the current output or run record with the previous checkpoint; an active-looking interface is not evidence.
7. Stop cleanly. Finish on verified completion, expiration, unavailable access, uncertain ownership, an approval boundary, or user request.

Never create an additional controller to compensate for an unverified owner. A separately approved overnight plan may continue existing work only within its stated scope; it does not inherit permission to send, publish, deploy, or alter shared systems.

Record what a heartbeat actually did when reviewing scheduled work. A receipt should show progress and remaining approval gates, not just that a task ran.

Copyable implementation

# Extended-work plan

Objective: [one bounded operation]
Existing project and owner: [verified workstream]
Approved sources: [named evidence]
Execution mode: manual checkpoint | approved scheduled run | approved overnight plan
Available runtime: [verified environment, not an assumption]
Time and resource limits: [start, expiry, allowed resources]
Permitted actions: [exact internal read or preparation scope]
Prohibited actions: [messages, live edits, access, publishing, deployment]

Before:
- Verify the current source, existing owner, and last known checkpoint.
- Save one restart instruction and the expected acceptance check.
- Confirm the exact approval and an enforceable stopping condition.

During:
- Record what changed, what remains, and any failed check.
- Stop if access, ownership, time, or permission becomes uncertain.
- Keep all external actions pending separate human approval.

After:
- Validate the exact output against the named acceptance check.
- Report completed, blocked, or review-ready state with evidence.
- Preserve the recovery checkpoint and outstanding approvals.

An example plan is not itself approval, a running schedule, a connected account, or proof of a completed task.

Example

For example, a project lead needs a comparison of three approved public research documents before the next morning. The existing research task already contains the objective, source list, quality checks, and a partially completed outline.

The lead asks for an overnight plan covering only those documents, one local draft, a fixed end time, and a short morning summary. The plan prohibits outbound messages, changes to shared documents, new account connections, and unrelated browsing. Work begins only after the lead approves that exact scope.

The next morning, the result identifies which sources were actually read, which sections remain uncertain, and whether the draft passed its checks. If a source became unavailable overnight, the task remains blocked with a restart card rather than pretending the analysis is complete.

Approval boundary

Longer runtime never expands the authority granted to the original task. Sending, posting, publishing, deploying, editing shared artifacts, changing permissions, spending money, and destructive operations each require their own explicit approval.

Do not bypass device management, security controls, organizational policy, or account restrictions. If the available environment cannot enforce the approved time, scope, or stopping condition, do not start unattended work.

Validation

Verify separate claims rather than replacing evidence with a reassuring status light:

• Ownership: the existing project and accountable person are confirmed.
• Sources: each permitted input is current and within scope.
• Availability: the approved execution environment actually supports the planned run.
• Approval: the exact objective, resources, and prohibited actions were authorized.
• Progress: a fresh receipt shows what changed, not merely that a task exists.
• Recovery: a new task can continue from the latest checkpoint.
• Stop condition: expiration, uncertainty, completion, or user interruption halts the run.
• Output quality: the final artifact passes its named acceptance checks.

If any claim is missing, label the result blocked, partial, or review-ready as appropriate.

Failure modes

Common failures include treating a planned run as an active one, assuming another account or device has the same capabilities, confusing a visible task with verified progress, and relying on yesterday's approval for a materially different job.

Other failures are starting a second controller, losing the existing owner, scanning unrelated sources, overriding normal device safeguards, silently changing shared work, or calling an unfinished draft complete. A process that cannot explain its evidence and stopping condition is not ready to continue unattended.

Prefer a short checkpoint and a clear human decision over an elaborate workaround. Reliable continuity comes from ownership, evidence, bounded permission, and recovery.