206 - Knowledge: from a memory to something the whole team can use

If any term in this lesson feels unfamiliar, the 100 series is one click back. The 200 series assumes that mental model.

Everything the platform learns is a memory. Most memories are personal or operational and stay yours. When a memory asserts something true about the business or the data that other people would benefit from, it becomes an insight: a proposal awaiting review. Whoever holds the apply_knowledge capability reviews insights and promotes the good ones into knowledge, which is shared, trusted, and canonical.

That is the whole model, and it is worth reading twice, because the two arrows in it are where all the interesting behavior lives. The first arrow is decided by what kind of fact you stated. The second is decided by a person.

The first arrow is not a judgment call the agent makes in the moment. Every memory is filed under a lifecycle class when it is captured, and the class is what decides whether the memory is a candidate for promotion at all. Two of the five classes are personal by nature. The other three make claims that could be true for everyone, so they enter review as pending insights instead of quietly settling into one person's memory.

The classes also explain a behavior you will notice early: restating something you already told the agent does not stack a second near-identical memory beside the first. Capture checks your existing memory before writing, and a restatement supersedes the record it corrects. The five kinds of memory and how each comes back goes deeper on the recall side of this.

Nothing crosses into shared knowledge automatically, and the reason is the same reason a catalog update deserves a human: a fact that answers questions for everyone should have been read by someone before it starts doing that. What is worth being precise about is the shape of the check. It is not an admin role, and it is not a job title. It is whether your persona grants the apply_knowledge tool.

That distinction is practical rather than pedantic. Roles tend to bundle unrelated powers together, and the person who genuinely knows whether a revenue definition is right is usually not the person who administers the deployment. A capability can be handed to the domain expert who should hold it, and to nobody else, without also handing them the keys to everything else. This is the same governance at execution time principle that shapes the rest of the platform.

A promoted insight does not have one destination. It has two, and which one it lands in depends on what kind of fact it is. A fact about a specific table or column belongs on that catalog entity, where the next person browsing it will read it. A fact about the business, a definition, a rule, a piece of context that outlives any one table, belongs on a page written for a human to read.

The older way of describing this platform only knew about the catalog, and it left a real gap: there was nowhere canonical for the knowledge that does not hang off a single entity. The knowledge-page sink closes it.

A knowledge page is the durable, human-readable half of the answer. Where the catalog holds structured metadata about one entity, a page holds the vocabulary, definitions, runbooks, and context that a new teammate would otherwise learn by asking somebody. Pages are the canonical store: the memory and insight queue is where knowledge is provisional, and a page, once it exists, is the version the organization stands behind.

Everyone can read pages. Creating, editing, and removing them is gated on the same apply_knowledge capability that gates promotion, which is deliberate: it introduces no separate curator role to administer.

Memory, insights, and canonical knowledge used to live in separate corners of the portal, which made the lifecycle something you had to be told about rather than something you could see. They are now one Knowledge page, with the lifecycle stated in its header.

The Catalog sub-tab is the other half of this lesson made browsable: the whole DataHub catalog inside the portal, with tables, context documents, tags, domains, and the business glossary. Governing those vocabularies from the portal is a subject in its own right, and 211 - Governing the catalog without leaving the portal gives it a lesson rather than a paragraph. What matters for this one is that both promotion sinks are reachable from the same page, because they are two halves of one corpus.

One insight applied to one dataset is a small win. The payoff is in the accumulation: week over week the corpus gets better, which means search surfaces more useful context, which closes the context gap that otherwise sits between an agent and your data, which means the agent gets more questions right on the first try, which means more sessions produce something worth capturing. This is how everyday usage turns into documentation rather than a documentation project nobody has time for.

Knowledge persists across users and sessions, and that is exactly what makes governance the decisive question. Who can see which data, who holds apply_knowledge, and what the audit log records are not paperwork; they determine what the agent can actually do. The next lesson covers that layer.

Ten terms cover the vocabulary you will meet whenever the subject turns to memory, insights, or knowledge. Three tool names (memory_capture, search, apply_knowledge) are the ones you will see in tool-call logs most often.