Your Enterprise Knowledge Base Is Full of Answers Nobody Needed

Scope note: This essay considers enterprise knowledge-base construction, retrieval across a work session, failure records, and repeated agent learning as one operational loop. It does not argue that every missing fact can be discovered through failure or that the cited prototypes establish long-term enterprise performance.

Most enterprise knowledge bases contain an impressive amount of material that no working person has ever needed.

Then an AI agent fails, and the missing fact is nowhere in sight.

The usual response is to add more documents. More policies. More pages. More chunks poured into the retrieval system until the useful answer becomes one pale card in a warehouse of plausible context.

Five recent preprints point toward a better rule. Build the knowledge base from the pressure of real work. Watch where a task fails, where a question turns, where a session reaches beyond the first search, and where an earlier mistake should prevent a later one. The archive should answer demand. It should not merely accumulate.

A question is not the unit of work

Most retrieval systems treat each question as a separate event. A person asks. The system searches. The model answers. The transaction closes.

Work does not behave that way.

A support investigation might begin with a billing error, move into account history, cross a product rule, and end in an exception process stored somewhere else. The questions are connected even when the documents are not.

In One Retrieval to Cover Them All, Shivam Ratnakar and his coauthors tested this problem against WixQA, a collection of 6,221 enterprise support articles. One ordinary retrieval covered only 41 percent of the information needed across a user’s full session. Their method reorganized the knowledge base around documents that tend to be needed together. Coverage rose to 58 percent, and the number of retrieval calls needed to reach 70 percent coverage fell by 34 percent.

The exact numbers belong to one support corpus. The larger point travels well. A knowledge base organized around isolated pages may be tidy and still fail the shape of the work.

More retrieval can produce the same answer

The obvious fix is to search more ways. Rewrite the question. Run several searches. Merge the results. Send the strongest passages to the model.

Luigi Medrano and his coauthors tested that approach in Scaling Retrieval Augmented Generation with RAG Fusion. Retrieval fusion increased raw recall in their production-style enterprise pipeline. After reranking, fixed context limits, and latency budgets did their work, most of the advantage disappeared.

The system found more possible evidence. The answer did not improve in proportion.

This is the part that deserves more attention. Retrieval quality is not the number of documents touched. It is whether the right evidence survives the entire route from storage to answer. A wider net can still feed the same narrow gate.

Failure can tell the archive what it lacks

Demand-Driven Context, by Raj and Saideep Navakoti, starts from a blunt observation: enterprise agents often fail because the decisive knowledge lives in local terms, procedures, dependencies, and old decisions that nobody thought to document.

Their proposed method reverses the ordinary sequence. Instead of documenting a domain first and hoping the material proves useful later, the organization gives the agent real problems. Each failure becomes a request for a specific missing piece of context. A person then curates the smallest useful addition.

In a worked retail incident-management example, nine problem cycles produced 46 connected knowledge entities. The authors also propose that 20 to 30 cycles may be enough for a particular job role, but that is a hypothesis, not an established enterprise threshold.

The method still makes an important correction. Documentation becomes a response to observed need. The failure names the hole.

Dead ends are knowledge too

Organizations are usually better at recording successful procedure than failed inquiry. The final answer enters the system. The six expensive paths that did not work vanish.

That omission is costly for agents because an agent can repeat a bad idea with perfect confidence and fresh tokens.

In Negative Knowledge as Failure-aware Shared Memory, Hanchun Wang adds a curator that converts failed research attempts into typed records. A later agent must explicitly accept or reject those records before trying its next experiment. In the reported tests, this memory used fewer tokens than the baseline and helped solve new scientific tasks that the baselines did not solve.

Forage V2 approaches the same problem from repeated organizational learning. Knowledge accumulates across agent runs instead of dying with each session. The reported experiments cover only three task families and six runs, but they expose the important design question: can a later agent inherit a useful method without inheriting every old mistake?

Success records tell a system what worked once. Failure records tell it what not to spend again.

The knowledge base becomes a work queue

My read across these papers is that enterprise knowledge management should move closer to incident management.

A useful operating loop would look like this:

1. Give the agent a real, bounded task.
2. Record the point where evidence becomes insufficient.
3. Separate missing knowledge from weak reasoning or a broken tool.
4. Curate the smallest durable record that closes the gap.
5. Connect that record to the task, related documents, permissions, and date.
6. Test the same class of task again.
7. Preserve both the accepted route and the failed alternatives.

This does not eliminate top-down documentation. Laws, policies, safety rules, and formal procedures should not wait for an agent to discover them by collision. The loop changes the priority around everything else. It tells the organization which undocumented fact is currently expensive.

The result is not a larger archive. It is a sharper one.

Useful knowledge has a scar

The strongest trend in this group of papers is not a new retrieval trick. It is a change in what counts as evidence for knowledge management.

A search session shows which facts belong together. A failed task shows which fact is missing. A rejected approach shows what should not be repeated. A production limit shows whether better retrieval survives contact with the rest of the system.

That evidence is less elegant than a complete taxonomy prepared in advance. It is also closer to the work.

An enterprise knowledge base should not try to know everything before anybody asks. It should remember where the work broke, why it broke, and what finally held.