diff --git a/thoughts/ai/cron.md b/thoughts/ai/cron.md
index 361b5c2..edf7be2 100644
--- a/thoughts/ai/cron.md
+++ b/thoughts/ai/cron.md
@@ -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 don’t replace pipelines. They sit at the boundary where
+> pipelines fail. That boundary is where human judgment used to live,
+> and where agents now belong.