Skip to content

Cron / Scheduling#

1. What it is#

Cron/scheduling denotes tools that let the model (or the user, via the model) arrange for a prompt, recipe, or loop iteration to run at a future time or on a recurring cadence, without a human re-invoking the harness. It spans three distinct operations that implementations handle differently:

  • Recurring/one-shot task scheduling — register a prompt to fire on a cron-style schedule (or once, at a future time), independent of whether any session is currently open.
  • Remote/cloud-triggered execution — hand scheduling off to a hosted service that wakes the harness (or a fresh session) rather than the local process staying resident.
  • Self-paced loop timing — not user-facing scheduling at all, but the model choosing when its own next iteration of an already-running loop should resume, within a bounded window.

This sits apart from the rest of a coding agent's toolset: every other common capability operates within a single turn or session. Scheduling is the one capability whose entire purpose is to outlive the current session and act on the passage of wall-clock time, which raises questions about which architectural layer should own it before it's ever a question of tool naming or parameters.

2. Adoption and mechanism#

This is a thin, sparsely-adopted capability: most harnesses are session-interactive by design (IDE extensions, TUI agents) and have no "the harness itself stays running between invocations" execution model that a cron primitive would hook into. The implementations that do exist are both CLI agents with a persistent local process or an accompanying cloud service, which is plausibly a precondition for this capability rather than a coincidence.

The two known implementation shapes diverge more than a typical thin capability, because they solve related but distinct problems:

  • Granularity of the API surface. One approach splits scheduling into several separate tools by responsibility — local session-scoped create/delete/list, a cloud-triggered remote path, and a loop self-pacing primitive — with materially different execution substrates behind each. Another collapses everything into one tool with an operation-selecting sub-command argument (list/create/run_now/pause/unpause/delete/kill/inspect/sessions/session_content) over standard cron expressions (including a 6-field, seconds-resolution superset of POSIX cron).
  • Scope of what's scheduled. One model is explicitly session-scoped: a scheduled task is tied to the session that created it and is restored when that session resumes, but is not a durable, globally-addressable job independent of any session. The other manages a saved, replayable task definition as a first-class scheduled entity with its own lifecycle (pause/unpause/kill/inspect, plus inspecting runs a schedule has already produced) — a more "cron daemon"-like model than per-session restoration.
  • Remote vs. local execution substrate. One implementation has a cloud-hosted scheduling path — a materially different trust and infrastructure boundary from local, session-tied scheduling — tied to a vendor's own hosted product rather than being available under any model backend.
  • Self-paced loop timing is a different kind of primitive entirely. It isn't user- or model-initiated scheduling of new work; it's a mechanism called at the end of each loop iteration to pick when the next iteration of that same loop should resume (typically a window of a minute to an hour). It has no equivalent in the other implementation and arguably isn't "cron" in the conventional sense at all — it's closer to a variable-interval timer controlling the cadence of an already-running control loop (see §6 for why this distinction matters for PluggableHarness Agent).

3. Permission, sandbox & safety#

Scheduling tools are typically treated as requiring no explicit per-call approval beyond whatever the harness's default read/write tiering already applies — scheduling isn't singled out as an exception in either implementation observed. Neither treats scheduling as a category requiring the elevated scrutiny it arguably deserves given what it does: a scheduled task is code the model wrote that will execute unattended, later, without the user present to review it in the moment — a materially different risk shape from an ordinary tool call, one that none of the common approval models (per-call prompt, category auto-approve, safe-to-run boolean, smart-approval classifier, config-only, staged-apply-gate) are designed around.

Sandboxing specific to the scheduling tools themselves is not a documented concern in either implementation. What's actually sandboxed (or not) is whatever the scheduled task eventually executes — ordinary prompt re-invocation through the harness's regular tool-calling and permission pipeline, so a scheduled task inherits the same OS-level sandboxing (or lack thereof) that governs the harness's normal execution. The safety-relevant property specific to scheduling itself is closer to a supply-chain concern than an execution-sandboxing one: a task created once can fire many times unattended, meaning any approval the user granted at creation time transitively covers every future firing, not just the one being approved.

A cloud-triggered execution path adds a distinct trust boundary local-only scheduling doesn't have: the scheduled prompt executes against hosted infrastructure, not the user's own machine, which changes the blast-radius calculus (no local filesystem/network access by default, but also no local sandbox controls apply).

4. Convergent patterns & divergences#

With only two known implementations, convergence is thin, but a few things hold across both: neither gates scheduling tools behind extra permission relative to the harness's normal default, both distinguish "schedule new work" from "list/inspect what's scheduled" as separate operations, and both are CLI-native harnesses with a persistent-process or hosted-service model that IDE extensions and cloud-sandboxed autonomous agents simply don't have a slot for.

Where they diverge is architecturally telling: one fragments scheduling into several tools spanning three different execution substrates (local session state, a cloud service, and a loop-internal timer), while the other treats it as one coherent internal subsystem exposed as one tool with many sub-operations. This is too sparse a capability for a clear convention to have emerged. The most notable observation is that self-paced loop timing doesn't fit the "scheduling tool" frame at all — it's closer to a kernel/loop-control mechanism that happens to be exposed as a tool in one specific implementation, which is a modeling choice PluggableHarness Agent doesn't have to inherit (see §5).

5. Implications for PluggableHarness Agent#

Cron/scheduling is excluded from the first-party tool reference catalog, grouped with browser automation and memory-as-a-tool as differentiators left to future or third-party providers rather than the reference set (see the reference catalog). This is the sparsest of those differentiator capabilities: there isn't a plurality mechanism to standardize on the way there is for, e.g., edit_file's old_str → new_str pattern, and the two known implementations diverge enough (session-scoped local cron vs. cloud-triggered scheduling vs. loop-internal timer) that any first-party reference design would be picking a convention out of a sample of two rather than distilling a convergent pattern.

That said, there's a modeling question worth surfacing separately from "is this a tool operation worth shipping first-party": self-paced loop timing is arguably not a tool-provider operation in the first place. It controls when the kernel's own turn loop resumes — closer to the agent-loop specification's territory (loop termination and bounds, governing independent bound dimensions and limit-reached behavior for a running loop) than to a resource/data_source/interactive operation a third-party plugin would implement over gRPC. If PluggableHarness Agent ever wants a self-paced loop primitive, modeling it as a kernel loop-control parameter (something the model can influence via a structured turn output, analogous to how plan/apply is already a first-class kernel gate rather than an ordinary tool call) would avoid conflating it with the session-external, wall-clock scheduling that a cron-style tool actually does.

The session-external scheduling half (register a prompt to fire later, independent of any open session) doesn't map cleanly onto any existing PluggableHarness Agent spec's authority. Session persistence and replay own storage and query of session state that already exists, not scheduling new activity into existence; the kernel-callback surface's synchronous, in-session callbacks aren't a wake-the-kernel-later mechanism either; and nothing in the configuration policy DSL addresses recurring or deferred invocation. This looks like a genuine gap rather than a deliberately deferred one — but given how thin this capability is, and that one of the two known implementations depends on a vendor-hosted service with no analog in PluggableHarness Agent's plugin architecture, it's reasonable for PluggableHarness Agent to leave session-external scheduling unaddressed for now rather than design a kernel primitive against a two-implementation sample. If a future third-party tool provider wants to implement local cron-style scheduling, it can likely do so as an ordinary resource-kind operation whose Invoke writes a schedule to its own provider-local state and separately runs a background process that calls back into the kernel's session-running primitive when a schedule fires — the same "ordinary tool provider calling back into the kernel" pattern already used for sub-agent spawning, which would let cron slot into the existing plugin model without new kernel surface, if and when it's prioritized.