memnode
Sign InSign Up
Back to Articles

The Trust Hierarchy: Epistemic Types and Source Trust in Agent Memory

Not all agent memories deserve equal weight. How memnode tags each memory with an epistemic type (observed, reported, inferred, hypothesized) and a source trust signal, and how those feed canonization, recall ranking, and duty-class memory.

memnode9 min read
agent memorymemnodeepistemic typetrustprovenancedesign notes

Most agent memory systems treat every record as equally true. A fact the agent watched happen, a claim a stranger typed into a chat box, a guess the model made to fill a gap, all land in the same flat store and come back out with the same weight. That is how an agent ends up confidently repeating something it never actually knew. The fix is not a bigger model or a better embedding. It is a memory layer that records how it learned each thing, and then lets that shape what it trusts.

memnode treats trust as a structural property of memory, not an afterthought bolted onto access control. Two signals do most of the work. The first is the epistemic typeof a memory: was it observed, reported, inferred, or merely hypothesized. The second is source trust: who or what stood behind it. Together these feed canonization and shape how strongly an answer is asserted at recall. This article walks through the hierarchy, while keeping the tuning knobs deliberately vague, because the exact weights have to be earned empirically.

Not all memories deserve equal weight

Start with an intuition every engineer already has. If a teammate says the test passes, you believe it a little. If you run the test yourself and watch it go green, you believe it a lot. If someone reasons it should pass because nothing touched that module, you believe it conditionally. And if someone says I bet it passes, that is a hunch. The information content is similar. The trust is not.

A flat memory store erases that distinction. When two memories collide, the agent gets both back with no guidance on which to lean on. memnode encodes the distinction at write time and carries it through the whole lifecycle, so the difference between a verified observation and a discarded hypothesis survives long after the session that produced them.

The epistemic types

Every node declares an epistemic type when it is written, and the recording call requires the caller to say what kind of knowledge this is. That forces a moment of honesty at the exact point where most systems just dump text. The types are:

  • observed means the agent saw it directly. It ran the command and read the exit code. It watched the deploy finish. This is the strongest first-hand category.
  • reported means someone told the agent. A user statement, a third-party document, a log line written by another system. The fact may be perfectly true, but the agent is taking it on someone else's word, so its weight depends on the source.
  • inferred means the agent derived it from other memories. Nobody stated it and the agent did not observe it. It is a conclusion, only as sound as the premises and the reasoning underneath it.
  • hypothesized means a guess or a candidate explanation. A working theory the agent is entertaining, not asserting. This is the weakest type and is meant to be held lightly until evidence promotes or kills it.
  • summary means a compression of many underlying memories into one statement. It is downstream of other knowledge, so it inherits trust from what it summarizes and is expected to point back at that source material.
  • procedural means a stored way of doing something rather than a claim about the world. A sequence of steps that worked before. It is judged by whether it keeps working, not by whether it is observed or reported.

The point is not to rank these on a single line from good to bad. It is that they are different kinds of knowledge that should never be silently blended. An observation and a hypothesis about the same subject can coexist, but the system has to know which is which so it never asserts a guess with the confidence of a fact.

Why source trust matters separately

Epistemic type tells you how the memory was acquired. Source trust tells you how much weight the origin itself carries. These are independent axes, and you need both. A reported fact from a senior maintainer who owns the subsystem is worth far more than the same epistemic type from a drive-by comment on an issue, even though both are nominally reported. And the agent's own inferred conclusions are treated with the skepticism a system should reserve for its own guesses.

Each memory therefore also carries a record of where it came from: a user, an agent, the system itself, an import, or an inference. That origin feeds a source trust signal that modulates how seriously the memory is taken. A user statement and an imported document are both external, but they are not equally authoritative, and the consolidation and recall paths treat them differently. The principle is simple to state and the precise weighting is where the engineering judgment lives, so we keep the exact numbers and thresholds internal.

A fact observed directly by a user is more reliable than one inferred by an agent, which is more reliable than one imported from an external document. Most memory systems treat all sources equally. memnode does not.

How type and trust modulate promotion

These signals are not decoration. They gate the journey a memory takes from raw observation to trusted belief. New information always lands as episodic and provisional: the agent observes, the system decides what to trust. Memory that arrives from outside the agent, anything imported, inferred, or shared, enters quarantine by default and cannot influence a confident answer until it earns its way out. This is the same self versus non-self instinct an immune system uses, and it is the structural defense against memory poisoning, where a planted claim survives a restart and quietly corrupts later decisions.

Promotion toward canonical status is rule-gated, and epistemic type plus source trust are inputs to those rules. A claim climbs by accumulating support from independent episodes, keeping contradiction pressure low, and surviving repeated successful recall. A high source trust shortens that climb; a low one lengthens it. A hypothesized memory should not be able to masquerade as canonical no matter how often it gets recalled, because recall frequency is not evidence of truth. The exact support counts, trust floors, and stability windows are tunable and proprietary, but the shape is the same everywhere: nothing becomes canonical automatically, and weaker provenance carries a heavier burden of proof.

How they modulate recall

The same two signals shape the other end of the loop. When the agent asks a question, memnode does not dump the nearest vectors. It assembles competing candidates and returns the winning interpretation along with a confidence and a justification. Epistemic type and source trust adjust the scoring there too, so a well-supported observation from a trusted source outranks an inferred claim from a weak one, even when the inferred claim happens to be a tighter semantic match.

Crucially, these signals also govern how strongly the answer is asserted. A canonical fact built on direct observation comes back stated plainly. A claim that is still provisional, or that rests on inference or a single low-trust report, comes back hedged, surfaced as contested, or withheld in favor of an honest insufficient knowledge response. Task context sharpens this further: a strict-facts recall mode leans hard on canonical status and source trust and refuses to serve provisional nodes at all, which is what you want when the cost of being confidently wrong is high.

Duty-class memory: scoping trust to a responsibility

Some knowledge is too consequential to live under the same rules as everything else. A note about a user's favorite color and a billing policy that decides what a customer is charged are not the same kind of fact, even if both are technically reported and canonical. memnode is designed to recognize this through duty-class memory: memories scoped to a role or a responsibility, such as billing policy, security rules, compliance facts, and customer entitlements.

Duty-class memory is designed to carry stricter canonization thresholds, to be excluded from automatic synthesis so the engine never invents a new policy by blending two old ones, to require explicit correction logging, and to never be auto-archived. The same design line extends to role-based filtering, where an agent only recalls the slice of memory appropriate to the role it is acting in. These role and duty-class behaviors are design-complete in the roadmap rather than fully shipped, so treat them as where memnode is heading. The intent is clear: the higher the stakes, the higher the burden of proof, and the narrower the blast radius if something is wrong.

Where it came from and what it becomes

Trust signals only mean something if you can audit them, which is why epistemic type and source trust sit on top of full lineage. Every consolidated belief can answer where it came from: which episodes supported it, which corrections reshaped it, how its status changed over time. You can pull up a canonical fact, trace it back to the original observed episode, and watch the moment a contradiction was resolved. The trust hierarchy is the input; lineage is the receipt.

The destination is canonization. Type and trust feed the gate that decides what the memory system actually believes versus merely stores. A memory that starts as a quarantined import, earns support, clears the trust floor for its class, and survives a stability window can become canonical. One that stays a low-trust hypothesis never does. The full lifecycle is covered in the canonization article.

A concrete example

Picture a DevOps agent maintaining a service. Walk one fact through the hierarchy.

turn 1  user says: "the staging deploy script lives at deploy/staging.sh"
        -> reported, source trust: medium (single user statement)
        -> lands episodic / provisional

turn 2  agent runs the script, watches it deploy successfully
        -> observed, source trust: high (first-hand)
        -> supports the reported claim; contradiction pressure stays low

turn 3  agent reasons: "since staging uses deploy/staging.sh,
        prod probably uses deploy/prod.sh"
        -> inferred, source trust: low (agent's own guess)
        -> stays provisional; never asserted as fact

later   consolidation sees the observed episode backing the
        reported path, repeated successful recall, no rebuttals
        -> staging path promoted toward canonical
        -> the inferred prod path is NOT promoted

Now the payoff. When the agent later asks where is the staging deploy script, it gets a plainly asserted canonical answer backed by an observation it made itself. When it asks about the prod script, it gets a hedged response, or an explicit I inferred this but never verified it, because that memory is still an inference from a low-trust source. The agent does not reason about which memory to believe; memnode encoded that judgment at write time and enforced it at recall. In a flat store all three turns would come back as equally weighted strings, and the agent might confidently state the prod path it only guessed with the same weight as the staging path it watched run. That is the difference between storing text and maintaining beliefs with evidence.

The takeaway

A trustworthy agent is not one that remembers more. It is one that knows the difference between what it saw, what it was told, what it worked out, and what it guessed, and that carries that difference forward into how strongly it speaks. Epistemic type plus source trust give memnode that spine. They gate promotion so weak provenance has to earn its place, they shape recall so answers are asserted only as strongly as their evidence allows, and combined with duty-class scoping they put the heaviest burden of proof on the highest-stakes facts. The result is a memory layer you can interrogate, with a clear answer to the only question that ultimately matters: how do you know that?

The memnode design series

For the bigger picture of how these pieces fit together, see the memnode evolution overview.