Halfway through a query session an analyst types a sentence that is worth more than the query: “timestamps before March 2024 are UTC, after that they are America/Chicago.” The agent takes the correction, fixes its WHERE clause, returns the right numbers, and the sentence is gone. The next session, with a different analyst or the same one tomorrow, starts blind and makes the same mistake. Every organization runs on knowledge like this, and almost none of it makes it back into the catalog. A platform whose whole job is connecting agents to data is in the one position to catch it, because the knowledge surfaces inside the sessions the platform already mediates. This post is about the loop mcp-data-platform uses to catch it: capture during the session, recall on demand, and a reviewed path back into the catalog.

This is the fourth post in MCP by Design. The previous posts built the server, composed it, and steered the agent driving it. This one is about the human on the other side and what the platform does with what they know. It is grounded in the open-source txn2/mcp-data-platform, also available hosted as Plexara.

§Knowledge That Dies at the End of the Session

Tribal knowledge about data is real and specific: what a column actually means, which table is reliable, how a metric is calculated, when a time zone shifted. It lives in experienced heads and surfaces in conversation, and AI-assisted exploration makes the leak worse rather than better. A user shares a correction, the assistant uses it for the current answer, and then the context window closes and it is gone. The assistant improved for the duration of one session; the catalog gained nothing.

Closing that leak is a workflow, and the platform models it with two MCP tools and an admin path. An analyst captures what they know without leaving the session. The agent can recall what was captured before instead of re-asking. An admin reviews captures and promotes the good ones into DataHub, where they become durable metadata the next session reads for free.

§Capture, Recall, Apply

Three tools carry the loop, each used by a different person at a different point in the workflow.

capture_insight runs during a session and is available to any persona that has it enabled. It records a piece of domain knowledge against the entity it concerns, classified into one of six categories:

The time-zone sentence is a data_quality insight. The categories drive behavior: the admin review surface groups incoming captures by category, and the catalog write-back uses the category to decide what kind of change to propose.

recall_insight is the other half, and it is what stops the agent re-asking. It searches the calling user’s captured insights by relevance, so before the agent asks the analyst the same question a third time, it can find that the answer was already given and stored. The agent reads back what the organization already learned.

apply_knowledge is admin-only and is where capture becomes catalog. An admin reviews the pending insights, approves the ones worth keeping, and the platform synthesizes them into proposed DataHub changes and writes them back. Capture is open to everyone; the write to the shared catalog goes through one reviewer, and that asymmetry is where governance lives.

§One Table, Two Axes

All of it lives in a single Postgres table, memory_records, backed by pgvector. The earlier design split “knowledge capture” and “memory” into separate stores; they are now one, which means an insight and a remembered preference rank against each other in the same search and a person sees both under one view. Every record is scoped on two axes:

• user, keyed on email, decides ownership. You can update or forget your own records; an admin can touch anyone’s.
• persona decides visibility. A record captured under the analyst persona is visible to that persona, not to a viewer with narrower rights. Admin sees all.

Keying ownership on email rather than the OIDC subject is a small decision with a real consequence: a person’s insights and memories share an owner and both surface under their My Knowledge view, instead of being split across whatever identifier each subsystem happened to record. The platform shipped a migration to backfill older rows onto the email key, stashing the original identifier so the change is reversible.

§Recall That Degrades Instead of Lying

The recall path is where this article meets the rest of the series, because it is built on the same pgvector and Ollama substrate as the Vector Search Without the Vector Database work, and it makes the same engineering choice the series keeps returning to: report its own state accurately.

Semantic recall fuses two signals, blended 0.6 * semantic + 0.4 * lexical, the vector arm on an HNSW index and the lexical arm on a Postgres full-text GIN index. The blend exists because pure vector search underweights an exact token, and memory content is full of exact tokens: entity URNs, column names, error codes. A query for customer_id should not lose to fuzzy neighbors.

The part that matters for design is what happens when the embedding provider is down. A naive implementation errors, or worse, silently returns nothing and lets the agent conclude there is no relevant memory. This one falls back to lexical-only matching and says so, in the response:

{
  "strategy": "semantic",
  "ranking": "lexical",
  "degraded": true,
  "note": "embedding provider unavailable; results are lexical-only (exact-term matches), not semantic",
  "memories": [ ... ]
}

The agent reads degraded: true and knows the recall it just got is exact-term only, not semantic, so a thin result set means “I searched narrowly,” not “there is nothing here.” Lexical search even surfaces rows whose embedding is NULL because they were saved during the outage, which pure vector search would skip entirely. When the provider returns, a backfill reconciler re-embeds those rows off the request path, keyed on a content hash so unchanged text is never re-embedded. A memory written during an outage is recallable immediately by keyword and becomes semantically recallable later, automatically. This is the embedding pipeline pattern applied to the memory corpus, and labeling the degradation is what lets the agent trust the result instead of being misled by it.

§The Loop Has a Lifecycle

Capture is not a write-and-forget. Each insight moves through a state machine, and the states carry the governance:

pending --> approved --> applied --> rolled_back
   |            |
   |            +--> (synthesized into a DataHub change)
   +--> rejected
   +--> superseded   (a newer insight replaces it)

An insight starts pending. An admin working through apply_knowledge can pull a bulk_review that groups everything waiting by entity, by category, and by confidence, drill into one entity to see its pending insights next to the current DataHub metadata, and approve or reject. Approved insights get synthesized into change proposals and applied to the catalog, and every application is recorded as a changeset so it can be rolled back. The time-zone correction does not just edit a description; it leaves a tracked, reversible trail from the sentence an analyst typed to the metadata a future query will read.

Two background behaviors keep the store from rotting. A staleness watcher checks whether the DataHub entity a memory refers to was deprecated or deleted, and flags the memory so it stops surfacing as if it were still true; admins can list the flagged ones with review_stale. And the supersession state means a later, better insight about the same entity retires the earlier one instead of contradicting it in search results. The loop maintains itself, which is what keeps a knowledge store usable over time.

§Why This Is the Part Users Feel

The composition and the middleware from the earlier posts are invisible to the analyst, but this loop is the part they feel. The agent stops asking the same question every session, and a correction one person makes becomes context everyone inherits. The catalog stops being a static artifact a central team maintains on a quarterly cadence and starts improving every time someone with domain knowledge uses it, which is the actual promise of active metadata: the catalog gets better because it gets used. Because every promotion runs through one reviewer and lands as a reversible changeset, that improvement stays governed: knowledge goes in from the edges, and only what a human approved reaches the shared catalog.

The last post in the series turns the lens on the platform itself: what happened when I drove the whole thing as a real client and found tools that lied about what they had done, and the testing discipline that catches that class of failure before an agent builds on it.

The platform behind this series is txn2/mcp-data-platform, available hosted as Plexara.