`##cron`: agents on a schedule

An agent that only works while you watch isn't autonomous — it's supervised. ##cron gives rysh agents a calendar: nightly triage, morning briefs.

Be honest about your "autonomous" agents: do they do anything when you're not looking?

For most setups, the answer is no. The agent works while the chat window is open and you're feeding it turns. Close the laptop and your tireless AI workforce is a parked process. That's not autonomy — that's supervised labor with good branding.

The oldest trick in operations fixes this, and it's older than most of us: cron. Unix figured out in the 1970s that the computer should work on a clock, not on your presence. Rysh applies that idea to agents: ##cron, the built-in scheduler for a workspace where panes are conversations.

The shape of it

##cron is part of rysh's ## command language — the little system shell you type straight into any pane. Schedule work, list what's scheduled, and read what happened while you were gone:

##cron ...            # schedule a prompt or command on a recurring interval
##cron logs           # what ran, when, and how it went

The thing being scheduled isn't a shell one-liner (though it can be). It's a prompt to an agent in a pane — which changes what "scheduled job" means. A cron job that runs npm audit gives you a wall of CVEs at 6am. An agent on the same schedule reads that wall, checks which findings actually touch code paths you use, drafts the upgrade PR description, and leaves a summary in its pane. The clock triggers judgment, not just execution.

What people actually schedule

The patterns that fall out are the unglamorous, compounding kind:

• Nightly dependency triage. Audit, cross-reference, summarize: "2 of 14 advisories affect us; here's the diff that fixes both."
• Morning briefs. Before standup: what merged yesterday, what's red in CI, which TODOs went stale.
• Slow-drift watchers. Disk usage, error-log anomalies, that one flaky test's failure rate — checked on a cadence, escalated only when the trend is real.
• Scheduled browser runs. Rysh's autonomous web recipes compose with scheduling — a scouting or checking task re-run on cadence, results accumulating in a pane. (##auto web schedule exists for exactly this pairing.)

None of these justify a human's morning. All of them justify an agent's 3am.

Where the results go — and why that's the good part

Here's what separates ##cron from "cron + a script that calls an API": the job runs in a pane, in a session.

Rysh sessions are daemons with persistent state. Detach with Ctrl+O d, and the session keeps living; every pane's output and history is persisted to JetStream KV on your machine. So a scheduled agent's work lands somewhere with a memory:

rysh attach ops        # next morning
# the triage pane holds the full transcript: what ran, what it read,
# what it concluded — and ##cron logs has the run history

You don't get a notification that work happened. You get the workspace where it happened, replayable. And when a run matters enough to reach out, scheduled flows can notify and chain follow-ups on success (notify, on_success —) — so the 3am run that found something real doesn't wait politely until you attach.

The governance question you should be asking

"An agent acting on a schedule, with nobody watching" should raise your eyebrows. Good. Here's the honest answer.

A scheduled run gets the same governance as an interactive one — the gates live in the execution layer, not in your attention:

• Read-only and idempotent commands (the allowlist: git reads, ls, grep, builds, tests) run free — which is why triage, briefs, and watchers are the natural cron workloads: they're investigation, and investigation is safe by construction.
• Mutating operations still require approval. An unattended run doesn't inherit your yes; work needing a human waits for one.
• Every tool call is written to the pane's transcript. ##cron logs plus the pane history is the audit trail.

So the honest framing: ##cron doesn't remove the human from the loop — it time-shifts the loop. The agent does the hours of looking while you sleep; you do the seconds of deciding when you're back. That's the right division of labor between a clock, a model, and a person.

All of it on your machines — rysh is self-hostable, sessions run on your hardware with your Anthropic key, and the schedule keeps ticking whether or not a TUI is attached.

Your agents have a clock now. Give them a shift.

Running agents on a schedule in a real team? We want to build this with you — become a design partner: rysh.ai/design-partner.

More in this series: Sessions that survive: attach, detach, and never lose an agent mid-task · ##auto web: autonomous browser recipes in one markdown file