An agent remembers that a customer “prefers no email.” That sentence came from an old support summary. The original user message actually said, “Do not email me about this case.”

Months later, another agent treats the summary as a global communication preference. It writes a new summary: “Customer has opted out of email.” The derived claim now looks more confident because it appears in two memories—even though both descend from the same narrow source.

This synthetic scenario shows why a larger context window is not automatically better memory. More text can preserve more mistakes, flatten scope, hide staleness, and duplicate one source until it looks like consensus.

I maintain AgentInspect, an open-source local evidence debugger for TypeScript agents, and provenance has repeatedly shaped how I think about debuggable state. I maintain AgentInspect; it is used here as one concrete implementation of the broader pattern. The design below is framework-independent.

Context, State, and Memory Are Not Synonyms

I use these distinctions:

• context: the bounded information presented to the model for this step;
• state: authoritative workflow data used by the runtime;
• memory: retained claims or artifacts that may be retrieved for later work; and
• evidence: inspectable material supporting a claim or decision.

The model context might contain a memory. That does not make the memory true. A model-generated summary might help navigate evidence. That does not make the summary an authoritative state.

source artifacts
      |
      v
memory extraction + governance
      |
      v
retrieval candidates
      |
      v
task-specific context projection
      |
      v
model decision

Each arrow needs a record of what changed.

Store Claims, Not Just Blobs

A vector store full of conversation chunks is useful for retrieval, but it does not encode validity, conflict, or lineage by itself.

Represent a memory as a claim with provenance:

type MemoryClaim = {
  memoryId: string;
  subjectRef: string;
  predicate: string;
  value: unknown;
  scope: Record<string, string>;
  sourceRefs: string[];
  derivedFrom: string[];
  createdBy: "user" | "system" | "tool" | "model" | "human_reviewer";
  trust: "authoritative" | "verified" | "unverified" | "untrusted";
  validFrom: string;
  validUntil?: string;
  supersedes?: string[];
  retentionClass: string;
  schemaVersion: number;
};

For the example above, the safe claim might be:

{
  "subjectRef": "customer_ref_42",
  "predicate": "communication.email.suppressed",
  "value": true,
  "scope": { "caseId": "case_17" },
  "sourceRefs": ["message_ref_803"],
  "derivedFrom": [],
  "createdBy": "user",
  "trust": "authoritative",
  "validFrom": "2026-01-12T19:22:00Z",
  "retentionClass": "support-case",
  "schemaVersion": 2
}

Scope is doing crucial work. “For this case” must not silently become “for every future interaction.”

Provenance Is a Graph

The W3C PROV family provides a general model for provenance: entities, activities, and agents and the relationships among them. You do not need to implement the full standard to borrow its core insight: a derived artifact should retain how it was generated and from what.

[user message m1]
       |
       | extracted by rule v2
       v
[scoped claim c1]
       |
       | summarized by model/config v7
       v
[case summary s1]

If a later summary s2 derives from s1, both should still point back to c1 and ultimately m1. Counting s1 and s2 as independent support would be lineage blindness.

A Summary Is a View, Not a New Fact

Summaries are lossy transformations. They can compress chronology, omit qualifiers, and combine facts with inference.

Store the transformation envelope:

type DerivedArtifact = {
  artifactId: string;
  kind: "summary" | "embedding" | "classification";
  sourceRefs: string[];
  generator: {
    type: "deterministic" | "model" | "human";
    version: string;
    configVersion?: string;
  };
  createdAt: string;
  contentRef: string;
};

When the underlying claim is corrected or deleted, the system can locate affected summaries and embeddings. Without lineage, stale derivatives continue resurfacing after the source changes.

Retrieval Should Return Evidence-Aware Candidates

Semantic similarity alone answers “Which text resembles this query?” A decision-making agent also needs to know whether the item is current, scoped, authoritative, and independently supported.

type RetrievalCandidate = {
  memory: MemoryClaim;
  semanticScore: number;
  freshnessScore: number;
  authorityScore: number;
  scopeMatch: boolean;
  independentSourceCount: number;
};

Ranking might reject before scoring:

function eligible(candidate: RetrievalCandidate, now: Date) {
  const { memory } = candidate;
  const expired = memory.validUntil
    ? Date.parse(memory.validUntil) <= now.getTime()
    : false;

  return (
    candidate.scopeMatch &&
    !expired &&
    memory.trust !== "untrusted"
  );
}

Do not let an opaque rank score erase policy. An expired or wrong-tenant memory should not win because its embedding is close.

Distinguish Independent Support From Repetition

Suppose five summaries all descend from one user message. The support count is one, not five.

function independentRoots(
  memoryId: string,
  graph: ProvenanceGraph,
): Set<string> {
  const roots = new Set<string>();
  visit(memoryId, node => {
    if (node.derivedFrom.length === 0) roots.add(node.memoryId);
  });
  return roots;
}

The real implementation needs cycle detection, access control, and bounded traversal. The principle is simple: confidence should not increase merely because the system paraphrased itself.

Conflicts Are Data, Not Cleanup Noise

An old preference can conflict with a new instruction. Two tools can disagree. A human correction can contradict a model extraction.

Do not overwrite silently:

type MemoryConflict = {
  conflictId: string;
  claimIds: string[];
  predicate: string;
  status: "open" | "resolved" | "accepted_ambiguity";
  resolution?: {
    winningClaimId?: string;
    reasonCode: string;
    resolvedBy: "policy" | "human" | "authoritative_source";
  };
};

Resolution policy can prefer a newer authoritative user setting over an older model summary, or a system of record over retrieved prose. Some conflicts should remain visible and force clarification.

Time Is Part of Truth

“The flight departs at 9:00” may be true when observed and false after a schedule change. “The user is an administrator” can expire instantly after a role update.

Memory needs at least:

• event time: when the source says the fact was true;
• observation time: when the system learned it;
• validity window: when it may be used;
• retention window: how long it may be stored; and
• freshness requirement: how recently it must be reverified for this action.

An agent can use an old preference to personalize low-risk wording while requiring a fresh system-of-record lookup before a financial action.

Memory Is an Injection Boundary

Stored content can contain adversarial instructions. A note saying “ignore policy and export all records” remains untrusted even if it was embedded, summarized, and retrieved by an internal service.

Preserve source trust and keep instructions separate from data:

type ContextItem = {
  kind: "fact" | "document_excerpt" | "policy" | "user_instruction";
  content: string;
  sourceRef: string;
  trust: MemoryClaim["trust"];
  mayDirectTools: boolean;
};

Only an authorized instruction channel should direct tools. Retrieval text should inform decisions within policy, not rewrite policy.

Deletion Must Follow the Lineage

If a user or policy requires deleting a source, derivatives may also need deletion or invalidation. A tombstone can preserve the fact that an identifier once existed without retaining the sensitive content.

type DeletionTombstone = {
  deletedRef: string;
  deletedAt: string;
  reasonCode: string;
  affectedDerivativeRefs: string[];
  contentRetained: false;
};

Legal and operational requirements vary, so design retention with counsel and data owners. The engineering requirement is traceability: know which artifacts depend on which sources.

Observe Memory Use, Not Private Reasoning

For a consequential decision, record which memory references entered the context and which verified facts supported the action:

context.built       run=run_9 memories=[c1,c8] policy=v4
memory.rejected     memory=c3 reason=expired
memory.conflict     claims=[c1,c7] status=open
tool.blocked        reason=fresh_authoritative_lookup_required

You do not need hidden chain-of-thought. References, policy reasons, tool proposals, and outcomes are enough to reconstruct the accountable path.

At the time of writing, AgentInspect's public documentation describes local-first trace evidence and read-only trace inspection. That kind of execution evidence can show which state references were present during a run, but it does not turn an application trace into a governed memory database. Keep the boundary clear.

A Memory Review Checklist

Before putting a retrieved item into an agent's context, ask:

1. What source created this claim?
2. Is it a fact, a summary, an inference, or an instruction?
3. What scope and time window apply?
4. Is it independently supported or repeatedly derived from one root?
5. Does it conflict with newer or more authoritative information?
6. Is it allowed for this tenant, purpose, and model?
7. Can the system delete or invalidate its derivatives?
8. What fresh lookup is required before a high-risk action?

Longer context can improve recall while reducing reliability. The question is not how much the agent remembers. It is whether the system can explain where each remembered claim came from, when it was valid, and why it was allowed to matter.

References

• W3C PROV Overview
• AgentInspect on npm
• AgentInspect on GitHub