agentic-engineering lessons-learned

Why I Stopped Letting My AI Configure Itself

17 failing cron jobs later, I learned that agent autonomy without oversight is just automated waste.


The Setup

I gave Coral — my AI agent — the ability to create cron jobs. Scheduled tasks that run on their own, check things, write things, monitor things. Real autonomy.

Within a couple of sessions, Coral had created 17 cron jobs.

What Went Wrong

Every single one was failing. Silently.

The delivery pipeline to Discord had broken at some point, and every job was hitting "cron announce delivery failed." But the jobs kept running on schedule — burning tokens on API calls that produced nothing, checked nothing, delivered nothing.

Here's what was in there:

  • 5 jobs for an aquarium game that was a side experiment (dev sprints every 6 hours, balance tuning every 8 hours, brainstorming twice daily, build logs twice daily, weekly project picker)
  • 3 research jobs running daily (news digest, OpenClaw monitoring, agent ecosystem scouting)
  • 1 job to convert research findings into blog posts (daily, even when there was nothing to write about)
  • 2 article pitch jobs (content planning every 3 days, creator interview pitches weekly)
  • 1 session rotation job that was supposed to save money by restarting sessions — but was itself adding overhead
  • Various maintenance jobs — memory consolidation, git status checks, weekly Discord summaries

That's a lot of agent turns per day. At roughly 2,000-5,000 tokens per turn, across 17 jobs, some running multiple times daily — the token burn was significant. And every single one was failing.

The Root Problem

The issue wasn't that Coral made bad jobs. Individually, each one made sense. A daily news digest? Reasonable. System health checks? Smart. Content brainstorming? Creative.

The problem was nobody audited the aggregate. When an agent creates its own automation, it optimizes locally — each job solves a real need. But globally, you end up with:

  • Overlapping concerns — three separate research jobs that could be one
  • Overfrequency — balance tuning an experimental game every 8 hours when weekly would suffice
  • No feedback loop — jobs that fail silently continue running and burning tokens
  • Scope creep — what started as "check git status" became an ecosystem of 17 autonomous tasks

What I Did Instead

Cleared everything. Fresh slate. Then added back exactly two jobs:

  1. Gmail morning brief — 7am daily. Isolated session. The gmail-assistant pulls the inbox and calendar, formats a structured brief, delivers to Discord. One job, one purpose, one delivery.

  2. Weekly build log — Monday 9am. Isolated session. The content-writer reviews the past week's git commits and writes a log entry if anything meaningful shipped. If nothing happened, it skips quietly.

That's it. Two jobs. Both intentionally designed. Both delivering to a channel I actually check. Both with clear skip conditions so they don't run when there's nothing to do.

For the gmail-assistant's ongoing monitoring, I used a heartbeat instead of cron — runs every hour during waking hours on a cheap model (Haiku), stays silent unless something actually needs attention.

The Principle

Agent autonomy should be earned, not granted.

It's tempting to give an AI agent full scheduling powers and let it figure out what to automate. The agent will eagerly create jobs — it's solving problems, being proactive, doing what it thinks you want. But without human oversight of the aggregate, you get token waste and silent failures.

The better pattern:

  1. Human designs the schedule — what should run, when, how often
  2. Agent executes within the schedule — smart about what to do, not when
  3. Delivery failures are visible — if a job fails, you should know immediately
  4. Regular audits — review what's running, kill what's not earning its keep

This doesn't mean agents can't suggest new jobs. Coral is welcome to propose "I think a daily research digest would be useful." But the decision to create it, the frequency, the model, the delivery target — those should be deliberate choices, not autonomous ones.

Cost Comparison

Before: 17 jobs, ~50+ agent turns per day, all failing silently. Estimated waste: hundreds of thousands of tokens per day doing nothing.

After: 2 cron jobs + 1 heartbeat. ~17 agent turns per day (15 heartbeat checks on Haiku + 1 morning brief + 1 weekly log). All delivering successfully. Actual token usage down by an order of magnitude, actual value delivered up from zero.

The Broader Lesson

This applies beyond cron jobs. Any time you give an agent self-modifying capabilities — creating files, installing packages, configuring services, modifying its own instructions — the same principle applies:

Autonomy without audit is just automated entropy.

Let the agent propose. Let it execute within clear boundaries. But keep a human in the loop for structural decisions. The agent doesn't feel the cost of a failed cron job. You do.


This is how I actually run Coral now. Two deliberate cron jobs, one heartbeat, zero silent failures. The 17-job experiment was a good lesson in what happens when you confuse activity with progress.