Giving the agent a clock shipped four trust models under one word
Claude's /loop, Desktop tasks, Cowork tasks and cloud routines share a timer, not a permission boundary. Name the runner, state, authority and missed-run policy before granting a schedule.
Kurt Cagle's August 16 essay gets the consequence right: giving an agent a clock creates standing authority. It can write, notify or mutate state while nobody is looking. Where I disagree is the noun. Claude had not acquired a scheduler. By August 17, “scheduled Claude” could mean four user-facing surfaces with four materially different trust boundaries.
The short answer: /loop borrows the life and permissions of a live session. A Desktop task borrows an awake machine and a permission mode chosen for that task. A Cowork scheduled task runs remotely against saved files and connectors. A Claude Code cloud routine runs autonomously against selected repositories, environments and connectors, with no approval prompt during the run. The timer is the least important thing they share.
The feature was older than the headline
Anthropic's own release notes date scheduled Cowork tasks to February 25 and remote Cowork on web and mobile to July 7. Cagle's “just got a scheduler” framing made a useful governance argument, but it compressed a layered product history into a launch moment that did not exist.
The layers mattered. The /loop documentation described a session-scoped job: it runs on your machine, needs the session, and inherits that session's tools and permissions. Desktop scheduled tasks were durable but local: they could see a chosen working folder, had per-task permission modes, and only fired while the app and machine were awake. The documented missed-run policy kept one recent catch-up and discarded older misses.
Cowork scheduled tasks moved execution to a remote Cowork session, so the laptop could close; their natural state was the files saved to Claude and the connectors attached to the task. Cloud routines were a developer automation surface: schedule, API or GitHub event in; a fresh cloud session with chosen repositories, environment and connectors out. That surface explicitly ran without approval prompts.
A September 10 recheck shows Anthropic now grouping Claude Code into three choices — Cloud, Desktop and /loop — while Cowork keeps its own scheduled-task documentation. That taxonomy convergence is not evidence that the August distinctions were imaginary. It is evidence that feature names are a bad place to store a control decision.
A schedule does not carry consent forward
Cagle's strongest test is that autonomy should be delegated, revocable and auditable. I would make the delegation more mechanical. Before a recurring job earns a clock, its record should name five things: runner, trigger, working state, authority boundary and missed-run policy.
“Run this every night” answers only the trigger. It says nothing about whether the job sees a dirty local working tree or a fresh clone, whether an asleep laptop means skip or catch-up, whether an API token can start it, or whether a write pauses for approval. Those are not implementation details. They decide both reliability and blast radius.
The sharpest boundary is the cloud routine. When there is no approval prompt, the repositories, network policy, environment variables and connectors are the approval. Include a connector with write tools and the routine can use those writes. The safe unit is therefore not “Claude may use Slack.” It is “this routine may read these channels and post only to that destination, for this purpose, until this review date.” If the connector cannot express that grant, the prompt cannot repair it.
That is the same control lesson as approving agent actions against independent policy: prose from the agent is not a boundary. The boundary has to survive a persuasive mistake.
A timer multiplies the gate you already shipped
The adjacent August 16 short came from a different incident, but belongs here for one reason. An agent reached a gym cancellation endpoint that did not check ownership. The clock did not create that authorization hole; recurring, unattended execution would only give the hole more chances to matter. Endpoint policy remains the gate.
This is why I treat an unattended loop as a release artifact, not as a saved prompt. Version its instruction. Bound its credentials. Give it fixtures, a budget, a stop condition and a receipt. Then test the failure path with the human absent, because absence is the feature being purchased.
Three empty outputs can mean three different failures
Consider three missed nightly runs as an illustration. The output is absent in each case, but that tells you almost nothing about where execution stopped.
In the first case, there is no invocation record. In the second, the runner starts but cannot authenticate. In the third, it resolves its inputs and launches a child process, which stops before producing an accepted result.
The empty calendar cells look identical. The repairs are not. One needs better availability evidence, one needs identity health, and one needs orchestration state that distinguishes “started” from “finished.” A binary scheduled/not-scheduled dashboard hides all three.
My operating rule now: every scheduled agent writes a phase receipt — triggered, authorized, inputs resolved, work completed, output accepted — plus an explicit reason wherever the chain stops. A clock proves only that time passed. It does not prove the runner existed, the credential worked, or the deliverable landed.
Do not approve “a scheduled agent”; approve a named runner, state, authority, miss policy and receipt — because the clock is only the trigger, never the trust model.
