Self-learning organisations: what Google's Knowledge Catalog does and does not change

Every organisation of any size has a word that means something different in every department. Customer. Active project. Revenue. At the Monday meeting, finance and sales arrive with two different figures, and the first part of the meeting is about who is right. Usually they both are. They are simply using a different definition.

Google Cloud wants to shift part of that problem to software. At the end of October it announced that Knowledge Catalog, known until this spring as Dataplex Universal Catalog, can now make its own proposals to update its knowledge. The catalog is where AI agents, programs that carry out tasks on their own, look up what a table means, how a term is defined and which data belongs with which question. The new component proposes better definitions, descriptions and instructions. In its most far-reaching, optional mode, it also learns from what people and agents ask and where they get stuck. It is a preview, a test version that companies have to request access to.

What the software learns

The system reads documents from sources including Google Workspace, Confluence and SharePoint, and, if an organisation wants, the interactions of users and agents as well. It looks for ambiguous fields, terms without a definition and figures without support. What it finds comes back as a proposal, with the source attached and an estimate of how confident the system is. What learns, according to Google, is the catalog, not the underlying models.

That is useful, but it is not yet a learning organisation. The Japanese management thinker Ikujiro Nonaka described knowledge creation as a constant back and forth between what is written down and what lives in heads and habits. For this he borrowed a sentence from the philosopher Michael Polanyi: "We can know more than we can tell." A catalog sees what ends up in documents and conversations, not what someone knows and never says. Nonaka also referred to what Chris Argyris and Donald Schön called double-loop learning: questioning the framework itself, rather than only correcting an error within that framework.

Google's own example is net revenue that each department defines differently. The catalog can phrase those definitions more sharply and keep them neatly apart. Whether those differences are allowed to exist, which definition belongs to which use and who decides, it does not determine. That is how I read Google's description: the software refines within the framework, people choose the framework. The Monday meeting may get shorter. It does not become unnecessary.

Built smarter than the scepticism assumes

The obvious objection is that a system like this amplifies mess. It is not an exaggerated fear: research on language models shows that retrieved documents can mix current and outdated information, and that models then regularly follow the version that occurs most often. Anyone who has ever seen a shared folder full of files named "final_v3" knows how easily the wrong version ends up in the majority.

Google's design takes this into account. Automatic publishing can be switched on or off. Proposals the system is less sure about, and sensitive changes such as deletions, go as a request to a data steward, the employee responsible for certain data. That person approves, adjusts or rejects. Every change is logged with its origin and can be reverted. Proposals are tested against an evaluation set, a series of check questions with a known correct answer; if the results decline too far, automatic publishing stops. Whatever is contradictory or ambiguous lands on a separate list called "Needs attention". That is how Google describes the workings of a preview for which no independent test is known yet. On paper it is solid work, and the easiest criticism misses its target here.

Who works through the list

The same documentation is just as honest about what the system does not do. Conflicts it finds must be resolved by the user. The organisation supplies the evaluation set itself, and without that set automatic publishing can let errors through. For production environments, Google recommends a setting in which nothing is published automatically. According to Google, experts no longer write the context themselves; they review what the machine proposes.

So the work shifts from documenting to validating. Someone has to decide where a term may differ between departments. Someone has to write and maintain the check questions. Someone has to work through the list of points needing attention, including in the week of the year-end close. A role in a system is not yet a person with time and a mandate. Google describes the human effort in this approach as low: stewards "only" have to review and approve proposals. For the clicking, that may be true. Deciding what a word means is different work.

Research among companies points the same way, although the evidence is soft. In McKinsey's 2025 global survey, the small group of organisations getting the most out of AI redesigned its workflows far more often. A year earlier, BCG estimated that most of the problems in AI implementations lie with people and processes. McKinsey relies on what companies report themselves, BCG on an estimate it also uses as its own rule of thumb. Both sell transformation programmes, and neither proves a cause.

A brand is company knowledge too

Positioning, tone and what is promised to customers are knowledge too. In my experience they are scattered across presentations, web copy and quotes, and rarely in the same version everywhere. As far as I could establish, there is no solid research yet on what happens to brand consistency when agents draw on sources like these, so what follows is an estimate. A system that notices contradictory wording can save a communications team search work. Which wording carries the brand remains a choice someone has to make and be able to defend. Software can see that two versions of a promise exist. Which of the two the customer remembered is not in any document.

Can the technology set the learning in motion itself?

The strongest counterargument is that technology can in fact trigger organisational learning. The economists Erik Brynjolfsson, Danielle Li and Lindsey Raymond followed thousands of customer service agents who were given an AI assistant. They resolved more issues per hour, according to the researchers because the system spread the working methods of the best agents. It concerns one company, one profession and individual performance, and the study says nothing about leadership teams. It does show that a tool can spread knowledge that would otherwise stay stuck in a few heads. Even so, I expect that a catalog that puts the same contradictory definitions on the table every week can push a leadership team to finally choose.

I accept that argument. The system can trigger the learning, but it cannot make the decision on the organisation's behalf. A list of contradictions is an invitation, and whoever leaves it lying gets the same invitation next week.

Four questions before the rollout

• Who decides whether a term may differ per team and which definition belongs to which use, and does that person know it?
• Who writes the check questions that proposals are tested against, and who keeps them up to date?
• Who works through the list of contradictions, and how much time does that person get for it?
• Which knowledge, from product definitions to brand promises, may never change automatically?

Google is building a system designed to see where knowledge is missing or clashing, and one that itself recommends, for production, that people keep the final say. So a self-learning organisation does not start with the software. It starts at that Monday meeting, with the question of who answers when the software asks a question.