Build an agent that runs on a schedule

Most of the value people get from an always-on agent turns out not to be conversation. It is the things that happen without anyone asking: the morning briefing, the hourly check, the weekly report that used to be someone's Friday afternoon.

This is also the shape that goes wrong most quietly, because a scheduled agent has no one watching it by definition.

Scheduled is a different job from chat

When you message an agent, you are there. You see a bad answer and you push back. A scheduled run has none of that: no one to clarify with, no one to notice it misread something, and no natural stopping point except the instruction you wrote. Three consequences worth designing around:

• The brief has to be self-sufficient. Everything the run needs must be in the instruction, because there is nobody to ask.
• It needs a definition of done. Without one, "summarise what happened" expands to fill whatever context it can reach.
• Failure is silent. A run that produces nothing looks identical to a quiet day. Have it tell you it ran even when there is nothing to report.

Which runtimes actually have scheduling

This narrows the field more than people expect. Cron is a first-class feature in OpenClaw ($19/mo) and scheduled tasks are native to NanoClaw ($19/mo). PicoClaw handles a simple recurring job on the cheapest box we run ($9/mo), and Hermes is the right shape when the scheduled thing is a multi-step process rather than a single check.

The hosted coding agents explicitly are not built for this — their catalog entries say so. They are request-driven. If your recurring job is "run the test suite nightly," you want CI, not an agent.

Designing a digest people keep reading

The failure mode is not a digest that is wrong. It is a digest that is long, which becomes a digest nobody opens, which is the same as not having one.

1. Cap it. "At most five items, one line each, most important first." A hard cap forces the ranking that makes it useful.
2. Say what a non-event looks like. "If nothing needs me, send exactly: nothing needs you." That single line is what tells you the job ran at all.
3. Separate urgent from digestible. Urgent breaks the schedule and reaches you now. Everything else waits. Without that split you are choosing between noise and delay.
4. Give it a stable shape. Same sections, same order, every day. A predictable message gets read in five seconds; a freeform one gets postponed.

Start daily, not hourly

The instinct is to run things often. Resist it for the first fortnight.

An hourly job is twenty-four times the model spend of a daily one and roughly the same amount of information, because most hours contain nothing. Start daily, read what it produces for two weeks, and increase the frequency only where you can point at a run that would have been worth having sooner.

The way this gets expensive

Scheduled agents are the number one source of surprise bills, and the reason is structural: nothing fails, nothing alerts, and the cost accrues at 3am. A job that does slightly too much, running every hour, is invisible until the month ends.

Three defences:

• Scope each run explicitly. "Check these four sources" beats "check my sources."
• Tell it when to give up. A run that cannot reach something should report that and stop, not retry until it works.
• Look at cost per run in the first week. Multiply by thirty. If that number surprises you, fix it now rather than after a month.

Every agent built here reports cost per conversation and per run to ClawMetry, with a stop button. For a process whose defining property is that nobody is watching it, that is the part of the setup you should do first, not last. There is more on the numbers in what an agent actually costs.