Your AI product has amnesia. Here is how to fix it.

The amnesia problem

Every AI product starts the same way. User sends input, AI processes it, AI responds. Next interaction, the AI has no memory of the last one. It is a goldfish with a PhD.

This works for simple tools. Ask ChatGPT to write a regex, get a regex, move on. But for products that operate inside an organisation, in a team with history, conventions, decisions, politics, amnesia is a fatal flaw.

Consider a code reviewer that flags a pattern as a violation. A developer responds, "This is intentional, the TL approved it last month." The reviewer has no way to verify this. Next week, a different developer hits the same pattern. The reviewer flags it again. The team stops trusting it. The product dies.

Two layers, two problems

When you start building memory into an AI product, you quickly discover there are two distinct problems that look like one.

The first is retrieval. Given a new situation, what past knowledge is relevant? This is the classic RAG (Retrieval-Augmented Generation) problem. Embed your knowledge, store vectors, search by similarity. Plenty of tutorials cover this.

The second is trust. Of the knowledge you retrieved, how much of it should you act on? Who said it? When? Did anyone disagree? Is it still valid? This is the problem we think deserves far more attention, and it is the one that determines whether your product is useful or dangerous.

The retrieval layer

The retrieval layer is your product's memory. It answers the question, "What do we know that is relevant to this situation?"

A naive implementation stores text and searches by keywords. This breaks immediately in practice because people describe the same concept in different words. "Date field naming convention" and "fix the timestamp column" are the same topic but share zero keywords.

Vector embeddings solve this. You convert text into a numerical representation that captures meaning, not just words. Two pieces of text about the same concept end up close together in vector space, even if they use completely different language.

But vector search alone is not enough. You also need an entity graph, a structured map of relationships between things. "GiftCardPayment is exempted from RefundablePayment, decided by the TL on May 7th." This is not a fuzzy similarity match. It is a hard fact that the system needs to know.

The retrieval layer stores both embeddings for fuzzy semantic search and an entity graph for precise relational queries. At retrieval time, both run in parallel. The results are merged, deduplicated, and ranked by relevance.

// Three paths run in parallel
const [vectorResults, entityResults, tagResults] = await Promise.all([
  vectorStore.search(namespace, queryEmbedding, { limit: 15 }),
  entityGraph.about(extractedEntities),
  knowledgeRepo.findByTags(namespace, relevantTags),
])

// Merge, deduplicate, rank by score
const context = mergeAndRank([vectorResults, entityResults, tagResults])

The trust layer

Here is where most AI products stop. They retrieve context, inject it into the prompt, and let the AI figure it out. This works until it does not.

The problem is that not all knowledge is equal. A rule documented in an architecture decision record, reviewed by three senior engineers, is fundamentally different from something someone said in a Slack DM six months ago. But if both are stored as text with embeddings, the retrieval layer treats them the same.

The trust layer sits between retrieval and action. It evaluates every piece of retrieved knowledge against a set of governance rules before the AI acts on it.

Source credibility

Not all sources are equal. The trust layer assigns a credibility tier to each source of knowledge.

• Formal (1.0): wiki entries, architecture decision records, signed-off policies. Already verified by definition.
• Semi-formal (0.7): PR review comments, merged code comments, documented meeting notes. Probably accurate, but could be outdated.
• Informal (0.4): Slack public channels, Teams threads, email threads. Context-dependent, might be casual or joking.
• Unverified (0.2): Slack DMs, verbal agreements, patterns inferred from code. Needs explicit verification before acting on.

Source credibility is configurable. Every organisation has different norms. For some, a Slack message from the CTO is gospel. For others, nothing counts until it is in the wiki. The trust layer does not impose a model. It provides the framework and lets the consumer configure it.

Authority and approval

Who said it matters as much as what was said. The trust layer maps people to authority levels and uses those levels to determine how much weight a statement carries.

An intern saying "we should use snake_case" has different weight than the lead architect saying the same thing. Both are stored. Both are retrievable. But the trust layer scores them differently and may require additional verification for the lower-authority statement before acting on it.

Approval rules are configurable per organisation. Some teams need two senior engineers to confirm a new convention. Others need only a team lead. Security-tagged decisions might need the security team explicitly. The trust layer provides the rule engine. The consumer provides the rules.

Dissent is data

Here is something we are determined to avoid. Discarding disagreement.

Someone approves a decision. Someone else raises a concern. The decision is stored as "approved". The concern disappears. Six months later, the concern turns out to be valid, but nobody remembers it was raised.

When dissent exists, the trust layer caps the confidence score. The knowledge is still usable, but the system is honest about the fact that not everyone agreed. When the AI retrieves this knowledge, it can say, "This was approved by the TL, but Alice raised a concern about Q3 compatibility. That concern is still unresolved."

This is not just good engineering. It is how trust works in real teams. People trust systems that are transparent about uncertainty.

The confidence spectrum

The trust layer produces a confidence score for every piece of knowledge. This score determines what the AI does with it.

• Above 0.9: act on it silently. High confidence, multiple confirmations, recent, formal source.
• 0.7 to 0.9: flag it with context. "This looks like a violation of X. Here is why I think so."
• 0.5 to 0.7: ask the person involved. "This might conflict with X. Is this intentional?"
• 0.3 to 0.5: escalate. "I am not sure about this. Let me check with the right person."
• Below 0.3: stay quiet. Not enough signal to say anything useful.

This spectrum is the difference between an AI that annoys people and one that feels like a thoughtful colleague. A confident system that is wrong destroys trust faster than a cautious system that asks.

Four types of questions

When the confidence is in the "ask" range, the type of question matters. Not all questions are the same, and each type enriches the knowledge base differently.

• Clarification: "Just so I understand, is this intentional?" Fills in missing context. The answer teaches intent.
• Confirmation: "This would change the schema that three services depend on. Are you sure?" Guards against high-impact mistakes. The answer teaches risk tolerance.
• Escalation: "This seems above my paygrade. Let me check with the person who owns this policy." Routes decisions to the right authority. The answer teaches org structure.
• Learning: "I have noticed this pattern three times this week. Is this a new convention?" Detects emerging standards. The answer teaches new rules.

Every answer, regardless of type, feeds back into the knowledge base. Clarifications become exceptions. Confirmations become precedents. Escalations establish authority chains. Learning questions become new rules. The system gets smarter with every interaction.

The audit trail

Enterprise customers ask one question before any other. "Can I trace how a decision was made?"

With a trust layer, the answer is yes. Every piece of knowledge has a complete provenance trail. Who initiated it, who was asked to verify, who approved, who dissented, when, and why. This is not a nice-to-have. For regulated industries, it is a legal requirement.

The audit trail also serves a practical purpose. When a rule causes friction ("why is the system blocking my PR?"), the developer can trace it back to the source. "This rule was added by Sarah on March 3rd, approved by the TL, based on the incident report from February." Transparency breeds trust.

Putting it together

The architecture is two layers that compose but do not require each other:

• The retrieval layer (memory): store, embed, search, extract entities, track usage. Pure data, no opinions.
• The trust layer (governance): verify sources, require approvals, score confidence, log dissent, audit everything. Pure judgement, pluggable retrieval.

A product can use just the retrieval layer for basic semantic search. Add the trust layer when you need governance. Use both together for the full experience. Neither depends on the other at the code level.

Why this matters now

Every AI product is about to hit the same wall. The ones that are pure wrappers around LLMs will lose to the ones that accumulate organisational knowledge. The ones that accumulate knowledge recklessly will lose to the ones that govern it properly.

The products that win will be the ones that remember what their users taught them, verify it before acting on it, and are transparent about what they know and how they know it.

Memory without trust is a liability. Trust without memory is amnesia. Build both.

The moat is not the model. The moat is what the model knows about your organisation, and whether you can trust it.

Numstack