added cron post

This commit is contained in:
2026-02-08 22:17:39 -05:00
parent d5706fc5e1
commit a6bf0af02b

View File

@@ -1 +1,109 @@
# Thoughts on AI-based cronjobs
# Integrating AI Agents Into Scheduled Workflows
## Forward
AI, especially AI agents, are undeniably powerful today. Integrating
agents into scheduled tasks is actually a very natural next step as it
unlocks NLP in such workflows.
With the recent on-going development of `wp-materialize` and using it
to sync a blogs repo to my [personal
website](https://peisongxiao.com), and some tasks given during my
co-op, it's becoming one of the things on the top of my head.
---
## Necessity of agents
If we trace this topic using first principles, the biggest question
isn't "How to integrate agents into workflows?", it's:
> When to use agents?
Quite frankly, this is a nuanced question. You can practically do
anything with agents that you would normally do on your device. But is
that really what you need for cronjobs?
*We don't need agents for everything.*
### In applications
The simplest example out there: alarms.
It would be hilarious if someone scheduled an agent task for every
single alarm (but there are potential ways agents could be
integrated).
An application with a well-defined purpose doesn't need AI.
### Classic pipelines
For example, a well-established task doesn't need agents. If your
cronjob involves a simple, deterministic script with verbose output
would simply involve a message-sending channel and a log dump, perhaps
a parser in front to decide if a dump is actually needed.
This is largely applicable to existing scheduled jobs, no need to
spend money and time in setting up agents when the task itself is
**well-defined**.
## So, when do we need agents?
The gist of it is simply:
> When the task isn't well-defined and needs changing behavior.
When the task involves arbitrary input that requires human
understanding or reasoning, an agent could be a better fit.
The end-goal of having any scheduled task solidified into either a
deterministic script or application logic or an agent task, is to
minimize human intervention when doing repeated jobs. And agents do
quite well as a substitute for human reasoning and actions.
### Example: Scheduled Policy Review
Policies, unless in a machine-readable format, is not friendly to any
script. LLMs are one of the best parsers for such input, agents may
even discover new relevant policies as they arise.
If the task is to review the policy and suggest actions, then an agent
is definitely a good choice.
---
## But how?
### Accessibility
After using [OpenClaw](https://openclaw.ai/), I found that setting up
scheduled agents has never been easier for simple workflows: you
simply talk to OpenClaw about your needs, and it will set things up
for you.
But that's just one wrapper around such logic, more tools will
definitely come. And there's nothing stopping anyone from setting up
their own framework or a one-shot job if they have the knowledge to do
so.
But for someone that doesn't have access to such knowledge and tools,
it's up to someone to package that into a consumer-friendly UI/UX
that's also safe to use. We're not going to dive into the depths of
what agents can and cannot do in this post.
### What to do
Without diving into the depths, there's only one thing I can say about
this:
> Be explicit.
Being explicit about the context, the goals, and the
boundaries. They're what makes any agent powerful and safe.
---
## Reflections
Agents are just another tool in the task pipelines. Treat them as
the key to unlocking new possibilities, not as something you must use
for every job.
Consumer availability is still limited, but that landscape is rapidly
changing.
> Agents dont replace pipelines. They sit at the boundary where
> pipelines fail. That boundary is where human judgment used to live,
> and where agents now belong.