Agent Workflows vs Saved Prompts vs Cron Jobs

There is a cron line on a lot of solo machines that looks responsible. Something like 0 3 * * * pointing at a script that pipes a saved prompt into a coding agent: triage the issue tracker, draft the replies, push the dependency bumps. It ran last night. It ran the night before. The reassuring part is that it ran. The unsettling part is that nobody can say what it did.

One morning it does the wrong thing quietly. The dependency bump it pushed broke a build at 3:14 a.m., the agent decided the failing test was flaky and moved on, and the only trace is a commit nobody asked for. The cron job did exactly what it was told: it started the process on schedule. It was never asked to check whether the process succeeded, because a scheduler has no opinion about success.

That gap — between starting work on a schedule and running a controlled loop — is the whole problem. Most solo builders reach for one of two tools to make recurring agent work reliable, and both leave the same hole.

Two tools, one missing piece

A saved prompt captures the request. The first time a prompt produces a good result, saving it is the obvious move, and it removes real friction. But a saved prompt only remembers the instructions. It does not remember what happened last time, it cannot check its own output, and it has no place to stop and ask a question. (An earlier post covers that path in depth — what breaks as a prompt library turns into a shadow workflow system.)

A cron job adds the one thing a saved prompt lacks: it runs on its own, on a schedule, without anyone present. That feels like the upgrade. It is not, because scheduling is orthogonal to control. Cron answers when the work starts. It has nothing to say about whether the work was correct, whether a human should have seen it first, or what to do when a step fails. It fires the prompt into the dark and trusts the agent to behave.

The thing both tools are standing in for is a controlled loop: a defined sequence of steps where the path can branch on a condition, a step can pause for a human answer or approval, an output can be verified before the next step runs, a failure can retry or escalate instead of being swallowed, and every step leaves a record. Scheduling is one input to that loop. It was never the loop itself.

A cron job is a trigger, a workflow is a graph

The clearest way to see the difference is to stop thinking about when and start thinking about what happens between start and finish.

A cron job has two states: it fired, or it did not. Everything in between is the agent improvising with no structure around it. A deterministic workflow is an explicit graph of nodes the run moves through the same way every time. The schedule is just one way to start that graph — it is not the graph.

In Task Machine, a workflow run is built from a small set of node types, and a schedule is a separate first-class object that fires a run:

• Agent nodes do the actual work through a worker.
• Branch nodes route the run down different paths based on a condition — the only place a run is allowed to fork.
• Approval nodes stop and wait for a human to approve or reject, splitting into an approved path and a rejected path.
• Ask-human nodes pause to ask a question and resume with the answer.
• Artifact nodes capture the concrete output a step produced.

Verification and retry sit on top of those nodes rather than being nodes themselves. A node can carry a verifier that checks the output and, when the result is uncertain, opens a review instead of letting the run continue. Failed or timed-out steps retry with backoff before they are allowed to fail the run. None of that exists in a cron line, because a cron line is a trigger, not a graph.

Saved prompt vs cron job vs workflow

Put the three approaches against the axes that decide whether recurring agent work is trustworthy.

Read the cron column down the middle. It wins exactly one row. That row is real — scheduling is the genuine thing cron does well — but it is the only one. Every other axis is blank, and those blanks are where a 3 a.m. run goes wrong without anyone knowing.

Where the judgment actually lives

The reason a workflow graph holds together is that the decisions are not buried inside the agent's reasoning. They are explicit nodes, and the ones that need a person route to one place.

In Task Machine the inbox is that place. When an approval node is reached, an approval item appears there. When an ask-human node needs an answer, a question appears. When a verifier comes back uncertain, a review appears. When a step fails after its retries, or a budget threshold trips, an exception appears. A cron job that hits the same situations has nowhere to put them — so they become a silent commit, a swallowed error, or a surprise on the next invoice. The inbox is how a solo builder stays in the loop on the few moments that need judgment without sitting and watching every run.

Two more controls shape how far a run goes before it asks. Autonomy levels — from supervised through balanced, autonomous, and full — set, per scope, which actions need approval and which the agent may take alone. A lower level routes more decisions back to a person. And before risky work runs, planning scores it on blast radius, novelty, sensitivity, and reversibility, and a high enough score sends the plan for approval before any step executes. A cron job has no equivalent. It runs at level "full" every night, whether the task is rewording a changelog or force-pushing to main.

A note on budgets, kept honest: Task Machine lets you set spend limits across scopes, tracks real usage against them, and surfaces warnings and refusals in the inbox. Hard, automatic enforcement on every path is still being filled in, so treat budgets today as set-and-track with inbox alerts rather than a guaranteed hard stop on every scope.

When cron is genuinely enough

A workflow graph is the wrong tool for plenty of jobs, and pretending otherwise is how people end up over-building.

If the task is fully deterministic, has no judgment in it, and fails loudly when it fails — rotate a log, back up a database, regenerate a static site, ping a health check — cron is the correct tool. There is no output to verify, no decision to route, and nothing a human needs to approve. Wrapping that in a workflow graph adds nodes and a control surface to a job that has no ambiguity to control.

The line is not "scheduled versus on-demand." It is whether the work involves judgment that can be wrong in ways nobody would notice until later. A backup either restored or it did not. An agent that triaged your inbox, decided which issues to close, and drafted the replies can be confidently, invisibly wrong — and that is exactly the work cron should not be the only thing standing behind. The moment a recurring job has an output worth checking, a step worth approving, or a failure worth catching, the scheduler stops being the answer and becomes one small input to it.

That is the shape Task Machine is built around: recurring work as a graph you can read, gate, and trust to behave the same way every run, with a schedule as one of the ways it starts rather than the entirety of what it is. If a cron job has been quietly running an agent on your behalf and you have stopped being sure what it does each night, that is the signal to move the work into a loop you can see.

Join the private beta on the waitlist, or read From Prompt Reuse to Repeatable Workflows for the other half of this story.