Cron vs AI Agents: Why I Use Cron for 13 Automations

My dev studio runs 13 automations. They fire every day: collecting blog topics, generating candidates, publishing articles, sending notifications, logging everything.

All cron. Not one agent.

When I mention this to people following the AI space, the first question is almost always the same: "Why not LangGraph?" The answer is boring. LangGraph is interesting. Cron is reliable. For production business processes, I choose reliable.

What's actually running

I wrote a full breakdown of the system elsewhere. The short version: 13 tasks covering a content pipeline, task monitoring, publishing, and notifications. No orchestrators, no multi-agent planning. Each task is a script with one responsibility. Claude Code helped write them, but Claude doesn't control when or whether they run.

The system works. When a task fails, I see it in the logs within five minutes. When Claude returns unexpected output, the script parses it deterministically — either processes it or queues it for manual review. No drama.

This is the starting point for why I'm skeptical of agents for this kind of work.

Why "AI agent" is an architectural decision, not a tool swap

When people say "use an AI agent," they usually mean "use a framework where the model decides what to do next." That's not just swapping a library — it's handing control over the execution flow from deterministic code to a language model.

A cron job: start → run → result. The flow is fully defined upfront.

An AI agent: start → model decides what to do next → model decides again → ... → result. The flow is governed by the model's reasoning.

For research tasks, for complex multi-step scenarios with genuinely unpredictable conditions — an agent can be the right call. For publishing a post on a schedule, sending a notification, parsing a log — adding non-determinism there solves nothing. You're just adding a new failure mode.

LangGraph isn't a bad tool. But you have to understand what you're actually choosing when you pick it.

Three things that break when agents meet production

I'm not theorizing here. When I was building the automation system, I seriously looked at agent-based approaches. These three problems pushed me away.

First: observability. A deterministic script has a clear stack trace, logs with specific variable values, predictable failure points. An agent has a history of the model's "reasoning," which is hard to decode after the fact. When something goes wrong at step 4 of 7, I need to know why — not read through a model transcript hoping to find the moment it "decided wrong."

Second: run-to-run variance. The same agent with the same inputs can produce different results across runs. That's fine for creative generation. It's not fine for publishing content to a live site. I need to know that each run does exactly what the previous one did.

Third: debugging and retry. When a cron task fails, I know at which step, with which error, and I can rerun it with identical parameters. When an agent makes a wrong intermediate decision at step 3, retry doesn't guarantee reproduction — it might pick a different path. That makes debugging significantly harder.

All three problems are solvable. But the solution usually involves building a deterministic layer on top of the agentic one. At some point you start asking: why the agent at all, if I'm writing the deterministic layer anyway?

The hybrid that actually works: Claude API inside cron

A cron-plus-LLM hybrid is a deterministic script that calls a language model at one specific step, receives a response, and processes that response with regular code — no agent framework, no autonomous routing. In practice this means a cron script assembles context, sends a request to the Claude API with a strict system prompt, and parses the response against a known schema.

If parsing succeeds, the script continues. If not, it fails with a clear error — not silently, not ambiguously.

This isn't an agent. It's a script that uses an LLM as a function. Control over the execution flow stays in the code, not the model. Claude here is a powerful text transformer, not the decision-maker.

For 90% of the studio's automation tasks, this is enough. The model generates content, analyzes data, formats output. The code decides what to do with the result.

When agents are actually justified

I'm not against agents. I'm against using them where they create problems without a matching benefit.

An agent makes sense when:

the task requires real multi-step planning with genuinely unpredictable conditions;
the cost of error is low and the task tolerates output variance;
there's budget to build a proper observability layer;
the alternative is a massive deterministic decision tree that nobody can read anymore.

In the studio, exactly one task fits these criteria right now: researching a topic before writing an article. That actually requires multiple search iterations with intermediate decisions. Variance is acceptable there. I'm willing to invest in observability there.

Everything else: cron.

Boring is reliable

In 2024, when every feed is full of headlines about AI agents, "autonomous systems," and "workflow orchestration," choosing cron sounds like admitting you're behind.

I don't see it that way. Reliability in production isn't a compromise — it's a requirement. These 13 tasks run every day without my involvement precisely because each one does exactly one thing, fails predictably, and recovers without magic.

LangGraph will come back into my stack when a task actually needs what it offers. Until then, cron handles it. That's not a limitation of the architecture. That's the point of it.

*See also: How I trust AI agents in production: 3 patterns from 13 cron jobs — the trust patterns inside specific tasks. Monitoring 13 autonomous agents — what to log, what to alert on. Spec-first AI development — why discipline matters more than tooling.*