We Replaced a Cron Job With an AI Agent. It Cost 41× More and Was Slower.

Latency, cost, and accuracy: Cron jobs vs. AI agents.

Everyone’s bolting agents onto workflows that a script already handled. We tried it, measured it, and did the math.

Our nightly reconciliation job has run the same way for three years: a cron trigger, a bash script, a database query, a CSV diff, an email if something’s off. It had become so reliable that most of the team forgot it even existed.

Then someone suggested replacing it with an AI agent — “so it can reason about anomalies instead of just flagging thresholds.” It sounded like an upgrade. Everyone in the room nodded.

Why We Thought the Agent Would Win

Before I ran a single test, here’s what we expected going in, because it’s worth being honest about the case for the agent before showing why it didn’t hold up:

• Natural-language anomaly explanations a human reviewer could read without decoding a log format
• Handling of edge cases the fixed thresholds might miss — a record that’s technically within range but contextually weird
• Less brittle than hardcoded thresholds that need manual tuning every time the data shifts

Those are real, legitimate reasons to consider an agent. So instead of arguing about it in the meeting, I said let’s just measure.

The Setup and Methodology

Same task, same dataset, same environment, run 12 times each and averaged, to rule out one-off network flukes on either side.

# the old way — cron + bash, unchanged in 3 years
0 2 * * * /opt/scripts/reconcile.sh >> /var/log/reconcile.log 2>&1

# the new way — an agent framework wrapping an LLM call per anomaly check
agent = Agent(model="claude-sonnet-4-6",
              tools=[query_db, flag_anomaly, send_email])
agent.run("Reconcile last night's settlement records and flag anomalies")

Agent setup, for reproducibility:

• Model: Claude Sonnet 4.6
• Agent framework: a custom loop on top of LangChain, three tools (query_db, flag_anomaly, send_email)
• Dataset size: 2,400 settlement records per night
• Runs averaged: 12

The Numbers

| **Metric**                            | **Cron + Bash (Old)** | **AI Agent (New)** |
| ------------------------------------- | --------------------: | -----------------: |
| **Wall-clock time (avg. of 12 runs)** |           **3.9 sec** |        **158 sec** |
| **Cost per run**                      |    ~₹0 (compute only) |          **$2.35** |
| **Records processed**                 |                 2,400 |              2,400 |
| **False positives flagged**           |                     6 |                 14 |
| **Anomalies caught that Bash missed** |                     — |                  2 |

The agent wasn’t just slower on average — it was slower on every single one of the 12 runs, with no overlap against the bash script’s times. And more than double the false positives means someone on the finance team spent extra time each morning ruling out flags a threshold check would never have raised.

What the Agent Actually Did Better

To be fair to the other side of this: the two anomalies the agent caught that bash missed were both records that fell technically within range but were contextually odd — a settlement amount that matched a known refund pattern from a closed account.

A threshold check has no concept of “closed account behavior masquerading as a normal transaction”; the agent’s tool calls pulled account history and reasoned about it. And the agent’s flagged-anomaly output came with a plain-English explanation a non-engineer on the finance team could read directly, without anyone translating a log line for them. That’s a genuine advantage a threshold script doesn’t give you for free — it just came at a steep price for the other 2,398 records that didn’t need it.

Why the Cost Gap Exists

In our implementation, the bash script does one database query and one diff — constant time, no API calls, no round-trip to a model provider.

The agent does something structurally different for every record it evaluates:

Old flow — one pass, no round trips:

┌──────────┐     ┌──────────────┐     ┌──────────────┐     ┌───────────┐
│  Cron    │ ──> │  SQL query   │ ──> │  CSV diff    │ ──> │  Email    │
│  02:00   │     │  ~1.2 sec    │     │  ~2.7 sec    │     │  if flag  │
└──────────┘     └──────────────┘     └──────────────┘     └───────────┘
                                                              total: 3.9 sec

New flow — one round trip to the model per record, repeated 2,400 times:

┌──────────┐     ┌──────────────────────────────────────────────────────────┐
│  Cron    │ ──> │  Agent loop (× 2,400 records)                             │
│  02:00   │     │                                                            │
└──────────┘     │   ┌─────────┐   ┌───────────┐   ┌─────────┐   ┌─────────┐  │
                  │  │ LLM call │──>│ Tool call │──>│ LLM call │──>│ Decide  │  │
                  │  │ "reason  │   │ query_db  │   │ "read    │   │ flag or │  │
                  │  │ about    │   │ / flag_   │   │ result,  │   │ pass"   │  │
                  │  │ record"  │   │ anomaly   │   │ explain" │   │         │  │
                  │  └─────────┘   └───────────┘   └─────────┘   └─────────┘  │
                  │                                                            │
                  └──────────────────────────────────────────────────────────┘
                                          ↓
                                       Email
                                    total: 158 sec

Same shape of work, same destination — but the new flow pays for a network round trip and a model inference on every single record, twice per decision, where the old flow paid for one SQL query total.

Many agent implementations — ours included — end up calling the model more than once per decision: once to reason about the record, once to decide whether to invoke a tool, sometimes again to interpret the tool’s result. Multiply that by 2,400 records a night, and you’re paying, in latency and dollars, for a decision a threshold check was already making correctly in microseconds.

Where Agents Actually Earn Their Cost

This isn’t an anti-AI piece. An agent earns its keep when a task genuinely requires judgment a fixed rule can’t express — ambiguous cases, natural-language explanations for a human reviewer, situations where “it depends” is the honest answer. Nightly threshold reconciliation on structured settlement data mostly wasn’t that, in our case. It’s close to the deterministic, rule-shaped problem cron and bash were built for in the first place.

The two catches the agent found suggest a middle path worth testing next: keep bash as the nightly pass, and route only the handful of borderline records — the ones sitting near a threshold edge — to the agent for a second opinion. That would mean maybe 20–30 agent calls a night instead of 2,400.

The Question I Now Ask Before Reaching for an Agent

Before wrapping anything in an agent framework: does this task already have a correct, deterministic answer a script can compute? If yes, an agent doesn’t automatically make it smarter — in our measurements, it made it slower and more expensive without adding proportional value. Use agents where reasoning genuinely adds value. Use scripts where deterministic logic already solves the problem. Those aren’t competing philosophies — they’re two tools for two different shapes of problem.

Ask that question in your next planning meeting before someone proposes AI-ifying the next cron job. Watch how many hands go still.