Thoughtware

Do not rediscover known work

When judgment already exists as an evaluated library package, rewriting it in prompts splits eval history, raises cost, and breaks encapsulation.

10 min read

Cover for Do not rediscover known work

Deadline pressure produces a familiar shortcut. The org already publishes AskTargetedQuestion in the library, with contract, suite, owner, and semantic versioning. The meal agent team embeds a fresh "ask the smallest useful question" block in the system prompt instead. Demo ships Friday. Stakeholders celebrate velocity. Three months later: four prompt forks, no regression suite, nobody knows which question policy production uses. Product A over-questions on busy weeks. Product B infers instead of asking when authority is missing. Improvement in one fork does not help the others. Finance sees duplicate LLM spend for the same judgment under different names. That pattern is rediscovering known work, and it violates the economic and architectural reason libraries exist.

Helpful context: Libraries of cognition packages reusable judgment. Packages, not prompts names the asset model. Maturity moves work out describes the migration path from improvisation to inventory. This page is the anti-pattern note for teams under schedule pressure.

Do not make an agent rediscover work the system already knows how to perform.

The cognitive unit · Principle 23

Why it hurts

Rediscovery feels fast because it avoids publish gates, contract writing, suite binding, owner assignment, and catalog metadata. The cost arrives later and compounds across every dimension that libraries exist to control: split eval (improvement on one fork does not transfer), raised spend (same judgment billed twice under different names), encapsulation break (callers depend on prose, not contracts), autonomy fragility (meta-agents cannot search what was never published), incident opacity (no suite fails when behaviour regresses, because no suite exists), and ownership vacuum (nobody approves changes, everyone edits locally).

Rediscovery costMechanism
Split evalImprovement on one fork does not transfer
Raised spendSame judgment billed twice under different names
Encapsulation breakCallers depend on prose, not contracts
Autonomy fragilityMeta-agents cannot search what was never published
Incident opacityNo suite fails when behaviour regresses, because no suite exists
Ownership vacuumNobody approves changes, everyone edits locally

Libraries exist so organisational learning concentrates. Rediscovery disperses it again, back to the pre-library regime where every team owns a dialect of the same policy.

Import library cognitive units

Call `AskTargetedQuestion` v1.2. Suite travels. Substitution rules apply. One owner improves everyone.

Rewrite in agent prompt

Local cleverness. No semantic versioning. No regression. Next team repeats the work.

The economic argument

Cost per decision makes duplicate judgment visible when packages exist. Rediscovery hides the same judgment inside feature prompts until finance asks questions nobody can answer.

Consider three product lines each embedding targeted-question logic. Each pays inference cost per run. Each maintains prompt editors. Each debugs question policy independently. One organisational library entry would meter one judgment, one suite, one owner. Rediscovery multiplies cost by product count while lowering measured quality, because none of the forks has full suite coverage. The argument is not "never write prompts." Prompts implement contracts inside packages. The argument is: do not re-implement published contracts in parallel prose homes.

When rediscovery is tempting

Teams rediscover for understandable reasons, and each reason has a library-native response.

The most common justification is "our case is slightly different." Inspecting applicability first through runtime inspectability often reveals that the difference fits within existing guards. When it does not, extending the contract, publishing a variant package, or wrapping with tuning by wrapping preserves evidence. Slight differences often belong in applicability guards, not forked templates.

"Library search is slow" is a real obstacle that deserves a real fix: better catalog metadata as sealed and searchable describes. Search failure is infrastructure debt, not permission to fork. "We need to move fast" is valid, but fast paths belong behind the same contract as substitution rules explains. Measured shortcuts preserve evidence. Shadow prompts destroy it. "The library cognitive units is almost right" triggers the same principle: wrapping preserves evidence, while template rewrites kill it, as evidence dies when the template changes warns.

"Publish gates block us" feels like bureaucracy, but gates exist because unpublishable judgment should not pretend to be org infrastructure. Agent-private tactics are legitimate until stabilisation, then promote or delete, because lingering as permanent forks is the worst outcome. "We don't trust platform yet" is solved by using packages and reporting gaps, not by duplicating them locally, since local duplication prevents platform improvement from reaching the team.

cognitive unit versus Skill rediscovery

Rediscovery happens at both granularities. cognitive unit rediscovery rewrites AssessMealPracticality logic in a composer prompt instead of invoking the domain library entry. Skill rediscovery re-authors a settled multi-step invoice extraction procedure in a worker script each sprint instead of invoking the skill library entry.

Both split eval history. Both break search for meta-agents. Skill library versus cognitive unit library covers choosing the right shelf and importing from it instead of reinventing.

What this looks like in practice

When the pattern works correctly, the Meal Planning Agent invokes org-library AskTargetedQuestion when authority or information is missing. Materiality threshold lives in cognitive unit policy. Regression covers over-questioning and under-questioning. Version updates propagate through semantic versioning.

When rediscovery takes hold, the agent prompt contains twelve lines on "only ask when it changes the plan." No suite. Product A and Product B diverge on what "material" means. Incident review reads prose instead of suite failures.

The same distinction applies to domain judgments. Domain library RecommendMealSubstitution handles local repair proposals, and the agent invokes it while the deterministic shell applies the patch. Judgment owned in one package. The rediscovery version has CritiquePlan prompt growing a shadow substitution section that re-decides repair logic, producing two homes for one judgment, a locality failure compounded by rediscovery.

At the Skill layer, a settled multi-step invoice extraction procedure belongs in the skill library, not re-authored each sprint in a worker script. Procedure suite travels with the Skill. Worker scripts call the Skill rather than reimplementing it.

Relationship to maturity

Maturity moves work out describes the legitimate path: agent-private tactics while unstable, publish when contract and suite earn it. Rediscovery is the stalled path where work that should have moved out stays in prompts past stabilisation because publish felt slow. Architecture review benefits from the question: "Does this already exist under another name in the library?" A positive answer triggers import, not rewrite.

Relationship to autonomy

Autonomy without a library describes systems that cannot compose because inventory is missing. Rediscovery is worse: inventory exists but callers bypass it, so autonomy cannot search org knowledge while teams pay duplicate maintenance cost. The library unlocks autonomy when agents inspect and invoke published packages. Rediscovery locks autonomy into ever-longer system prompts listing what the catalog already contains.

Detection in review

Architecture review catches rediscovery with straightforward questions: Does this judgment already exist in the catalog under another name? Does this prompt block duplicate a published contract? Is there a suite for what the team is about to ship locally? If the answer is import, the review stops a fork before it entangles eval history. Code review for AI features benefits from listing library dependencies the same way it lists package.json entries, not as optional context.

Tracking rediscovery in architecture review with simple metrics, such as duplicate judgment names in inventory, fork count for the same decision sentence, and search miss rate before prompt rewrite, reveals whether the problem is team laziness or catalog and inspect gaps. Rising fork count with flat library publish rate usually means search or inspect needs fixing. Fixing infrastructure before blaming teams for bypassing libraries produces better outcomes.

Rediscovery cost in roadmaps

Tracking hours spent rewriting prompts for judgments that already exist in the library makes rediscovery tax visible in roadmap reviews beside model spend. Onboarding that teaches catalog search and inspect flows before freestyle prompt authoring reduces rediscovery at the source. Junior engineers often rediscover because tooling defaults to blank prompts.

Rewarding package reuse metrics the same way deployment frequency is rewarded shifts incentives toward mature cognition architecture.

What to do next

The practical starting point is to search the library before writing prompt prose for recognizable judgments. Private agent tactics earn packages when they stabilise, at which point promoting or deleting is the clean choice. Tracking rediscovery in architecture review by asking "does this already exist under another name?" catches forks early. Pairing with economics through cost per decision makes duplicate judgment visible in spend. Fixing search and inspect gaps before approving forks addresses the root cause, because bypass is often a symptom, not a strategy.

See inspect before you call, the library unlocks autonomy, and autonomy without a library for the positive pattern this anti-pattern blocks.

Read next: Skill library versus cognitive unit library.