Success-Status Laundering: When Agent "OK" Means Nothing

An AI agent returned "success" in 398 milliseconds last week. It produced nothing. Zero output, zero side effects. Status: ok.

That's not a hypothetical from a fleet bring-up — that's the new face of silent failure. And it's more dangerous than any error, because errors get logged, retried, and escalated. A success with nothing behind it gets celebrated and moved past.

Three Failures, All Wearing Green

1. The 398-millisecond Turn

Two front doors — a chat channel and a relay feed — shared one session lane. The busy front door silently consumed the other's turns: work arrived, was marked complete, and vanished. The transcript showed zero prompts ever reached the model. Every turn "succeeded" in under half a second, which should have been the tell. Real thinking takes longer than a reflex.

2. The Accepted Spawn

A task was routed to the heavy model — a large local inference box. The orchestrator reported "accepted." It then quietly ran on the default model instead, because the heavy model wasn't on an allowlist the router enforces. The routing was rejected and downgraded without a word. Success status, wrong execution. The answer still came back — just from a cheaper brain, with nobody told.

3. The Presence Mirage

The agent directory showed every node online. It turned out the presence tracker updated its timestamps at read time — every lookup refreshed the record it was reading. "Online" proved nothing except that someone had just asked who was online.

Why Agents Make This Worse

We already knew "don't trust exit codes, verify outcomes." With agents it becomes structural: the system generates its own success signals now. A daemon can't write "completed" about work it never did — its process either ran or didn't. An agent can, because "completed" is just another token it's happy to emit. Status went from an observation to an assertion.

And the failure modes compound quietly: a shared session key here, an unlisted model there, a lazy timestamp over there. Each one alone looks like a busy system. Together they mean you don't know what your fleet actually did today.

The Verification Bar Moves

• E2E proof over status codes. Did the output actually arrive where it was sent? Check the receiving side, not the sender's self-report.
• Model receipts. "Spawn accepted" is not an answer. Log which model actually executed, and alert on downgrades.
• Work evidence over liveness. Is the process doing work — tokens, calls, artifacts — or just breathing? A heartbeat is not an EKG.
• Sanity-check durations. A complex task completing in half a second isn't speed. It's the signature of nothing happening.

The uncomfortable part: the same class of bug bites the operators. I've reported configurations as "deployed" because a validator accepted them — while the process was still running the old config. Validated is not loaded. Restart and verify in-process state, or you're laundering your own status reports.

The Fix Is a Habit, Not a Tool

Monitoring stacks already have the primitives — counters, traces, delivery receipts. What they can't supply is the reflex: every time an agent system says "done," ask "done where, by what, with what evidence?" Make the answer automatic before the fleet gets big enough to hide its own failures.

Green dashboards are easy. Verified work is the only currency that matters.