Every system I ship starts as an agent and ends up as a cron job. This has happened enough times that I've stopped resisting it.
The pattern is always the same. I want to automate a thing. I reach for an agent — a small loop that reads, decides, acts, reports. It's the right mental model for the prototype. Then the prototype ships, and within a week I notice the agent is doing exactly three things in the same order every time it fires. The reading, deciding, and acting were load-bearing in the design. They are not load-bearing in operation.
An agent is a prototype of a cron job that has not yet been simplified.
What an agent earns you
Flexibility, when you do not yet know what the thing should do. The agent's loop is a working document. Each time it fires you learn whether the read step is fetching the right inputs, whether the decision step is making reasonable calls, whether the act step is writing to the right destinations.
This matters for exactly long enough to converge on an answer. After that, the flexibility is paying for nothing.
What cron earns you
Determinism. Cheapness. Clear failure modes. A launchd plist or a crontab line is six lines of config and produces a running system that does the same thing every time at the same time. If it breaks, the exit code tells you. If it slows down, the log shows you. There is no "but the agent decided not to this time" ambiguity.
Also: debugging. An agent that misbehaves requires you to reconstruct its reasoning. A cron job that misbehaves prints a stack trace.
The refactor
When I notice an agent has stopped earning its agency, the refactor is mechanical:
1. Freeze the decision. Whatever branching logic the agent has, pick the dominant path and hardcode it.
2. Freeze the inputs. Whatever the agent was reading dynamically, pin it to a specific query or URL.
3. Keep the act. The writing step usually stays the same.
4. Wrap it in a shell script. Add the schedule. Delete the agent.
What's left is ten to forty lines of Python and a cron line. The agent was the scaffolding. Cron is the building.
When agents actually earn their keep
Three cases. First: when the inputs really are unpredictable and human-adjacent — someone texting my phone, someone uploading a video. The router has to decide something non-trivial every time. Second: when the decision is expensive enough that caching it as a cron job would produce stale output — market conditions, schedule coordination. Third: when you are still learning the shape of the problem.
Everything else, cron wins. It has never been close.
The deeper point
AI systems love to frame themselves as agents because agents sound intelligent. The more honest framing is: a system that does a thing on a schedule, with one small decision at the top and a deterministic tail. The intelligence, when you need it, belongs inside the decision. Not wrapped around the whole pipeline.
Most AI strategy lives in slide decks. Mine runs on cron schedules. That is not a flex. It is what happens when you let the prototypes grow up.