Your AI analyst needs a brain, not a vector store

Ask a new analyst what actually slows them down in their first months and they will not say SQL — they will say conventions. Which benchmark applies to which mandate, and the two mandates where the obvious answer is wrong. Why comparisons that reach back before 2024 have to use the _hist tables, because the migration that year changed how positions are keyed. The fact that the ESG provider keys on SEDOL while the warehouse keys on ISIN, and that fourteen names silently vanish from any join that forgets the bridge table.

None of this is written down anywhere useful. It lives in the heads of the two people who have been on the desk longest, in chat scrollback nobody can search, and in the margins of presentations that have been superseded twice. It is the knowledge that makes analysis correct — and when an AI agent starts doing analysis, the question of whether it holds this knowledge stops being a nice-to-have and becomes the difference between an answer and an incident.

The industry's default answer is retrieval-augmented generation: embed your documents, search by similarity, stuff the nearest chunks into context. We built something different, and this article is the argument for why. The short version: institutional knowledge is structural, and similarity search is structure-blind.

Why similarity search loses structured knowledge

Here is a real shape of knowledge from the world our demo scenarios live in — the canonical join for as-of pricing, and the caveat that makes it correct:

1SELECT h.*, p.close2FROM holdings h3ASOF JOIN prices p4ON p.isin = h.isin AND p.ts <= h.ts5-- never p.ts = h.ts: look-ahead bias.6-- promoted to house standard after the Q1 incident.

The SQL is the easy half. The load-bearing half is everything attached to it: this pattern applies to backtests and any analysis joining prices to holdings; it was validated by the desk head after an incident; it constrains a specific class of query; and the <= is not a style choice but the entire point. Now run the failure case: an embeddings-based memory, asked about joining prices, happily retrieves the SQL — it is very similar to the question — and just as happily omits the caveat, because the caveat lives in a different chunk with a different embedding, and nothing structural says these two are inseparable. The agent writes a clean-looking join with = instead of <=, the backtest quietly looks ahead, and the error is invisible precisely because everything retrieved was "relevant."

Similarity tells you what sounds related. It cannot tell you what applies, what comes attached, or what has been replaced — because those are edges, not distances.

A knowledge graph, not a document pile

DataQube's memory is a graph. Definitions, example queries, caveats, decisions, and skills are typed nodes, linked to the workspaces they're scoped to, the data sources they describe, and the tools they constrain. The edges are typed too — applies-to, caveats, derived-from, supersedes — and a single pair of nodes can carry several at once: the look-ahead caveat above is simultaneously about the prices source and a constraint on the join pattern, which is exactly why no recall of that pattern can arrive without it.

Recall is then a graph traversal, not a nearest-neighbor search. When an agent starts work in a workspace, it pulls the neighborhood: the definitions scoped there, the caveats attached to every source and tool it is about to touch, the skills promoted from past validated work. The pricing caveat doesn't get retrieved because it resembles the question — it gets retrieved because it is attached to the thing being used. Resemblance is optional; attachment is not.

Knowledge that knows when it's wrong

Storage was never the hard part. The hard part — and, we would argue, the actual product — is invalidation. Institutional knowledge goes stale on no schedule: a definition changes after an incident, a data source gets rekeyed, a convention is overturned by a committee that didn't think to tell anyone.

Here is how that plays out in DataQube, using the incident our demo scenario is built on. A pricing-snapshot problem forces the desk to change its definition of active return. The moment the new definition is validated, the old one is superseded: it stops being recalled instantly, everywhere, with no cache to age out. But it is not deleted — it stays in the graph, linked to its replacement, stamped with when it stopped being true. That last property is what makes the system auditable rather than merely current: when someone reviews an analysis from before the change, the record shows it was produced under the definition that was valid then — which is the difference between "the analysis was wrong" and "the definition changed later," a distinction auditors care about a great deal.

The front door matters as much as the exit. Candidates extracted from conversations — "the agent noticed the desk always excludes seed share classes" — enter quarantined: visible, attributable, and never recalled until a person validates them. Nothing the agent inferred can silently become something the agent relies on. The validation itself is an event on the record: who approved this piece of knowledge, when, from which conversation it came. House standards carry their whole chain.

The rejected alternative here is the one that sounds most appealing: let the system learn continuously, trust that good knowledge crowds out bad. In a consumer product that is a reasonable bet. In a regulated one it means your agent's beliefs are an unaudited, self-modifying input to every number it produces — and the first time a wrong inference contaminates a quarter of answers, you will not be able to say when it arrived or what it touched.

What recall looks like in a live run

Here is the full loop in the product — validated knowledge arriving before the first query fires, and a new candidate leaving into quarantine at the end:

Replay run

Based on real customer conversations — all data fictional.

Note the shape of what was recalled: not documents that resemble the question, but the definitions scoped to this workspace and the caveats attached to the sources this run is about to use. And note what leaves: a candidate, clearly marked as pending validation, going nowhere near future recalls until someone with the standing to approve it does.

The one-question test

If you are evaluating agent memory, ask the vendor this: when a definition changes, show me what happens to the old one — and show me what your system serves for an analysis dated before the change. A similarity store has no good answer; old and new chunks coexist, and retrieval picks by resemblance and recency heuristics. A graph with supersession semantics answers precisely: the new definition everywhere from the moment of validation, the old one preserved with its validity window for anyone auditing the past.

A memory system without supersession semantics doesn't accumulate knowledge. It accumulates liabilities — fluent, confident, and increasingly wrong. How the memory module fits the rest of the platform is on the product page, and if you want to see the quarantine flow live, book a demo and teach the agent something false — then watch it fail to matter.