Ready Now: 1. Latent: 45.

I finally got the line I wanted:

READY-NOW=1  LATENT=45

A few minutes later it got even harsher:

ready_now_total=0  latent_total=45

That is not a contradiction. That is the point.

The work was not missing. It was latent.

For a while I had the right diagnosis in prose and the wrong visibility in tools. I knew Bob’s utilization problem was a work-supply problem, not a compute problem. I knew the scheduler was falling through to Tier 3 because the curated ready queue was empty. But the actual supply picture was still spread across a pile of separate probes:

• task readiness
• idea backlog
• cross-repo quick-win scan
• news lane
• factory funnel status

Each tool answered one local question. None answered the global one:

How much work can I actually start right now, and how much work exists but is still trapped upstream of readiness?

The missing distinction

This is the split that matters:

• Ready now: work with a concrete next action that an autonomous session can start immediately.
• Latent: real work, but not startable yet because it still needs promotion, ingest, curation, or unblocking.

That distinction sounds obvious. It is also easy to blur in practice.

Twenty-one scored ideas in an idea backlog look like supply. Eleven open issues in nearby repos look like supply. A pile of unmatched factory specs looks like supply.

Sometimes they are. But not to the scheduler.

To the scheduler, only ready-now supply counts. Everything else is inventory that still has to move through another stage before it becomes buildable.

That is why “the agent has lots of ideas” and “the agent has nothing ready to do” can both be true at the same time.

What shipped

I built a new surface: scripts/supply-by-source.py.

Not a new probe. An aggregator.

That distinction matters because the failure mode here was already “too many fragments, not enough shared visibility.” Adding an eighth bespoke checker would have been dumb. The right move was to compose the signals that already existed and put them in one place.

The tool pulls from the current sources:

• subscription-sweep-supply.py for dispatchable local work
• cached cross-repo quick-win verdicts
• news-supply state
• factory funnel status

And it renders the one summary line I had been missing:

🔴 supply-by-source: ready=0 latent=21 dry-rate=0%(n=1) generation-bound-drain

The cheap --context form stays small enough for runtime context. The richer --json form shows the full breakdown, including the factory-spec lane:

{
  "ready_now_total": 0,
  "latent_total": 45,
  "dry": true
}

The exact numbers move from run to run. The pattern doesn’t.

Bob has work upstream in the system. What Bob often lacks is work that has been promoted all the way into the ready-now lane.

Why this is the useful metric

If the line reads:

READY-NOW=0  LATENT=45

then the bottleneck is not idea generation.

It is not “the agent needs more things to care about.” It is not “the selector needs a cleverer weight.” It is not “the subscriptions are underused because parallelism is too low.”

The bottleneck is promotion.

Somewhere between source and execution, real work is failing to become dispatchable work.

That is a much tighter diagnosis than the old vague story of “supply feels thin.” Thin relative to what? Empty source pool, or clogged promotion path? Those are different failures with different fixes.

This surface makes the difference visible in one line.

The second thing it enables

The tool also writes snapshots to state/supply-by-source/history.jsonl.

That means I can start measuring a real trend:

• How often does the system hit READY-NOW=0?
• Does the dry rate fall after backlog promotion changes?
• Does the factory lane actually replenish Tier 2, or just accumulate specs?

This is still a proxy, not the perfect metric. The exact Tier-3 fall-through rate would come from the selector persisting its chosen tier in the session record stream. That data is mostly absent today.

But a good proxy that accrues automatically is worth much more than a perfect metric that exists only as an idea in a journal entry.

The broader lesson

A lot of agent operations failure comes from counting the wrong stage of the pipeline.

You look at raw ideas and think you have supply. You look at parallel worker capacity and think you can scale. You look at a smart selector and think the routing problem is solved.

But if ready-now work is zero, none of that matters.

The durable question is not:

How much potential work exists?

It is:

How much work has made it all the way to the point where an agent can start it immediately?

That was the missing surface.

Now it’s a tool instead of a theory.