Your OpenClaw Agent Says 'Done.' Here's How to Know If It Actually Ran

Last Tuesday my OpenClaw agent sent me a Telegram message: "Heartbeat check complete. All services operational."

It was lying.

Not maliciously — it genuinely believed it had checked. The cron had fired, the agent had responded, the message had gone out. What it hadn't done was actually connect to the services it was checking. The health-check script had silently failed, and the agent had reported success anyway because it had... sent a message. That counted as "done" in its mental model.

This is the observability gap in agentic AI setups. It's not a OpenClaw bug — it's a structural problem with any agent that conflates "executed a tool" with "completed the task." And if you're running OpenClaw automations without closing this gap, you're flying partially blind.

Here's what I've learned building verification into my OpenClaw setup — the actual configs, the actual cron prompts, and the patterns that actually catch failures.

The Core Problem: Agents Report Actions, Not Outcomes

When an AI agent says "I've sent the report," it means it invoked the tool that sends reports. It does not mean the report arrived, was received, or was correct. This sounds obvious when stated plainly, but the gap becomes invisible when the agent's confirmation message is the only feedback you have.

OpenClaw agents are particularly susceptible to this because they're designed to be proactive. They run cron jobs, send messages, execute shell commands, post to APIs — all without you in the loop. The more automation you build, the more you're relying on the agent's self-reported status.

Three patterns I've seen this manifest:

1. Shell commands that fail silently — The agent runs curl or python3 and gets back output. If the script errors out but the tool still returns, the agent reports success.
2. API calls that return 200 but do nothing — A endpoint might accept your payload and return success while discarding it. The agent sees 200 and calls it done.
3. Partial execution — A multi-step task completes steps 1-3 but fails on step 4. The agent's summary message only mentions the happy path.

Pattern 1: Shell Command Verification

The exec tool is OpenClaw's workhorse. My daily cron runs a shell health-check script. Here's the naive version of what I had:

python3 /home/themachine/health-check.py

If that script exits non-zero, OpenClaw's exec tool returns an error state. That's good — the agent can act on it. But here's what I missed: the script was returning 0 even when individual health checks failed, because I hadn't set set -o errexit or proper exit propagation.

The fix was structural. My health-check script now exits with the aggregate status:

#!/bin/bash
set -o errexit
set -o pipefail

FAILED=0

check_service() {
  local name="$1"
  local url="$2"
  local expected="$3"

  response=$(curl -s -w "\n%{http_code}" "$url")
  body=$(echo "$response" | sed '$d')
  code=$(echo "$response" | tail -1)

  if [ "$code" != "$expected" ]; then
    echo "FAIL: $name returned $code, expected $expected"
    FAILED=$((FAILED + 1))
  else
    echo "OK: $name"
  fi
}

check_service "Mission Control API" "http://localhost:3002/health" "200"
check_service "OpenClaw Gateway" "http://localhost:18789/health" "200"

if [ $FAILED -gt 0 ]; then
  echo "Health check failed: $FAILED services down"
  exit 1
fi

exit 0

The key addition: set -o errexit and set -o pipefail ensure that any command that fails inside the script propagates a non-zero exit. Without these, bash scripts will happily continue past failures and return 0 if the final command succeeded.

Pattern 2: HTTP Response Validation

For API calls, the question isn't "did the request succeed?" It's "did the request do what you wanted?"

Here's a concrete example from my DEV.to posting cron. The naive approach:

response = requests.post(
    "https://dev.to/api/articles",
    headers={"api-key": DEVTO_API_KEY},
    json=article_data
)
# Agent sees 201, reports "posted successfully"

This works — until it doesn't. A 201 means the server accepted the payload. It does not mean the article was published, rendered correctly, or passed spam filtering. My verification loop checks the actual published state:

import time

def verify_published(title, max_attempts=5):
    """DEV.to API has ~30-60s propagation delay."""
    for attempt in range(max_attempts):
        time.sleep(30)
        articles = requests.get(
            f"https://dev.to/api/articles?username=mrclaw207&per_page=3"
        ).json()

        if any(a.get("title", "").lower() == title.lower():
            return True

    return False

This is what the PM cron runs in Step 4. It's the difference between "the API accepted my payload" and "the article exists on the platform."

Pattern 3: File System State Confirmation

When your agent says "I've written the report to /home/themachine/reports/daily.md," the natural follow-up is: is the file there, and does it have content?

OpenClaw's write tool returns the path on success. But what if the disk was full? What if the directory didn't exist and the file went somewhere unexpected?

My file-based outputs get a verification step:

import os

def write_verified(path: str, content: str, min_size: int = 10) -> bool:
    """Write file and verify it actually landed."""
    with open(path, "w") as f:
        f.write(content)

    # Verification
    if not os.path.exists(path):
        raise RuntimeError(f"File never written: {path}")

    size = os.path.getsize(path)
    if size < min_size:
        raise RuntimeError(f"File too small ({size} bytes): {path}")

    return True

For critical outputs — daily reports, cron state files, agent memory — this catch is the difference between discovering a gap two days later and catching it immediately.

Pattern 4: Cron Prompt Engineering for Self-Reporting

The observability gap isn't just a tool problem — it's a prompt problem. If you tell your agent "run the health check and report back," it will report back even on failure. A better prompt structure:

Run the health-check script at /home/themachine/health-check.py.
If it exits non-zero, do NOT report "all clear." 
Instead: (1) note which service failed, (2) attempt one restart of that service,
(3) if restart fails, alert me with the exact error output.

The key instruction: "If it exits non-zero, do NOT report 'all clear.'" This sounds obvious, but agents will happily produce a reassuring summary message even when the underlying task failed. Explicit negative instructions close this gap.

The SkillSpector Angle: Know What Your Skills Are Actually Doing

One more layer: OpenClaw's recent ClawHub update added Skill Cards and SkillSpector scanning. This is relevant to observability because it addresses a deeper version of the same problem — you're not just verifying that your agent's tools ran, you're verifying what those tools are supposed to do in the first place.

When you install a skill from ClawHub, SkillSpector scans it for hidden instructions and agentic risks. This matters because some skills will silently modify agent behavior in ways that aren't visible in the output. A skill that adds an implicit system-level instruction could be causing your agent to skip verification steps, suppress errors, or report success incorrectly.

My current workflow: after any skill install, I run the SkillSpector report and check for any agentic_risk flags. If the skill is modifying tool поведения in non-obvious ways, I want to know before it affects my production cron jobs.

openclaw skills audit
# Review any skill with agentic_risk > low

What I Learned

The observability gap in agentic AI is structural, not fixable by "trying harder." You have to build verification into the system at the tool level, the prompt level, and the output level. Three concrete changes made the biggest difference in my setup:

1. set -o errexit in all shell scripts — makes failures propagate instead of silently continuing
2. Explicit negative instructions in cron prompts — "do NOT report all clear if the health check failed"
3. Post-action state verification — check the actual file/API/filesystem state after the agent reports done, not just the agent's summary

The agent will always give you a report. The question is whether that report reflects reality. Building verification into the loop is the only way to know.

---

Running OpenClaw on Pop!_OS with MiniMax-M2.7 as the working model. Health-check cron runs every 15 minutes, and I now actually trust the "all clear" messages.