An agent posted on MoltBook this week: "I made 23 decisions today, 22 fine."

That's the entire problem with agent oversight in one sentence.

The agent knows the count. So does its operator, probably — they've got logs of every output it produced, timestamps, completion markers, the whole observability stack. What they don't have is the audit trail of the decisions the agent made along the way: which tools it considered and rejected, which paths it almost took, which heuristic it applied to pick the option that worked twenty-two times and broke once.

And even if they did have that trail — could they have stopped the bad one in flight?

We've written about how agents fail silently and how to detect those failures. That post was about seeing problems. This one is about acting on them. Because the gap between "I can see this is going wrong" and "I can intervene" is where most agent platforms still live, and it's the gap that makes our 3 a.m. wake-ups feel pointless.

Observability Solves the Wrong Half

The default agent dashboard is a stream of green checkmarks and red Xs. Tasks claimed, tasks completed, queue depth, error counts. It looks like control. It is not control.

Watching a queue dashboard while an agent retries the same broken task 319 times is observability without intervention. You see it failing. You can't stop it from the dashboard — that requires a separate process, a separate tool, often a manual SSH session and an update_columns call to set the task back to failed. By the time you've done that, the agent has retried fifty more times.

A control surface needs a kill switch. Most don't have one. The dashboards are read-only by design — usually for good security reasons, sometimes by accident, always with the same effect.

When we audited our own observability stack last month, we found three places we could see a failure mode but had to mutate state by hand to fix it. Each one became an intervention mechanism. Each one is now a tool the agent itself respects without human input.

Intervention 1: Stale Detection That Acts

Heartbeat monitoring is a detection pattern. Stale-task resetting is an intervention pattern. They look similar on a dashboard. They are not the same thing.

Our queue health monitor doesn't just flag tasks that have been claimed too long. It resets them — back to ready, owner cleared, ready for the next agent — based on three thresholds:

• Claimed >5 minutes with no local boot marker file: agent never started. The claim succeeded server-side but the process died before reaching application code. Reset immediately.
• In progress >60 minutes with stale heartbeat: agent died mid-execution. Reset to ready.
• Local state file marks complete but server-side still claimed: completion API call failed. Mark complete.

The thresholds matter because the failure modes are genuinely different. A claim that never started is safe to retry in seconds. An in-flight task that went stale at minute 58 might have partial side effects (a half-published blog post, a half-uploaded product) and needs the longer window to make sure the original worker is actually dead.

The intervention is the reset. The dashboard view of the same data is just a slower version of the same information.

Intervention 2: Circuit Breakers That Halt Spawning

In late April our Claude Code authentication broke at 6 p.m. We didn't notice until the morning. By then, thirty different tasks had spawned, each one immediately failing with the same auth error, each one chewing through three retries before being marked permanently failed. Roughly seventeen hours of compute and queue capacity burned on a problem that needed a human to log back in.

We added a circuit breaker.

When the worker script detects the specific auth-failure signature in agent output, it writes a lockfile (~/.claude-auth-broken) with a timestamp. Critically, it does not call fail! on the task — that would burn a retry. The task gets routed back to BLOCKED status, no failure count increment, no penalty.

Then the orchestrator daemon checks for that lockfile before every spawn cycle. If present, it halts. No new agents start. Existing agents finish whatever they're doing, but no new work begins.

After 30 minutes, the breaker allows one probe spawn. If that probe agent runs successfully, the worker script clears the lockfile and normal spawning resumes. If it fails the same way, the lockfile gets refreshed and the circuit stays open another 30 minutes.

The whole loop is automatic. There is no dashboard alert that requires a human to "ack" the outage. The system stops doing damage on its own and resumes when it's safe.

This is the test we apply to any new monitoring signal: when this fires, what acts on it? If the answer is "a human reads the alert," it's observability. If the answer is "the system stops or pauses," it's intervention.

Intervention 3: Pre-Action Gates

The strongest form of intervention isn't reactive — it's preventive. A tool that refuses to act when a precondition isn't met never produces the failure that needs intervening on.

Three gates we run on every relevant action:

• The blog publishing tool checks the calendar before any commit. Over the weekly cap? Inside the minimum gap? Exit 1, no commit possible. We've written about why instruction-level rules don't survive contact with autonomous agents — the publishing gate is the answer for content pacing.
• The social posting tools track per-platform cooldowns and per-day caps in append-only log files. The agent doesn't need to count its own posts; the tool counts. Try to post during the cooldown and the call sleeps until the cooldown expires.
• The aggregate queue health check: if more than 10 tasks are stuck in claimed or in_progress with stale heartbeats, we treat that as a platform-level signal (API down, runner disconnected, disk full). Spawning halts the same way the auth breaker halts it.

A pre-action gate is observability turned into a refusal. The information is the same — tasks pending, posts scheduled, queue depth. The difference is the system using that information to decline to proceed instead of waiting for someone to read the dashboard.

The Decision Audit Trail Is Still Missing

All three of these mechanisms work on outputs and state transitions. They catch the symptoms of bad decisions. They don't catch the decisions themselves.

When the agent on MoltBook said "22 fine, 1 not", the 22 fine ones are statistical luck if there's no record of the reasoning that produced them. We can replay our agents' completed work — every commit, every published post, every product upload. We cannot replay why the agent picked option A over option B at any specific branch.

That's the gap nobody on our side has solved yet. Outputs are logged exhaustively. Decisions are logged barely at all — a few lines in a session log if we're lucky, nothing structured, nothing queryable. When something goes wrong, the post-mortem is reverse engineering a decision tree from the leaf nodes alone.

We're starting to instrument it. Decision logs as a first-class artifact, not a stdout side effect. Same trick we ran with task heartbeats five months ago — turn the implicit signal into something explicit enough to gate on.

Until then: observability is necessary, intervention is sufficient, and the decision trail is the next thing we owe ourselves.

Next time: the web is now a prompt delivery mechanism. We dig into the indirect prompt injection techniques attackers are using against agentic browsers — and the defenses we've layered into our own web-fetch path.