A Candidate Pool Is Not a Pantry

A candidate pool feels harmless because it is not a published surface.

That is the trick.

A list of opportunity candidates does not annoy users directly. A draft queue does not break checkout. A folder of possible topics does not send an embarrassing email by itself. It sits there looking organized, which is how small product systems get into trouble without making any noise.

Promptara Lab keeps running into the same operating shape: automated systems can observe more than a human should review, suggest more than a product can absorb, and preserve more maybes than anyone wants to admit. One internal signal pass can see 93 observations, insert 12 new ones, and leave 39 opportunity candidates. Another can observe plenty and insert nothing. Neither line is good or bad by itself. The question is whether the resulting candidate pool has a shelf life.

If it does not, the system is not building an opportunity list. It is stocking a pantry with unmarked leftovers.

Cheap collection creates expensive memory

The cost of collecting candidates is now low enough to be misleading. A daily usage report can show 23 requests, tens of thousands of tokens, and a bill under one dollar for the measured day. That is useful. It is also how a product system talks itself into keeping everything.

Storage is cheap. Recollection is cheap. Summarization is cheap. So the system keeps the maybe useful phrase, the maybe useful customer question, the maybe useful content angle, the maybe useful product clue.

Then a human has to read it later.

That later is where the real cost hides. Not in the database row. Not in the generated summary. In the tiny act of rebuilding context around an old candidate: where did it come from, why did it pass the filter, what was true at the time, what decision was supposed to happen next?

A candidate without age is a little operational prank. It asks for fresh attention while refusing to say whether it is fresh evidence.

This is why An Opportunity Is Not a Work Order still matters. A candidate is a prompt for judgment, not a command. But there is a second rule underneath it: a candidate is also perishable.

Stale candidates imitate strategy

Old candidates are dangerous because they often look smart.

They have tidy labels. They came from a real observation. They may have been grouped with similar items. They survived at least one filter. That gives them the smell of judgment, even when no one has actually chosen them.

This gets worse in AI assisted systems because the language is usually clean. A stale candidate does not show up covered in mold. It shows up with a decent title and a plausible next step. Very rude.

The product risk is not that one stale idea gets published. The larger risk is that the candidate pool becomes a fake map of the business. The operator starts reviewing what the system happened to preserve instead of what the product currently needs.

Traffic clues have the same problem. A visit without an action can be worth inspecting. It can point to weak intent, wrong positioning, unclear value, or simply a bored human with a browser tab. But if traffic without action gets stored forever as undifferentiated evidence, it becomes dashboard compost. Technically organic. Still not dinner.

A useful system separates live candidates from old clues. It should be possible to tell whether a candidate is new, refreshed, rejected, merged, promoted, parked for a reason, or expired.

Not because operators need more labels for the thrill of it. They do not. Labels are only worth having when they prevent fake certainty.

Expiration is not deletion

Builders sometimes resist expiry rules because they sound destructive. What if the system throws away the perfect idea? What if a topic becomes relevant again? What if an old clue was early, not wrong?

Fair. Expiration should not mean pretending the evidence never existed.

A better model is decay, not deletion.

A candidate can move through states like fresh, aging, needs refresh, retired, or promoted. The exact labels matter less than the promise: the system must stop presenting old evidence as if it just arrived wearing a clean shirt.

A decayed candidate can still be searched. It can still support pattern analysis. It can still be resurrected if a new observation confirms it. But it should lose its right to sit in the primary review lane forever.

This is where a draft bill of materials becomes useful beyond publication. Every candidate needs its own small bill of materials: source type, first seen date, last checked date, reason it entered the pool, current state, and the next allowed decision.

That sounds bureaucratic until the alternative appears: a beautiful backlog full of mystery meat.

The pool should get smaller on purpose

A candidate pool that only grows is not a research system. It is avoidance with a user interface.

The healthier pattern is uncomfortable but simple. Every collection pass should create at least one kind of pressure on the pool:

• promote a candidate into actual work
• merge duplicates into a stronger pattern
• refresh candidates that need current evidence
• retire candidates that no longer deserve review
• leave some untouched, but with age visible

The untouched bucket is allowed. It just does not get to masquerade as strategy.

This also changes how success is read. A run that inserts zero new observations may still be useful if it confirms that the pool does not need more material. A run that creates dozens of opportunities may be useful, or it may have just delivered a box of obligations. The number alone is too polite to say.

At Promptara Lab, the point of the agentic framework under the hood is not to keep feeding bigger lists to a human. It is to make small product decisions easier to inspect. Sometimes that means collecting. Sometimes it means refusing. Sometimes it means letting a candidate age out with dignity.

The pantry metaphor is useful because everyone knows the failure mode. Buying groceries feels productive. Organizing shelves feels responsible. Then one day the back row contains three jars of the same thing, two expired sauces, and something that may once have been ambitious.

Product systems do this too.

The fix is not to stop collecting. The fix is to make freshness visible, make decay explicit, and stop treating every preserved maybe as if it still deserves a human minute.