206 - Knowledge: from memory to insights

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

Frontier clients like Claude.ai and ChatGPT ship their own memory features that persist across conversations at the provider level. That memory is user-scoped, broad, and generic. It remembers preferences, not facts about your data.

Plexara implements its own memory alongside the client's. Plexara memory is scoped to the workspace and rooted in the data estate. It remembers that a specific user prefers fiscal-calendar views of sales, or that a specific agent has previously confirmed a column definition. The memories are stored as semantically searchable records and the agent_instructions guide the agent to call memory_recall when prior-session context could help the current question.

The third layer is organization-wide knowledge that lives in the catalog itself. Descriptions, tags, glossary terms, curated queries, quality flags. Applies on the first question of any session for any user. Getting a fact into this layer requires passing through an admin review pipeline, because changes here affect everyone.

In practice the choice is usually clear once the question is framed correctly: is this fact about me, or is this fact about the data? Personal preferences and per-user disambiguations are memory. Facts about the data or the business that anyone should benefit from are insights.

Getting this right matters for two reasons. First, it keeps memory focused so the recall stays fast and relevant. Second, it keeps insights flowing into the catalog so the organization's documentation compounds over time rather than sitting in one user's personal memory.

Insights do not become catalog documentation automatically, and the reason is governance. A catalog update that affects every future user deserves a human in the loop. Plexara enforces that with a four-step pipeline that every insight passes through.

The pipeline also serves an audit purpose. Every change in DataHub points back to the insights that produced it, who captured them, who reviewed them, and when they were applied. Nothing about the catalog is mystery-authored.

A common misconception is that the pipeline only runs when a user says "capture this." In practice three independent sources keep it fed. First, user corrections: when the agent says something wrong and the user pushes back, the correction can be captured. Second, agent-authored observations: the agent notices a pattern (amounts look like cents; a column description appears stale; an expected value is missing) and captures the observation with lower confidence for review. Third, enrichment gaps: the semantic middleware automatically notes places where catalog metadata was requested and came back empty.

All three flow into the same Capture step. The reviewer sees the source of each insight and can weigh it accordingly.

None of this is impressive on its own. One insight applied to one dataset is a small win. The payoff is in the compounding: week-over-week, the catalog gets better, which means datahub_search surfaces more useful context, which means the agent gets more questions right on the first try, which means more of those sessions produce new insights worth capturing.

Memory and knowledge persist across users and sessions. That power makes governance the load-bearing question. Who can see which data, who can approve an insight, who can write to the catalog: these are not paperwork, they determine what the agent can actually do. The next lesson covers that layer.

Seven terms cover the vocabulary you will encounter when the subject turns to memory, insights, or catalog updates. Two tool names (capture_insight, apply_knowledge) are the ones you will see in tool-call logs most often.