Agent READY, Usage 0%: When the Wiring Lies

The agent reported READY. The provider dashboard reported 0% usage. Both signals came from the same run.

If you had asked me that day whether the pipeline worked, I could have given you two confident answers depending on which screen I was looking at. The incident forced a distinction I now treat as non-negotiable whenever I orchestrate models: wiring, dispatch, and substantive inference are three different claims, and only one of them is a result.

What I was building

At the time I was running a delegation pipeline for implementation work: a root planner handing bounded tasks to sub-agents, each with a custom agent type, a fixed model per role, and a self-contained brief — objective, non-goals, target files, verification criteria. An experimental provider was wired in for implementation experiments, and the runner validated every returned diff against an exact file allowlist, running git apply --check before anything touched the workspace.

On paper, the setup had everything a serious delegation pipeline needs. What it did not have yet was an answer to a simpler question: how do I know inference actually happened?

What was breaking

During a run, the agent reported READY while the provider usage meter stayed at 0%. Nothing had crashed. No error was thrown. By every signal the system produced, the round-trip looked successful.

READY is a real signal, but a narrow one. It says initialization completed and basic dispatch happened. It does not say that any token was billed or that any model weight was ever queried. The risk I logged after the incident says it plainly: confusing wiring, dispatch, and substantive inference lets a successful network call hide the fact that no inference ran.

The same experiment surfaced a second failure mode, one level deeper. A session reported that generic agents had inherited the root planner’s model, and the weekly usage meter kept burning down while the work meant for the experimental provider ran on the wrong one. Sending another message to an already-created agent does not migrate its model — I have to note that this second incident is user-reported, with no logs preserved, so I treat it as a report, not a trace. But the shape of the failure is the same: a signal from one layer, standing in for proof at another.

Diagnosis

The correction started with naming the layers and what each one’s proof looks like:

• Static configuration. The runner declares the model and endpoint and requires the API key. This proves wiring — nothing more.
• Dispatch. The runner received the brief with an exact allowlist, or the native call used an explicit agent type. This proves the task was handed to the right role.
• Inference. The provider returned usage and a verifiable output — a diff that validates against the allowlist. This proves work happened.

Measured against those levels, a READY response covers level one and part of level two. It does not demonstrate tokens consumed or billing. And the failure cuts both ways: if the API key is missing, the dispatch is unproven, and the documented protocol is to report the exact error and not invent a provider confirmation in either direction. No invented green when signals are missing, no invented red when they are green.

The correction

The fix was one verifiable call. The usage meter moved from 0% to 1%.

One percent is the least impressive number I have ever been happy to see. It is also the only number in that pipeline that cannot exist unless inference ran. From then on, verification per level became the rule: smoke tests with dated markers per level, recorded evidence per level — the logged verification of that pipeline used explicit markers so that wiring, dispatch, and inference each had their own dated proof.

The rule the incident left behind, nearly verbatim from the case file: separate wiring, dispatch, and substantive inference. A green status is not a result until each layer is observed independently.

The general rule

You do not need my pipeline to use this. If you orchestrate models — agents, evaluators, multi-step chains — the rule transfers as three questions per layer:

• What does this layer’s green signal prove?
• What would falsify it?
• What number moves if real work happens?

Then observe the layers independently, at least once, per configuration change. A configuration is proven at the level you observed, and no higher.

Two cautions come straight from the case file. First, a single observed response does not prove the model produces useful output — the call that moved the meter to 1% proved inference ran, not that the result was good; that is what diff review and audits are for. Second, evidence is dated per level: a proof from a previous runtime version does not automatically transfer when the runtime updates. Re-run the cheap checks before you re-trust the expensive ones.

When this rule does not apply

Honesty about scope, because this pattern can decay into ceremony:

• If you call a single provider directly with one synchronous request and you actually read the response body, you do not need a dispatch ledger. Three-layer separation earns its keep when the layer that reports success is not the layer that does the work.
• Layer separation does not replace verification. It tells you inference ran; only reading the output tells you it was worth running.
• And it is not an excuse to distrust cheap signals entirely. READY is genuinely useful — as a trigger for the next-level check, not as a substitute for it.

Epilogue

The experiment this incident came from is over: the provider plan was cancelled, the provider was removed from the configuration, and the dispatch documents are kept as historical reference. What survived the cancellation is the habit.

The pipeline I trust now is boring about this. Every delegation has a name, a brief, an allowlist, a stop condition, and a pointer to evidence — and none of those things is a status light.

This incident is documented, with its correction and learned rule, in the Agent Systems case file, alongside six incidents that shaped that workflow. Its natural pair is the follow-up rule for when output arrives but arrives broken: stop the unit on the first schema error.