Agent Workflows vs Saved Prompts vs Cron Jobs

A lot of solo machines have a cron line 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, and 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 without anyone noticing. 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. Nobody asked it 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, including 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, but scheduling is separate from control. Cron answers when the work starts. It has nothing to say about whether the work was correct, whether a person 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.

Both tools are standing in for 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.

A cron job is a trigger, and 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 that the run moves through the same way every time, and a schedule is one way to start it.

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 work through a worker.
• Branch nodes route the run down different paths based on a condition, and they are the only place a run can fork.
• Approval nodes stop and wait for a person 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. 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. A cron line has none of this, because it only triggers work.

Saved prompt vs cron job vs workflow

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

Read the cron column. It wins exactly one row. Scheduling is the thing cron does well, and it is the only thing. Every other axis is blank, and those blanks are where a 3 a.m. run goes wrong without anyone knowing.

Where the judgment lives

A workflow graph holds together because the decisions sit in explicit nodes instead of inside the agent's reasoning, and the ones that need a person route to one place.

In Task Machine that place is the inbox. 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 watching every run.

Two more controls shape how far a run goes before it asks. Autonomy levels, from Supervised through Balanced and Autonomous to 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 "full" every night, whether the task is rewording a changelog or force-pushing to main.

Budgets need one honest note. Task Machine lets you set spend limits across scopes, tracks real usage against them, and surfaces warnings in the inbox. Once an applicable limit is used up, budget checks stop new runs from starting, but they do not halt an operation that is already running at the exact threshold, and team budgets only track usage.

When cron is 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, such as rotating a log, backing up a database, regenerating a static site, or pinging a health check, cron is the correct tool. There is no output to verify, no decision to route, and nothing a person needs to approve. Wrapping that in a workflow graph adds nodes and a control surface to a job with no ambiguity to control.

The dividing line 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 and invisibly wrong, and cron should never be the only thing standing behind that kind of work. Once a recurring job has an output worth checking, a step worth approving, or a failure worth catching, the scheduler becomes one small input to the answer.

Task Machine is built around that shape: 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. If a cron job has been running an agent on your behalf and you are no longer sure what it does each night, move the work into a loop you can see.

Start a 7-day trial, or read From Prompt Reuse to Repeatable Workflows for the other half of this story.