Agent cron versus production rails: 2026 vendor schedulers, and why we run OpenClaw + a scheduler + Temporal

Most vendors now offer a way to run unattended agents on a schedule. They are fast to start and easy to host. We still run OpenClaw + a scheduler + Temporal, because the workflow layer — not the timer — is what makes agent work production-grade.

The 2026 roundup (verified 4 Oct 2026)

• Anthropic Routines in Claude Code: research preview since 14 Apr 2026. Fired by schedule, API call or GitHub event, in a fresh cloud VM. Hourly at most, no approval stops. The docs say a green run means no infrastructure error, not that the task succeeded.
• Anthropic Claude Managed Agents: scheduled deployments since 9 Jun 2026 (public beta). Minute-level cron, per-tool approvals that wait for a human, vaulted credentials. A failed run is recorded, not retried.
• OpenAI dots: announced at DevDay, 29 Sep 2026. An always-on agent in ChatGPT with its own cloud computer and recurring tasks in plain language. Limits and retry behaviour not yet documented; say only that.
• GitHub Agentic Workflows: public preview since 11 Jun 2026; schedule or repo-event triggers, optional manual approval.
• Microsoft Foundry Agent Service routines: public preview; timer, cron and event triggers; the one vendor scheduler we found documenting delivery retries (up to five).
• Google Jules scheduled tasks (since 10 Dec 2025); Cursor and Devin Automations; AWS Bedrock AgentCore, a managed runtime with no scheduler of its own in the docs we read.

Our rails in production

• Agents run on OpenClaw on our own server. A weekly workflow runs on a self‑hosted Temporal server beside it. The OpenClaw scheduler only fires the weekly start.
• Models do judgment only: one proposes, a model from another vendor challenges, the first refines. Side‑effecting steps are plain code.
• Every stage is a human approval in Telegram. Gates open strictly in order; a comment revises only that piece.
• Approvals wait as long as needed: on the first full run one took 20 hours and the cycle 12 days, surviving several restarts and deploys. Each scheduled item then gets a durable timer and a go/no‑go message 20 minutes before.

We operate this as a workflow, not a long prompt. The scheduler starts the work once. The workflow carries state, approvals, retries and alerts until the cycle closes.

Point‑by‑point comparison

• Failure halfway: most vendor runs start fresh on the next trigger. Our workflow resumes at the failed step.
• A human in the middle: vendor docs we read describe approvals at start-of-run or per tool; nothing about mid‑run approvals that can wait days. Our gates can wait indefinitely.
• Memory between runs: a fresh agent session will not, by default, know last week’s outcome. Our workflow carries state and timers per item.
• Knowing it worked: a green session means “no infrastructure error” in at least one set of docs; we verify each step and alert on any failure.
• Who owns schedules and history: vendors own the scheduler UI and logs. We keep schedules, state and history in our repo and Temporal, and we can swap models.
• Cost and responsibility: vendors win on managed sandboxes, vaulted credentials, connectors and nothing to patch. We run and patch all of it.

A simple flow, end to end

To make the rails versus scheduler distinction concrete, here’s an abstract, non‑social example of a recurring request becoming a finished artifact:

1. A request is defined in plain language: purpose, inputs, checks, approvers, delivery windows, and what must never proceed without approval.
2. The scheduler fires on the chosen cadence. One signal, one start.
3. The workflow starts and loads prior state (what ran last time, who approved, pending items).
4. A code step collects inputs. An agent drafts the artifact. A second model reviews it. The first refines.
5. The workflow posts an approval in Telegram and waits. It can wait hours or days without losing its place.
6. When approved, the workflow sets a durable timer for the delivery window and sends a go/no‑go message 20 minutes before.
7. At the timer, code executes delivery and records outcomes. Each step is verified and logged.
8. The workflow closes with a summary and archived state for the next run.

The key is orchestration: the scheduler answers “when,” while the workflow carries who decides, what to check, what to wait for, and how to record it.

Why the workflow layer matters

Production rails answer “what happens next, under which conditions, and who decides.” That is what turns a recurring trigger into dependable work.

In our case, the process owner never edits workflow code. Stages, gates and rules are described in plain language and corrected by conversation. It could sound like this:

• “If an approval is pending, wait as long as needed. Do not time out unless I say so.”
• “If a delivery step like ‘write to ledger’ or ‘send report’ fails, stop and alert me. Do not retry automatically.”
• “Set a go/no‑go message 20 minutes before each scheduled delivery and wait for approval.”
• “End the run with a summary of successes, failures and any manual actions.”

The payoff is speed and access: you move from an idea to a working, correctable run by describing the rules, then refining them in conversation.

Choosing rails: vendor cron or your own

Pick the vendor cron when you want a managed sandbox, vaulted credentials, connectors and zero patching — and your task fits one session without multi‑day gates or step‑level guarantees.

Pick your own rails when you need durable, step‑verified work with humans in the middle, state between runs, and rules about what must never be retried.

We run OpenClaw + a scheduler + Temporal for that reason. If you are choosing between a vendor scheduler and your own rails for agent work that must not go wrong twice, we can walk you through how ours is built.

Where do you draw the line between vendor convenience and the guarantees your operation needs?