ASK KNOX
beta
Learn/Agent Memory 101/Lesson 349
LESSON 349

Writing Good Memories: The One-Fact Rule

A memory store full of transcript dumps is worse than useless — the one-fact rule is the discipline that makes every entry searchable, actionable, and durable.

8 min read·Agent Memory 101

Introduction

You have a memory system. The query-first habit is in place. Contradiction detection is working. Now: what are you actually storing?

This is where most memory systems silently fail. The store fills up with transcript fragments, vague reminders, and multi-topic summaries that degrade every query result. When you search for something specific, you get a wall of loosely related noise back. The memory system becomes a liability.

The one-fact rule fixes this. It is the simplest discipline in memory management and the one most consistently violated.

Core Concept

The One-Fact Rule

One memory entry. One fact. That is it.

A memory entry should express exactly one piece of knowledge: one decision, one pattern, one rule, one lesson. If you find yourself writing "and also" in a memory entry, you have two entries in disguise.

Why one fact per entry?

Precision in retrieval. When an entry covers one topic, a query about that topic returns it. When an entry covers five topics, a query about any of those five topics might surface it — but it is only fully relevant to one of them. Multi-topic entries pollute retrieval results for every topic they partially address.

Actionability. One fact = one action. When the agent retrieves "use the bridged token, not the native token, for all on-chain transactions in this project," it knows exactly what to do. When the agent retrieves a paragraph covering payment tokens, blockchain considerations, wallet setup, and transaction fees, it has to parse what the actual rule is — introducing interpretation error.

Maintainability. When a fact changes, you update one entry. When you have combined facts, changing one part of the entry risks invalidating the other parts.

The Four-Component Structure

A well-formed memory entry has four components:

1. The fact itself. One sentence. Specific, concrete, unambiguous. Not "we usually prefer X" but "always use X for all production deployments as of 2026-03."

2. The why. One to two sentences explaining the rationale. This is what allows future agents to evaluate whether the rule still applies when circumstances change. Without the why, a rule is a black box.

3. The when. A date. When was this fact established or last confirmed? Without a date, there is no basis for trust score decay and no way to flag stale entries.

4. The scope. What context does this fact apply to? Project name, environment, system, team. Not all facts are global.

Example of a well-formed entry:

FACT: Use bridged USDC (USDC.e), not native USDC, for all on-chain transactions in this project.
WHY: The bridged token has deeper liquidity on the target DEX; the native token has insufficient
     liquidity and causes failed fills at production volumes.
WHEN: 2026-01-22
SCOPE: payments-service, polygon-mainnet

That entry is retrievable, actionable, and evaluable. A future agent can read it and know: (a) the exact rule, (b) why it was established, (c) how old it is, and (d) where it applies.

What NOT to Store

Transcripts and conversation logs. The full back-and-forth of a session is not memory — it is raw material. Extract the decisions, patterns, and findings. Store those as individual entries. Discard or archive the transcript itself.

Obvious facts. "Python requires indentation" does not belong in your knowledge store. Memory should contain facts that are specific to your context, your project, your decisions. General knowledge is already in the model.

Unresolved hypotheses presented as facts. "The timeout issue might be related to the load balancer" is a hypothesis, not a fact. Store it if you want to track the investigation, but label it as such: HYPOTHESIS (confidence: 0.3): ...

Everything from every conversation. The goal is a curated store of durable, high-value knowledge — not a complete record. Selectivity is a feature, not a limitation. If you store everything, you have stored nothing in practice, because the signal-to-noise ratio collapses.

The Extraction Habit

Good memories are rarely written in real time. They are extracted after the fact, from the outcomes of work.

The pattern:

  1. Complete a task
  2. Ask: what did I learn that I did not know before this task?
  3. Ask: what decision was made that will constrain future work?
  4. Ask: what failure mode did I encounter that I should remember to avoid?
  5. Write one entry per answer

This takes two minutes. It is the discipline that compound learning is built on. A well-configured agent framework does a version of this at session end — the "advice-to-future-self" pattern — writing what it learned to the semantic memory layer before shutting down. The next session starts with that knowledge pre-loaded.

Practical Application

A developer finishes a debugging session where they discovered that a particular API endpoint returns 200 even on error conditions — you have to check the status field in the response body.

Bad memory storage (transcript dump):

Long debugging session. API was returning 200 but things were failing. Eventually 
figured out you have to check the status field in the body. Also looked at timeout 
settings and some other stuff. Fixed the issue.

This entry is almost worthless. It cannot be retrieved precisely. A future agent querying "API error handling" might get this, but then has to parse the narrative to find the actual rule.

Good memory storage (one-fact rule applied):

FACT: The /submit endpoint returns HTTP 200 even on failure. Check response body 
      field 'status' for "error"|"success" — do not rely on HTTP status code.
WHY: Discovered 2026-05-29 during auth flow debugging. Root cause: legacy API 
     contract, never corrected for backwards compatibility.
WHEN: 2026-05-29
SCOPE: payment-service, /api/v2/submit endpoint

Specific, actionable, scoped, and dated. A future agent querying "payment-service API errors" or "/submit endpoint" retrieves this entry and knows exactly what to do.

Common Mistakes

"I'll clean it up later." Transcript dumps accumulate. The cleanup never happens. Build the one-fact discipline into your storage process from the start, not as a retrospective cleanup project.

Storing what happened instead of what was learned. "We debugged the authentication issue" is an event, not knowledge. "The authentication failure was caused by clock skew exceeding 5 minutes between service and token issuer" is knowledge. Store the learning, not the event.

Writing facts without the why. Rules without rationale become cargo cult rules. Future agents — and future humans — follow them without understanding them, cannot evaluate when they should be updated, and cannot explain them to others.

Scope creep on single entries. "Use X instead of Y for A, B, and C, unless D, and also remember to check E." This is three or four entries. Every "and also" in a memory entry is a red flag.

Summary

  • One memory entry, one fact — the one-fact rule is the core discipline
  • Every entry needs four components: the fact, the why, the when, and the scope
  • Do not store transcripts — extract decisions and store those as individual entries
  • Store what was learned, not what happened
  • Build the extraction habit into the end of each work session
  • Selectivity is a feature — a curated store of 100 precise entries beats a dump of 1,000 vague ones

What's Next

You are writing good memories. But what about the memories that have gone stale, are now wrong, or have been superseded by newer decisions? In the next lesson, we cover memory pruning — when forgetting is actually the right move for a healthy knowledge store.