One of the easier ways to waste time with modern automation is to pick the wrong shape.
You can now automate a surprising amount of work with a scheduled task, a script, an agent, an assistant workflow, or something in between. That sounds like freedom. In practice it often creates confusion.
People see a product like GitHub Copilot guiding Git decisions inside the workflow and start wondering whether every recurring task should become "agentic."
Usually, no.
A lot of the time, the right answer is still a boring scheduled task.
The useful question is not:
"Can AI do this?"
It is:
"Does this job need judgment, or does it just need reliability?"
That distinction clears up a lot.
A scheduled task is for work that should stop being interesting
The best scheduled tasks are almost aggressively unglamorous.
They run on a clock.
They do the same kind of thing every time.
They are supposed to be predictable.
If they become surprising, that is usually a bug.
Examples:
- generate a weekly report every Monday morning
- pull new records from one system into another every night
- rebuild a static site when a known source changes
- send a reminder at a specific time
- run a backup
This kind of work benefits from:
- clear inputs
- stable steps
- deterministic outputs
- easy failure detection
You do not want a system improvising here.
You want a system that either works or fails clearly.
That is why cron jobs, timers, and small scheduled workflows are still so useful. They are boring in exactly the right way.
An agent is for work where the path is not fully known in advance
Agent-style automation is useful when the job cannot be fully reduced to "run the same steps again."
That usually means at least one of these is true:
- the input is messy
- the task requires interpretation
- the right next step depends on what it finds
- the user would benefit from guidance, not just execution
- a human may need to review or redirect the work midstream
This is closer to what GitHub Copilot is doing in the decision-guidance pattern I wrote about recently.
The interesting part is not that it can explain Git commands.
The interesting part is that it can intervene at points of uncertainty:
- should these changes be one commit or two?
- is this a good time to push?
- does this repo state look safe?
- should I checkpoint before I merge?
That is not just automation.
That is assisted judgment.
If the job is fundamentally about helping a human make a better decision while the work is in motion, an agent or agent-like assistant can be a very good fit.
My default rule
If I can describe the task as:
given X, at time Y, do Z
I probably want a scheduled task.
If I have to describe it as:
look at the situation, decide what matters, then pick the next step
I probably want an agent.
That rule is not perfect, but it catches a lot.
The weekly blog post example is a good boundary case
I have a weekly scheduled job that drafts a blog post for me based on recent work.
That job is a useful example because it contains both shapes at once.
The schedule itself is simple:
- run every Monday at a known time
- gather recent context
- create a draft
- freeze it
- commit and push it
That is scheduled-task territory.
But inside that job, the actual writing is not deterministic.
The system has to:
- infer what work mattered most that week
- decide what lesson is worth writing about
- choose a frame
- produce a coherent post instead of a status dump
That part is much closer to agentic work.
So the right design is not "cron or agent" as a pure binary.
It is:
- use a scheduled task to trigger the workflow
- use an agent inside the workflow where judgment is needed
- keep the edges around it deterministic
That hybrid pattern is often the real answer.
The real decision variables
When I am deciding between a simple scheduled task and an agent, I usually ask five questions.
1. How repeatable is the work?
If the same steps should happen every time, prefer a scheduled task.
If the steps depend heavily on what the system discovers, prefer an agent.
2. How expensive is a wrong answer?
If mistakes are costly, I want less improvisation.
That usually means:
- deterministic scripts
- narrow checks
- explicit failure modes
- human review gates
Agent freedom is most useful when the cost of exploration is lower than the cost of rigidity.
3. Is timing the point?
Some jobs mainly exist because they must happen at a specific time:
- a morning summary
- a nightly sync
- a weekly backup
- a Monday blog draft
That is a strong hint that scheduling is part of the core design.
An agent can still participate, but it usually should not replace the scheduler.
4. Does the user need coaching or just execution?
This is where tools like Copilot stand out.
A lot of its value is not "I executed a thing for you."
It is "I helped you make the next decision with better judgment."
That is different from a timer-driven task.
If the product value lives in steering behavior inside a live workflow, an agent or assistant is often the better shape.
5. Do I need a receipt or a result?
Sometimes I mainly need the output.
Other times I need the trail:
- why this option was chosen
- what was checked
- what failed
- what the system saw
- where the human intervened
The more I care about inspectable reasoning and intermediate states, the more likely I am to reach for an agent workflow with explicit artifacts.
A bad smell: using an agent to hide unclear process
One of the easiest traps is to use an agent because the workflow itself is still vague.
That can feel productive for a while because the agent appears flexible.
But sometimes what is really happening is that you have not yet defined:
- the trigger
- the inputs
- the expected output
- the validation rule
- the failure boundary
An agent can help discover those things.
It should not become a permanent excuse not to define them.
If a recurring task is stable enough, I usually want to harden more of it over time.
That often means a maturity path like:
- do it manually
- let an agent help while I learn the shape
- capture the recurring parts
- schedule the boring core
That is healthier than calling everything an agent forever.
My practical bias
I am generally biased toward simpler automation first.
Not because agents are bad.
Because unattended complexity compounds faster than people admit.
A scheduled task is easier to reason about.
Easier to test.
Easier to trust.
Easier to repair when it fails at 3 AM.
An agent earns its keep when the work genuinely requires interpretation, synthesis, or guidance.
That is why I find the GitHub Copilot pattern interesting.
It is not interesting because it makes Git autonomous.
It is interesting because it adds judgment support at the right moments inside a human workflow.
That is a much better product instinct than forcing autonomy where none is needed.
The short version
If the job should become boring, schedule it.
If the job still needs judgment, context, or coaching, use an agent.
And if the workflow contains both, which many real ones do, split the system on purpose:
- boring trigger
- flexible middle
- deterministic edges
That is usually a better design than pretending every recurring task wants a robot personality.