Agent Reliability Playbook

Fixed structure, variable content

The #1 reliability killer: freeform generation. Your agent outputs something different every time, and eventually it produces garbage.

Instead of "Write a morning briefing", use a template with fill-in sections:

## Morning Briefing — {{date}}

### 🌅 Weather
{{weather_summary}}

### 📅 Schedule
{{calendar_events}}

### 📰 AI News
{{news_summary_3_items}}

### 📊 Markets
{{market_snapshot}}

The agent fills in {{variables}} instead of deciding the structure. Result: consistent output, every single time.

One API failure ≠ total failure

Your briefing needs weather, calendar, news, and market data. If the news API returns a 503, the whole briefing shouldn't die.

Wrap each data fetch in its own error handler:

def fetch_weather():
    try:
        return get_weather_data()
    except Exception as e:
        return "⚠️ Weather unavailable"

def fetch_news():
    try:
        return get_news_data()
    except Exception as e:
        return "⚠️ News unavailable"

The briefing still delivers — just with one section marked unavailable instead of the whole thing failing.

Scheduled cron + heartbeat redundancy

Your 6:40 AM cron fires the briefing. But what if the server was restarting at 6:40? You get nothing.

Add a heartbeat check: every 30 minutes, the agent checks "did the daily briefing run today?" If not, it runs it. Two independent triggers, either one works.

# Cron: 6:40 AM daily
schedule: { kind: "cron", expr: "40 6 * * 1-5", tz: "America/Denver" }

# Heartbeat: checks every 30 min, fires if briefing hasn't run
# Implemented as a systemEvent in the heartbeat cron

Result: even if the server restarts, the briefing catches up within 30 minutes.

Never crash silently

When a tool call fails, your agent has two choices: crash or continue. Always continue — but log the failure for debugging.

• Each tool failure gets logged with timestamp, tool name, and error
• The daily output includes a brief "issues" section if anything failed
• A daily cron health check surfaces consecutive failures

My health monitor runs every 6 hours and reports if any cron has failed 3+ times in a row. That's how I caught a silently broken API key that had been failing for 2 days.

One .env file, isolated keys

When you have 12 API keys and one expires, which one broke the workflow?

Structure your config so each integration has its own labeled section:

# .env
# --- Weather ---
OPENWEATHER_API_KEY=...

# --- News ---
BRAVE_API_KEY=...
GNEWS_API_KEY=...

# --- Calendar ---
GOOGLE_CALENDAR_CREDENTIALS=/path/to/creds.json

When something breaks, grep -i "KEYWORD" ~/.openclaw/.env tells you exactly which key to rotate.

Briefings should be brief

Your agent will happily produce 5,000 words if you let it. Telegram has message limits. Your attention has limits.

Hard constraints in the skill definition:

## Output Rules
- Total output: under 800 words
- Each section: 3-5 bullet points max
- Weather: 2 sentences
- News: 3 headlines, 1 sentence each
- Markets: numbers only, no commentary

This also saves token cost. A constrained briefing costs $0.02 instead of $0.15.

Automated self-monitoring

You won't notice your agent is broken until you wonder "why didn't I get my briefing today?"

Set up a health check cron that runs independently and reports:

• Which crons ran today
• Which ones failed
• Consecutive failure count
• Recommended action ("API key may need rotation")

This runs as its own cron job — separate from the automations it monitors. It's the agent watching the agent.