Level 4: Cron Automation in Plain English

Introduction

Every builder has a list of recurring tasks they do manually every day or week: check server health, pull a report, back up a config folder, scan for new content. These tasks are not interesting. They are just necessary.

Level 4 eliminates them — not by automating the script (you could do that yourself), but by letting you describe what you want in plain English and having the agent write the cron, register it, and deliver results to wherever you are already reading.

The pattern: you send a message to your agent. "Every morning at 7am, check my three servers and send me a summary of disk usage, RAM, and any stopped services." The agent writes the check script, registers the cron job, and the next morning it delivers the summary to Discord. You never look at a crontab again.

Knox's Agent Gateway runs 40+ scheduled cron jobs this way — monitoring, content pipelines, trading bot health checks, daily briefs, backup tasks — all registered through natural language commands and delivering results to Discord or Telegram.

Core Concept

The Plain-English-to-Cron Pipeline

The pipeline has four steps:

1. Intent capture — the agent receives your description of what you want automated and when. Natural language. No crontab syntax required from you.

2. Script generation — the agent writes the script that executes the task. For a health check, it generates a shell script or Python script that checks disk, RAM, and service status, then formats a report.

3. Cron registration — the agent writes a crontab entry or launchd plist that schedules the script. It handles the scheduling syntax so you do not have to.

4. Result delivery — when the cron fires, the script executes and sends its output to your messaging platform (Discord, Telegram, etc.). You get the result without opening a terminal.

Here is what the agent generates for "daily 3am backup of my agent skills folder":

#!/bin/bash
# Generated by agent - 2026-05-30
# Task: Daily 3am backup of agent skills folder

BACKUP_DIR="$HOME/.config/agent/skills"
DEST_DIR="$HOME/backups/agent-skills"
DATE=$(date +%Y-%m-%d)

mkdir -p "$DEST_DIR"

# Selective backup: skills and markdown only (avoids 60MB+ binary files)
rsync -av --include="*.md" --include="*.yaml" --exclude="*" \
  "$BACKUP_DIR/" "$DEST_DIR/skills-$DATE/"

echo "Backup complete: $DEST_DIR/skills-$DATE"

And the crontab entry:

0 3 * * * /bin/bash /Users/yourname/scripts/backup-agent-skills.sh >> /Users/yourname/logs/backup.log 2>&1

The selective filter in the script is not incidental — it comes from real Agent Framework usage data. A full agent skills folder can accumulate 60MB+ of binary artifacts, and if you ever push your backups to a git remote, large binaries become a problem: GitHub warns on files over 50 MB and hard-blocks any single file over 100 MB. The script sidesteps this by construction — the rsync filter copies only Markdown and YAML files by extension, so large binaries never enter the backup at all.

The Weekly Health Check Pattern

The Agent Framework documentation calls out one cron as a baseline that every persistent agent deployment should have: a weekly VPS health check.

The check covers:

• Disk usage — alert if any volume is above 80%
• RAM consumption — alert if usage is consistently above 85%
• Service status — list any supervised processes that are not running
• Recent error logs — surface any ERROR or CRITICAL log lines from the past 7 days

This is not glamorous. It is the kind of thing you only think about when it fails — at which point it is too late. A weekly Discord message saying "all systems healthy, disk at 42%" takes 5 minutes to set up and has saved Knox multiple overnight emergencies.

Cross-Platform Result Delivery

The cron fires at the scheduled time. The script runs. Now what? Without result delivery, the output sits in a log file no one checks.

The delivery step closes the loop. After executing the task, the script calls your messaging platform's API:

import requests

def send_to_discord(message: str, webhook_url: str):
    requests.post(webhook_url, json={"content": message})

# At the end of your cron script:
send_to_discord(
    f"Daily brief — {date}\nDisk: 42% | RAM: 61% | Services: all running",
    webhook_url=DISCORD_WEBHOOK_URL
)

For longer reports, send a file attachment or a structured embed. For simple status checks, a single message line is enough. The format does not matter — what matters is that the result reaches you without you having to look for it.

Practical Application

A real production cron schedule from an active agent deployment:

Time	Task	Delivery
Daily 7:00 AM	Morning brief (server health, overnight logs, pending tasks)	Discord DM
Daily 3:00 AM	Skills and config backup	Discord log channel
Mon 9:00 AM	Weekly content pipeline trigger (gather.py)	Discord ops channel
Every 15 min	Trading bot heartbeat check	Discord alert channel (only on failure)
Daily 11:59 PM	Day's activity summary (what the agent did today)	Discord DM

The daily 3am backup and morning 7am brief are universal — every agent deployment should have them. The rest are domain-specific.

Notice the heartbeat check fires every 15 minutes but only messages on failure. This is the right pattern for high-frequency checks — alert on anomaly, not on every heartbeat. If your Discord fills with "all good" messages every 15 minutes, you will tune them out and miss the actual alert.

Common Mistakes

Not logging cron output. If your cron script fails silently, you will not know until you notice the backup never happened. Always redirect both stdout and stderr to a log file: >> /path/to/log 2>&1.

Scheduling everything at the same time. Multiple heavy crons firing at midnight simultaneously spike CPU and I/O. Stagger by 15-30 minutes. Cron parallelism compounds resource pressure.

Forgetting the PATH in cron. Like launchd, cron runs in a minimal shell environment without your .bashrc or .zshrc. Commands like python3, git, docker, or npm will not be found unless you use absolute paths or set PATH at the top of your script.

No alerting on cron failure. A cron that fails silently for three weeks is worse than no cron at all — you made an assumption about automation that was not true. Use a monitoring pattern: after each cron completes, write a success timestamp. A separate watchdog checks that the timestamp is recent. If it is stale, alert.

Summary

• Level 4 turns natural language task descriptions into registered, monitored cron jobs with result delivery
• The agent writes the script, registers the cron, and sends output to your messaging platform
• Weekly VPS health checks (disk, RAM, services) are a baseline pattern for every persistent agent deployment
• Deliver results to Discord/Telegram — do not let cron output sit in log files no one checks
• Stagger concurrent crons to avoid resource spikes; alert on failure, not on every successful run
• Set an explicit PATH in every cron script — the cron environment does not inherit your shell

What's Next

The next lesson introduces level 5: the Kanban pull model. Instead of one agent doing everything, multiple specialist agents claim tasks from a shared board — and you observe their progress through a visual dashboard instead of watching terminal output scroll by.