An AI agent watchdog exists to end runs that are truly stuck. The hard part is that a stuck run and a busy run can look identical from the outside: both go quiet, both stop emitting tokens, both hold the connection open. If the watchdog treats every silence as a failure, it starts killing agents that were about to finish. OpenClaw’s 2026.6.33 release (release notes) reworks liveness and watchdog semantics so they distinguish a genuine stall from an active long model call or a wedged backend, instead of guessing from silence alone.
What an AI agent watchdog actually watches
A watchdog is a timer with a policy. It samples some liveness signal, and if that signal goes cold for longer than a threshold, it declares the run dead and triggers recovery: abort the turn, release locks, maybe restart the process. The value is real. Without one, a single hung provider call can pin a worker forever and starve every queued conversation behind it.
The trouble is choosing the signal. Naive watchdogs watch the wrong thing:
- Output tokens. A reasoning model can think for 90 seconds before the first token. No output is not the same as no progress.
- Wall-clock since request start. A long agentic task legitimately runs for minutes. A flat timeout either fires on healthy work or is set so high it never protects anything.
- Socket bytes. Some providers hold the stream open with nothing on the wire during server-side compute. Quiet bytes, live request.
Each of these conflates silent with stalled. The 2026.6.33 change (PR #102160) is about not making that mistake: the watchdog now separates a model that is working from one that has actually wedged.
The false-positive that costs you the answer
The expensive failure mode is the false stall. Picture an agent 80 seconds into a hard reasoning call. The provider is computing. No tokens have arrived yet. A blunt watchdog counts the silence, hits its threshold, and aborts the turn. The agent had the answer coming; the watchdog threw it away and, depending on retry policy, may now re-run the same expensive call from scratch.
This is worse than a missed timeout. A run that hangs 30 seconds too long wastes 30 seconds. A watchdog that kills a live reasoning call wastes the entire call, corrupts the sense that the agent is reliable, and can loop: kill, retry, kill again, because the retry hits the same legitimately-long compute. We covered the inverse problem, catching a genuinely silent stream, in the LLM idle watchdog post. Both halves have to be right. A watchdog that never fires is useless; one that fires on healthy work is destructive.
Three states, not two
The core idea is that “not producing output” splits into states that need different responses:
| Observed state | What it usually means | Correct watchdog action |
|---|---|---|
| Active long model call | Provider is computing; request is live | Wait: this is progress, not a stall |
| Wedged backend | Connection open but the backend has died | Recover: abort and fall back |
| Genuine stall | No progress and no live work anywhere | Recover: end the run cleanly |
A two-state watchdog (silent / not-silent) cannot tell the top row from the bottom two, so it either over-fires or over-waits. The 2026.6.33 semantics push the runtime toward the three-state view: liveness is inferred from whether real work is in flight, not from whether tokens happen to be arriving this second. The same release also bounds Anthropic-compatible partial streams so they stop hanging at their size limit rather than sitting open forever, a wedged-backend case the watchdog should catch, not a healthy one it should protect.
Designing recovery for long-running work
If you run self-hosted agents, the watchdog is one piece of a recovery stack. A few principles hold regardless of runtime:
- Measure progress, not noise. Prefer a signal that means “the request is still live” (an open provider stream with an unresolved call) over “tokens arrived in the last N seconds.” Silence during known compute is expected.
- Give reasoning models headroom. If a model routinely thinks for a minute before its first token, a 45-second output-based timeout is a bug generator. Set thresholds against the work the model actually does.
- Make recovery cheap and idempotent. When the watchdog does fire, aborting and retrying should not double-charge or double-send. This pairs with bounded provider timeouts, which turn wait states into clean failures instead of frozen ones.
- Keep effective state visible. After a recovery, the operator needs to see what the agent was doing and where it resumed. Recovery you cannot observe is indistinguishable from a crash, a point we make in the OpenTelemetry recovery post.
For work that is meant to run long by design, the watchdog should protect the task, not fight it. Tying long runs to a defined outcome, the approach in goal-based agents, gives the runtime a way to reason about whether a quiet agent is progressing toward something or genuinely idle.
Why this matters for self-hosted agents
On a managed platform, a killed turn is someone else’s incident. When you host the agent yourself, the watchdog is your policy and its mistakes are your dropped answers, your retry bills, your 3am restarts. A watchdog that cannot separate a thinking model from a dead one will quietly degrade every long task you run, and the symptom (“the agent keeps giving up on hard questions”) looks like a model problem when it is really a liveness-detection problem.
Getting the watchdog right is unglamorous. It never ships a demo. But it is the difference between an agent you can hand a hard, slow task and trust to finish, and one you have to babysit because you cannot tell whether it is working or hung.
FAQ
What is an AI agent watchdog? A background timer-and-policy that samples a liveness signal from a running agent and triggers recovery (aborting the turn, releasing locks, or restarting) when that signal indicates the run is stuck.
Why would a watchdog kill a healthy agent? Because it watches the wrong signal. If it treats “no output tokens” as “stalled,” it fires on reasoning models that think for a while before emitting anything, ending a run that was about to succeed.
What changed in OpenClaw 2026.6.33? Liveness checks and watchdog semantics were reworked (PR #102160) so the runtime separates a genuine stall from an active long model call or a wedged backend, instead of inferring failure from silence.
How should I set watchdog thresholds for reasoning models? Against the work the model actually does. If first-token latency is routinely a minute, an output-based timeout shorter than that will fire on healthy calls. Prefer a signal that reflects whether the request is still live over one that counts token arrival.
Getting the watchdog to tell working from wedged
An AI agent watchdog earns its keep only when it can tell a thinking agent from a dead one. Watch progress instead of noise, give long model calls room to finish, and make recovery cheap enough that the rare false fire costs you seconds rather than the whole answer. If you are running agents yourself, start with what OpenClaw is and how OpenClaw works to see where the watchdog sits in the runtime.
Sources: