The Agent That Should’ve Been a Cron Job
The procedure is settled. The model is still being paid to rediscover it every morning.
What it is
The Agent That Should’ve Been a Cron Job uses an AI agent to interpret and execute a repeatable procedure whose rules are already known. A script could run those rules directly, but the workflow keeps asking a model what to do next. It’s a for-loop with a metered genius inside it.
How it happens
The agent worked the procedure out interactively, and it worked — so the procedure just… stays inside the agent. Why extract it into code when you can ask it to “do that thing again” tomorrow? The tool that helped discover the procedure becomes its permanent runtime.
Consider an illustrative daily sales digest: select yesterday’s paid orders in the agreed timezone, exclude cancellations, total by store, and render a fixed table. Those are explicit rules. Have AI write and test that program. If the digest also needs a prose explanation of unusual results, a model can draft that section from the computed figures without choosing which orders count as revenue.
Warning signs
- The model repeatedly chooses steps that could be one call to an existing script.
- A rule change requires editing several scheduled prompts because no shared implementation owns the rule.
- The same input snapshot can produce different totals, filters, or output fields.
- Nobody can explain what judgment the live model call contributes.
- Cost, completion time, retries, and failed runs are not measured together.
Why it’s dangerous
A model call adds a dependency and a place where the procedure can be interpreted differently. If a daily report quietly changes its definition of “paid,” every number may look plausible while comparisons with last week stop meaning anything. The arithmetic can be correct while the report answers a different question.
That does not make every scheduled agent wasteful. An occasional job, a procedure still being discovered, or work that needs runtime judgment can justify one. Changing input values alone do not: that is what program arguments are for. Anthropic’s agent design guidance distinguishes predictable workflows from agents that choose their own steps and recommends weighing added cost and latency against performance. Include the cost of building and maintaining the replacement. A model call that costs little and runs twice a month may be cheaper overall than another service somebody has to operate.
How to prevent it
Separate the known rules from the judgment. Put selection, arithmetic, validation, and delivery rules into code when their behavior is settled. Keep a model call for a step such as interpreting free text when it adds useful capability. Give that call bounded inputs and validate its output before anything relies on it.
Ordinary code still needs correct rules, tests, monitoring, and maintenance. Cron supplies a schedule, not correctness. You may only need to expose an existing script as a tool and let the agent invoke it. Do not build a new automation platform to avoid a handful of model calls.
The serious team fix
- Turn the discovered procedure into a maintained tool. For a stable procedure that runs often enough to justify it, have AI draft the program and its checks against agreed examples. Record the input contract, timezone, rounding rules, and expected output where they matter. Put the code in version control with a named owner.
- Confine judgment to the step that needs it. A narrative summary can fail without changing the report’s totals. Decide whether that failure should stop delivery or produce an explicitly incomplete report; do not silently substitute invented commentary.
- Measure the whole job. Track cost per successful run, completion time, errors, and recovery work. For the digest, record the source snapshot and the rules used to calculate totals. Check what a retry does after partial delivery. Compare operating and maintenance costs before extracting more code; the aim is a dependable job, not a model-free purity badge.