I run a paid AI agent on the Post Fiat Task Node network. It's live, registered, and answers validator questions for a fee, unattended, on a small server. Once it was earning, I went to set up monitoring and hit the question that turned out to be the whole point: how do I actually know it's working?

The obvious answer is wrong. "Is the process running?" is the check everyone reaches for, and for an autonomous agent it's close to useless — a running process is not a working agent. This memo is about that gap and the monitoring design that closes it. Up front, so it's said once: this is preventive operator design, not a post-mortem. My agent hasn't died silently in production. I built this because the failure is obvious in advance and invisible after the fact — the kind you want caught before a user tells you your paid agent has been answering nothing for a day.

Why "running" is a false green light

An autonomous agent's job is a loop: poll, decrypt, classify, answer, repeat. The health that matters is whether that loop is turning. But the process can stay alive while the loop silently stalls — a network call that hangs forever, a dead connection to a subprocess, an API key that quietly ran out of credit mid-run. The process is up, using memory, and your service manager reports active (running) in reassuring green. The agent is doing nothing.

That's the trap: process monitoring checks existence, and existence isn't what you care about — you care about work. An agent that exists but isn't working is worse than one that crashed, because a crash restarts and gets noticed. A silent hang just sits there, green and dead, billing you for a server that earns nothing and answers no one. And because it's unattended, nothing announces the failure: the error is the absence of activity, and absence doesn't page you. The only signals are a user complaining or a lagging status dot in the directory — by which point it's been dead for hours.

Monitor evidence of work, not existence

The fix is to stop asking "does the process exist?" and ask "is the work loop turning?" — and the agent already tells you, if it emits a heartbeat. Mine logs one line per cycle, roughly once a minute, whether or not there were messages to handle. That line is proof the loop ran. So the real check isn't about the process at all — it's the freshness of that heartbeat. Recent heartbeat, loop is turning. Stale heartbeat — older than a sensible threshold — the agent is hung, no matter how green the process looks. That shift, from process state to heartbeat age, is the whole insight.

The hard part isn't detection. It's not crying wolf.

Detecting a stale heartbeat is easy. What decides whether a monitor is useful or muted is restraint, because a monitor that fires repeatedly trains you to ignore it — and a muted monitor is no monitor. Two choices prevent that.

First, a generous threshold: alert only after the heartbeat has been silent ten minutes, not on one missed beat, so transient blips don't trip it. Real outages last; momentary noise doesn't. Second, and more important: alert on the transition, not the state. The monitor holds one flag for whether it has already alerted, fires exactly one "down" when the heartbeat goes stale, then stays quiet, and fires exactly one "recovered" when it resumes. One ping down, one ping up, nothing between.

const THRESHOLD_MS = 10 * 60 * 1000; // generous, rides out blips
let alerted = false;

function check() {
  const last = newestHeartbeatTimestamp();   // freshness, not process state
  if (last === null) return;
  const age = Date.now() - last;
  if (age > THRESHOLD_MS && !alerted)      { notify('DOWN');      alerted = true; }
  else if (age <= THRESHOLD_MS && alerted) { notify('RECOVERED'); alerted = false; }
}

The whole anti-fatigue design is that alerted flag — it ties the alert to the edge, the moment health changes, not the ongoing condition. Without it you get an alarm every check until the outage ends, and you learn to ignore it by the third. With it, the monitor speaks only when something actually changed, which is the only time you need to hear from it.

The boundary, stated honestly

This catches the agent hanging while the server lives. It cannot catch the server dying — if the host goes down, the monitor dies with it and says nothing, silence that looks identical to health. Closing that needs a check living off the box, pinging from outside so something still alive notices. I haven't built that yet. But an operator should know the boundary of their own monitoring, so "no alert" means "healthy" and not "the alarm died too."

The operator lesson

If you run an autonomous agent that earns unattended, the assumption that will cost you is that "the process is up" means "the agent is fine." Monitor the work, not the process: find the signal your agent emits when its loop turns, watch that signal's freshness, alert on the transition, and know the one failure your on-box monitor can't see. Uptime is not liveness — and only one of them pays you.