Who benefits from a knowledge system, and why that answer is changing

What does knowledge nobody can find cost?

The cost of unfindable knowledge has been measured. APQC surveyed 982 full-time knowledge workers and found that they spend an average of 8.2 hours per week searching for, requesting and recreating information that already exists, of which 2.0 hours is pure repeated work (APQC, 2021). You could assume that 2 hours is an underestimate rather than an overestimate, because you can only report duplicate work if you later discover it already existed. The cases nobody ever finds out about are not in the figure.

More interesting than whether it pays off is the question of for whom. And recently, the answer to that question has split in two.

What determines whether a system is usable?

Ferreira et al. (2025) studied knowledge workers in industry who had built their own personal knowledge system in Obsidian. Their finding was that the structure of such a system follows from the expected retrieval strategy. People who search via queries lay out notes differently from people who navigate via internal links or tags. The authors therefore recommend a minimal starting structure that grows with use, plus an explicit processing routine so that new input does not sit around unsorted.

That is the opposite of how knowledge bases are usually set up, where the layout is often designed in advance by someone who will never work with it. Frost names lack of usability as a failure factor, and Ferreira shows that usability emerges from search behaviour rather than from predesigned layouts.

A semi-systematic review of 149 peer-reviewed articles from 1993 to 2025 additionally distinguishes between taking over work and supporting work, or augmentation (Litvinenko, 2026). Automation of explicit knowledge, such as transcription and indexing, increases efficiency and scalability, with bias, opacity and deskilling as documented risks of overuse. Augmentation, where the system proposes connections and the human decides, supports adaptive learning but depends on data quality and training. This is at once the strongest and the vaguest source in this list. A review yields a framework, not figures you can build a business case on.

What does it deliver for people?

Those figures do exist for the supporting case. Brynjolfsson, Li and Raymond (2025) followed 5,172 customer service agents during the staggered rollout of an AI assistant, supplemented with a randomised pilot. The assistant was trained on the conversations of the best-performing colleagues, so in effect knowledge that had until then lived in a small group of heads was made available to the rest. The result was on average 15 percent more resolved cases per hour with unchanged customer satisfaction.

The distribution of that effect says more than the average. The gain sat almost entirely with the least experienced agents, over 30 percent for the bottom group. The most experienced agents barely saved any time and lost slightly on quality.

The same happens with software developers. Cui et al. (2026) ran randomised experiments at Microsoft, Accenture and a Fortune 100 company and, across 4,867 developers, found 26 percent more completed tasks. There too, the gain sat with the less experienced group, who also adopted the tool faster.

The counterexample is at least as instructive. Becker et al. (2025) had sixteen experienced open source developers carry out 246 tasks in their own mature codebases, with a coin flip per task deciding whether AI help was allowed. Beforehand they expected a 24 percent time saving. Afterwards they estimated they had been 20 percent faster. Measured, they were 19 percent slower. Strikingly, self-reporting was wrong in both directions, which means that asking whether people work faster is not a usable measurement.

Taken together, this points one way. Where someone does not yet know the domain, access to other people's knowledge delivers a gain. Where someone already has the domain in their head, consulting a system costs more than it yields. A knowledge system does not make your best people better. It ensures the rest do not have to reinvent every time what those people already know.

That is a real but bounded return. It scales with intake, turnover and onboarding time, not with the size of your organisation. This is exactly why many companies conclude after a year that it was not worth it.

What does it deliver for AI?

That conclusion has recently become incomplete, because a second reader has joined.

All the studies above concern people looking something up. In AI-assisted work that question shifts, because then the model is the party that has to look something up, and that model is entirely dependent on what you hand it.

That effect has been measured. In EDIT-Bench, an evaluation of models on real code edits, the success rate differs by up to 11 percentage points based on nothing other than the amount and kind of context the model receives (Chi et al., 2025). Same task, same model, different outcome. Research into repository-level code changes identifies retrieving the right context as one of the main bottlenecks, and shows that simply offering more context does not help once the model cannot pick out the relevant parts.

That changes what a knowledge system needs to be. When we write a manual or another document, we assume a colleague already has knowledge. Think of what the company does, who the CEO is and what problems the company has. An AI model does not work the same way. Decisions that are written down nowhere, agreements that only live in someone's head and the reason a way of working is the way it is, simply do not exist for the model.

The pattern from the previous part was that the gain sits with those who do not yet know the domain. A model by definition does not know your organisation and never will. Every session, it is the new employee on day one all over again.

The finding of Becker et al. takes on a different meaning as a result. Experienced developers became slower in their own mature codebase, where they already had the context in their heads and the model did not. The difference lies in what has been written down, not in the help itself.

Where do most implementations go wrong?

The literature discussed does not argue against setting up a knowledge system, but it does identify where most implementations fall short. The layout is fixed in advance instead of derived from users' actual search behaviour. In addition, the system takes over tasks at points where supporting human judgement would have delivered more. In both cases these are design decisions that can be made before implementation.

What structurally changes the trade-off is that a knowledge system now serves two categories of users with different requirements. The human user benefits from a light structure and high findability, and fills in missing context from experience. The language model does not have that experience and relies on what has been made explicit. A system tailored only to the first category results in documentation that is unusable by machines. A system that only serves the second results in a data collection without an owner.