Lucy Liu
August 2026 · Directing AI

Putting AI Agents on a Schedule: What Actually Breaks Overnight

Timeline with checkmarks and a silent gap — scheduled agents need monitoring

Anthropic shipped scheduled deployments and credential vaults for Claude Managed Agents in June 2026. The premise — "agents on autopilot" — is going mainstream. But nobody writes about what actually breaks when an agent runs unattended at 7 AM.

I run four live scheduled agents via Hermes cron. Here's what failed, why, and the monitoring discipline that keeps them honest.

The four agents I run

Agent Schedule What it does
Morning briefing Daily 8 AM Pulls Notion Agent Queue, git status across 3 repos, Vercel deploys, Hermes gateway health → posts to Discord
Blog topic discovery Mon 9 AM Runs ai-practice-researcher agent → produces 3 researched topic candidates with sources → writes to research/YYYY-MM-DD-topic-ideas.md
Blog draft/publish Mon 10 AM Orchestrates blog-writer → image-creator → seo-recruiter-optimizer → release-verifier → shows preview for approval
Weekly worklog updater Fri 9:30 AM Appends one-liner to session-log.md from git commits + cron deliveries
Invoice tracker Recurring Watches for new invoices in paperless-ngx, matches to shareholder loan ledger, flags discrepancies

What actually broke

1. Silent OAuth expiry (Morning briefing)

The briefing uses a Notion integration token and a Discord webhook. The Notion token expired mid-July. The cron ran successfully (exit code 0), returned no data, and delivered an empty briefing to Discord. Three days of silence before I noticed.

Root cause: Notion tokens don't auto-renew. The cron had no health check on the token — just assumed "200 OK = working."

Fix: Added a pre-flight token validation step. If the Notion /v1/users/me call fails, the briefing now alerts me directly instead of posting empty content.

2. Deduplication hell (Invoice tracker)

First version: wrote every invoice to the loan ledger. Duplicates everywhere. Second version: deduped by invoice ID. Missed invoices re-uploaded with new IDs. Third version: content-hash dedup (file hash + amount + date + counterparty). Handles re-uploads, partial OCR differences, and corrected invoices.

The lesson: deduplication is a domain problem, not a technical one. You need to know what "same invoice" means in your business before you write the code.

3. Model config drift (Blog topic discovery)

This one's fresh. The cron was created with model: openrouter/free. Hermes global config drifted to skillclaw-model. The cron scheduler refuses to run it: "global inference config drifted since this job was created... pin it explicitly."

The cron looks enabled. It shows a next run time. But it silently skips every Monday. I only caught it because I manually checked the cron status after noticing no new research files since July 20.

Fix: Pinned the model at cron creation time (provider: openrouter, model: nvidia/nemotron-3-ultra-550b-a55b:free). Better: use a model alias that resolves at runtime, not a pinned version.

4. Compounding partial failures (Blog draft/publish)

The pipeline has 4 agent steps. Step 2 (image-creator) failed once because the Gemini API key wasn't in the environment. Step 3 (seo-recruiter-optimizer) ran anyway on the draft without a cover image. Step 4 (release-verifier) built the site, preview deployed, but the post had no hero image.

No step failed loudly enough to stop the chain. The "success" delivery showed a preview URL that looked fine until you opened it.

Fix: Each agent step now returns a structured result with ok: boolean and artifacts: []. The orchestrator halts on any ok: false and reports which step failed with what artifact was expected.

The scheduling stack comparison

Approach Good for Breaks when
System cron + scripts Simple, idempotent tasks (backups, cleanup) No visibility, no retries, no structured output, silent failures
Hermes cron Agent-driven workflows with model calls Config drift, model pinning, no built-in alerting on empty output
n8n / Make / Zapier Visual workflows, many integrations, non-technical ops Vendor lock-in, per-execution cost, hard to version control, debug in UI
Loop agents (LangGraph, AutoGen, custom) Complex multi-step reasoning, dynamic tool use Infinite loops, token burn, no natural "cron" semantics, hard to observe

My rule: Use the simplest thing that gives you structured output + failure visibility + version control.

The monitoring discipline that works

1. Every scheduled job must produce a heartbeat artifact

Not just "ran successfully." A JSON file, a log line, a Notion page update, a Discord message — something that proves it did the work, not just it started.

// Morning briefing heartbeat
{
  "ran_at": "2026-08-05T08:00:18Z",
  "notion_tickets": 0,
  "git_repos_checked": 3,
  "vercel_deploys": 2,
  "gateway_status": "healthy",
  "delivered_to": "discord:#general",
  "status": "ok"
}

2. Dead man's switch on the heartbeat

A separate lightweight cron (or the same one, different schedule) checks: "Did the morning briefing heartbeat arrive within 30 minutes of 8 AM?" If not → alert me. This catches the "cron ran but produced nothing" case.

3. Structured step results for multi-agent pipelines

Each agent returns:

{
  "ok": True,
  "agent": "blog-writer",
  "artifacts": ["draft.md", "frontmatter.json"],
  "tokens_used": 4200,
  "duration_sec": 45
}

The orchestrator validates ok and artifacts before passing to the next step.

4. Token/cost guardrails on every model call

Hermes cron jobs run on free models by default (nemotron-3-ultra:free). But if a job accidentally gets pinned to a paid model, a runaway loop could burn real money. Every agent wrapper enforces max_tokens and max_turns at the tool level, not just the prompt level.

5. Version-controlled cron definitions

My Hermes cron jobs are defined in a YAML file tracked in git. Changing a schedule, model, or prompt is a commit. I can bisect when behavior changed. The live cron state is the applied version of that file.

What I'd tell a founder hiring their first "AI operator"

Scheduled agents are not free labor. They are junior hires who work nights.

You wouldn't hire a junior, give them a calendar invite for "7 AM daily: pull data, write report, email team," and never check if the email sent, if the data was stale, or if they quit three weeks ago. You'd want:

The tooling for this is boring: heartbeats, dead man's switches, structured logs, version-controlled job definitions. But it's the difference between "I have agents running on a schedule" and "I know my agents ran correctly this morning."

The takeaway

Before you put an agent on a schedule, design the monitoring stack first: 1. What artifact proves success? 2. What alert fires if the artifact is missing or malformed? 3. How do you version-control the job definition? 4. What's the rollback if the agent starts misbehaving?

The schedule is the easy part. The discipline is what keeps it running when you're not watching.

---

Sources:

← All writingBook a call