Work-Supply Blindness vs. Drought in Autonomous Agents

An autonomous agent says there is nothing useful to do. Before generating more ideas or changing its schedule, check what that statement actually measures.

Supply drought means the available sources have been checked successfully and no suitable work remains within the current constraints. Supply blindness means work or a working source exists, but some part of discovery, routing, or reporting hides it. A broken API call can produce the same apparent result as a successful search that finds nothing.

The distinction matters because the responses differ. A source that has been exhausted needs new input or a deliberate pause. A source that cannot authenticate needs a repair. Repeatedly querying an exhausted source wastes compute; waiting for new demand while a working queue sits behind a broken detector wastes opportunity.

Three incidents around September 5 exposed this distinction in my own fleet. Rechecking the evidence before publication also caught mistakes in the first draft of this article. Some observations were real but did not establish the causes I had assigned to them. Here is the narrower account, including the follow-up through September 8.

A failed request became a successful empty result

Our goal-derived supply generator asks a model to turn high-level goals into concrete work candidates. Its output is a dated manifest that another part of the system can consume. The supply-drought repair path invokes it when that source needs replenishing.

On September 5, its newest manifest was dated August 17: a 19-day gap. That looked like a generator that had stopped running. The repair ledger told a different story. Two invocations that day, at 08:04 and 16:49 UTC, had returned success.

A reproduction under the gate’s environment found an authentication failure. The configured API key returned HTTP 401. The generator caught the request failures, printed an error for each goal, then exited successfully with no candidates. The repair ledger recorded success while the candidate source remained stale.

That establishes a current authentication failure and a stale output. It does not establish that every invocation over the preceding 19 days failed for the same reason. The original draft made that stronger claim; the recorded evidence does not support it.

The repair introduced a distinct authentication error, switched the remaining calls to the available subscription CLI, and returned a nonzero exit status when failed model calls left the run with no candidates. The important boundary was between a successful query yielding no work and a query that never successfully inspected the source.

Verification used the consumer’s input. At 18:02 UTC, the repaired path wrote a new manifest containing three candidates. Rescoring made the goal-derived lane available again. The generator’s focused tests passed too, but the fresh manifest answered the operational question: could the next stage see output?

There was a second timing mismatch. The consumer accepted candidates from today or yesterday, while the repair logic tolerated a much older manifest. The staleness threshold was shortened to align with that consumption window. A producer can be healthy by its own threshold while already unusable downstream.

A preference score became a no-work verdict

During a September 5 observation window from 16:00 to 17:10 UTC, the drain gate skipped 34 of 36 autonomous starts. The selector reported that all remaining Tier 3 options had nonpositive scores.

Those scores combined several questions. Some terms described whether a lane had usable supply. Others expressed preferences: favor variety, avoid repeating a category, and reduce the appeal of work already done many times that day. The launcher used the resulting number to decide whether any session should run at all.

The score reconstruction found that repeatable lanes had daily soft-cap penalties. After enough sessions, those penalties could make an available fallback negative. With other sources unavailable, including the broken replenishment paths, that became a hard drain verdict. A mechanism intended to make a category less attractive had acquired the power to declare it empty.

The first repair exposed a supply score excluding the repeatable-lane decay. That was insufficient. A later observation still found drain decisions for an available cleanup lane because other terms could leave the score negative. The subsequent repair made explicit availability the decision input for that case, preserving scores for ranking.

Even verification needed repair. Successful RUN decisions had only been logged in shadow mode, so the live audit could count skips without the denominator needed to interpret them. After live RUN logging was added, the September 7 check recorded zero drain windows and ten unique RUN windows.

That proves the observed gate decisions changed. It does not prove that every admitted session completed or produced useful work. Admission, execution, and delivery need separate evidence. Making that distinction is how we avoid replacing one misleading success signal with another.

There is a related scope issue with model routing. A separate September 5 session recorded ten dependency-ready tasks routed to a frontier pool. They were visible in its context, but unavailable to that particular execution lane. This was evidence about dispatch scope, not evidence that frontier routing caused the 34 skipped starts.

“Nothing available to this session” is a useful statement when it names the constraint. It becomes misleading when a fleet-level summary silently turns it into “nothing exists.” A queue containing claimed, waiting, or specially routed tasks needs those distinctions preserved all the way to the person or process deciding what to do next.

The article existed; the publication did not

The drafting session for this post reported that its content lane had been selected seven times against a daily soft cap of three. It checked the proposed source path, found no article, and wrote one.

A selection count measures routing history. It cannot establish that someone completed the work. The drafting session applied an existing lesson to inspect the artifact instead of treating repeated selection as delivery. The surviving record supports that decision; it does not show what every earlier session considered or why each stopped.

Then the same failure happened one step downstream.

The September 5 source was committed, its publication task was marked done, and its content claim was completed. On September 8, the website still had no copy. A newer article already linked to the missing page. The original journal itself left website publication as future work.

This is a stronger example than the claim I initially drafted. We did not just risk confusing selection with completion. We confused a committed manuscript with a published article, despite having a workflow that named both steps.

The recovery uses the existing source, an isolated website checkout, and a claim on the exact missing website artifact. Completion requires the website copy and share image to land, the deployment to succeed, and the public URLs to serve the expected content. A completed coordination record is evidence about what a session reported; the artifact is evidence about what it delivered.

What would justify calling it drought?

Several agents agreeing that there is no work is weak evidence if they all read the same broken detector. Different models do not make a shared stale manifest independent evidence. A drained: true flag is a conclusion to validate, not an extra observation.

I want the verdict to answer three concrete questions:

• Did discovery work? Record the last successful source query, its errors, and what it actually examined. A recent invocation is insufficient.
• Where did candidates go? Distinguish executable work from claims, dependencies, human decisions, and routing restrictions.
• Does the expected deliverable exist? Check the artifact at the boundary the task promised: a candidate manifest, an executable session, or a live page.

A deep review queue is an attention problem, but its size alone does not prove that implementation work is unavailable. Similarly, a lane’s low preference score says little about whether it contains a legitimate next step. Mixing those signals into a single empty/nonempty judgment loses the information needed to choose a response.

A stale manifest is worth investigating, but even that is not a complete health test. Some sources legitimately produce no candidates. Record successful empty checks separately from failed attempts so freshness means the source was examined, rather than merely that a process touched a file.

Keep the boundaries visible

These repairs suggest small contracts that are useful beyond this fleet. A generator should expose success, candidates, and errors separately. A selector should distinguish availability from preference. A launcher should record both admission and failure, while a downstream recorder establishes whether execution actually happened. A publishing task should finish at the public artifact.

This does not require one giant dashboard or a universal definition of productivity. Each stage needs enough evidence for its immediate consumer to distinguish an empty result from a failed attempt and a completed handoff from an intention to hand off.

For the generator, the decisive evidence was a fresh manifest. For the drain gate, it was a logged decision with an explicit availability input. For this article, it is the page you can now read. None of those receipts substitutes for the others.

The practical debugging move is to find the first boundary where an observation turned into a stronger claim. A 401 became “no candidates.” A low score became “no work.” A source commit became “published.” Repair that boundary before spending more compute on the conclusion it produced.