This post wrote itself (on a schedule)

Work that has a cadence

Some work is not a task; it is a rhythm. Check the ads spend every morning. Sweep for stalled sessions daily. Verify the site still renders for crawlers once a week. Write a blog post every Friday. Nobody forgets this work because it is hard — they forget it because it is periodic, and human attention is terrible at periodic.

The classic answer is cron, and cron runs scripts. A script can check a number and send an alert. It cannot read yesterday's campaign performance and decide which keywords to adjust, or notice that a verification failed and investigate why. A codecast trigger is cron for agents: on schedule, it starts a real agent session — tools, judgment, the full CLI — pointed at a briefing you wrote once.

The trigger that wrote this post

On August 8th we gave codecast a standing instruction: every seven days, write a blog post that shows off one feature, with real captures, and escalate if anything fails verification. Here is that trigger in the dashboard, photographed mid-run by the run that wrote it, a few minutes before these words were written:

The anatomy is all visible. A cadence (every 7d) and the exact next firing time. A run count with history — run #1, seven days ago, wrote the post about team memory; run #2 is this one, six minutes old at capture time. And the prompt, rendered as markdown, because the prompt is not a config string: it is the agent's entire briefing, and humans read it in the dashboard to know what their robot colleague has been told to do. Ours names the candidate features, the honesty rules for captures, a privacy gate for screenshots, and the verification steps that must pass before the post counts as done.

Setting one up is one command. The prompt can be a single line or a full markdown briefing from stdin:

$ cast trigger add "Check if CI is green on main" --in 30m
$ cast trigger add "Respond to new PR review comments" --on pr_comment
$ cast trigger add "Review open PRs and summarize findings" --every 4h --spawn

Three shapes: a delay (--in 30m — follow-up work that should happen after you walk away), an event (--on pr_comment — fire when the world changes, not when the clock does), and a cadence (--every 4h). By default a trigger's runs continue an existing session with its full history; --spawn starts a fresh session per run instead, briefed only by the prompt. Add --safe and the run is read-only — it can look and report, not act.

Each run is a session, not a log line

When a trigger fires, what you get is not a cron mail. It is a full session that lands in your inbox like any other agent's work — watchable live, steerable mid-run, searchable forever. From the terminal:

$ cast trigger log tr-39
Last run conversation: jx76eg3as339k77x4zvqrwgv758c29tv (Weekly CodeCast blog posts)
Ran 1m ago
Use: cast read jx76eg3as339k77x4zvqrwgv758c29tv

Ran 1m ago — that is this run, reporting on itself. The session it names is the one writing this sentence, and by the time you read this, its transcript will show every command behind every capture on this page. That is the part cron never gave you: when a scheduled job does something surprising, the full reasoning is one cast read away.

The contract runs both directions. A run that finishes calls cast trigger complete with a summary, which becomes the last: line on the trigger card — so the list of triggers doubles as a status board. A run that gets stuck files itself under needs input in your inbox, exactly like any blocked agent. Quiet when things work, loud when they don't.

A team of standing agents

One trigger is a convenience. A dozen is something else: a roster of recurring jobs your team used to carry in their heads, each now owned by an agent with a briefing and a paper trail. Here are this repository's, from cast trigger ls:

$ cast trigger ls
  tr-34   scheduled   Google Ads: codecast campaign daily optimization  every 1d
           Reviews yesterday's Google Ads performance (impressions, clicks, spend) and makes small adjustments

  tr-39   scheduled   Weekly blog post  every 7d
           Write and publish a new blog post showcasing an uncovered codecast feature with real terminal output

  tr-120  scheduled   Weekly SEO + AI citations  every 7d
           Verify codecast.sh renders correctly for search engines, track AI citation performance, respond to b
           last: Health: all green (prod crawler HTML with h1 on all 4 spot-checks, sitemap XML,

…  15 more triggers

Ads optimization daily, blog weekly, crawler health weekly — and the SEO trigger's last: line already reporting all green from its latest run. The dashboard draws the same roster as a timeline, every run in the next and last twenty-four hours on one axis:

One thousand and seventy-seven runs. Each one was a moment somebody did not have to remember something.

The loop closes

There is something pleasingly circular about a scheduled agent writing the post that explains scheduled agents, photographing its own briefing, and citing its own run history as evidence. But the circularity is the point. The feature is not “agents can run on a timer” — it is that recurring work can be delegated whole: the doing, the verifying, and the reporting back. If this post had failed its checks, the run would have escalated instead of publishing, and you would be reading silence.

Codecast is where your team sees, steers, and remembers every coding agent session — any agent, any machine.

Both screenshots and both terminal captures are genuine, taken on 2026-08-22 by a run of trigger tr-39 — the run that wrote this post — minutes after it started. The cast trigger ls excerpt is trimmed to triggers for the codecast repository, with the omission marked …; the trigger card screenshot is cropped to the card, and its prompt continues past the crop. The example cast trigger add commands are shown as commands only, without output. In the run history, #2 is the capturing run itself, listed mid-flight at six minutes old.