Memory From First Principles on AIBussin — AI applications, systems and books

What Remembering Means

Mon, 14 Sep 2026 05:00:01 +0100

A small team spends a week arguing about where to keep its event log.

They start with SQLite. It works at first, then slows to a crawl once several writers hit it at once. So they move the event store to PostgreSQL and write down why. Within a month nobody thinks about it any more. It is just how the system works.

A few months later, a new contributor asks the team’s AI assistant to scaffold a second service, with its own event log.

The Measurement Instrument

Mon, 14 Sep 2026 05:00:02 +0100

Chapter 1 ended with a test. Does the past change what the system does now, and does it change it for the better?

That is easy to state and hard to run. This chapter builds the thing that runs it.

Two words will recur for the rest of the book, and they must not blur together. The memory system is the thing that remembers. The instrument is the apparatus that decides whether it does. They are separate products, and this book builds both.

The RAG Baseline

Mon, 14 Sep 2026 05:00:03 +0100

The simplest answer to the memory problem is also the one every more elaborate system has to beat: keep the project history, retrieve the parts that look relevant, and let a capable model read them.

That approach already has many of the ingredients people casually call memory. The past is retained. A query selects evidence from it. A reader interprets that evidence in the context of the present task. If the resulting behaviour improves because the right part of the past was recovered, the system has done something useful without maintaining a separate persistent account of what the project believes, what changed, or what should be remembered next.

From Retrieval to Persistent Understanding

Mon, 14 Sep 2026 05:00:04 +0100

Chapter 3 built the strongest conventional retrieval the book could assemble, and left it standing. That result constrains this chapter before it starts.

The usual argument for structured memory goes: retrieval finds text, but it does not understand it. About the system Chapter 3 actually built, that is simply false. A hybrid retriever, a cross-encoder reranker, and a capable reader already do a great deal of interpreting.

Watch what that reader does. It tells proposals from decisions when the passages allow it. It follows rationale across artifacts. It abstains when the evidence runs out.

Pathways Through Memory

Mon, 14 Sep 2026 05:00:05 +0100

Chapter 4 set out to give the system a map. Instead of reconstructing meaning from raw passages at every query, it keeps interpretation: entities, relationships, claims, communities, each traceable back to the artifact it came from. Whether that map pays for itself is Chapter 4’s own question and Chapter 4’s own experiment; nothing here assumes its verdict.

This chapter asks a question that arises either way. Suppose the map exists. A map is a structure to search, but associative recall suggests a different mechanism: one memory evokes another, which evokes another, until useful evidence appears several steps from the original cue.

The Memory Nexus

Sat, 19 Sep 2026 05:00:06 +0100

Chapters 3 through 5 leave the system with an embarrassment of options. Chapter 3 built hybrid retrieval over raw history with reranking. Chapter 4 added a persistent derived graph with several query modes. Chapter 5 added cue-conditioned associative propagation over that graph. Each chapter earned its mechanism conditionally, and each left the cheaper layers available underneath. The question none of them answers is the one a deployed system meets first:

Why

Sat, 19 Sep 2026 05:00:07 +0100

Chapters 3 through 6 leave the system with a working pipeline and an uncomfortable surplus. Chapter 3 retrieves raw history. Chapter 4 derives a persistent graph from it. Chapter 5 propagates activation across that graph. Chapter 6 chooses between these mechanisms. A candidate memory reaches the reader, the reader writes an answer, and the answer contains claims about the project. This chapter asks the book’s third question — why did we decide or believe this? — in the form the pipeline forces:

Is It Still True?

Mon, 14 Sep 2026 05:00:08 +0100

The same events, a different story

Consider three remembered events from the migration history:

A = benchmark detects SQLite contention
B = team decides to adopt PostgreSQL
C = PostgreSQL deployment completes

As an unordered set, {A, B, C}, the system knows all three happened.

As a trajectory, A → B → C, it knows something stronger. The benchmark preceded the decision, and the decision preceded the deployment.

Now hold the contents constant and change only the order, to B → A → C. Nothing was added. Nothing was removed.

What Did We Leave Unfinished?

Mon, 14 Sep 2026 05:00:09 +0100

Chapter 8 left the system with a way to maintain belief through time. That system is a good historian. This chapter shows where it is a poor colleague: it can reconstruct the past, but it cannot yet tell a closed chapter from an open obligation.

The migration is finished. The work is not.

Extend the running migration history past the July decision:

Thursday 11 July, adr-007:
Decision: move the event store to PostgreSQL.

Monday 15 July, commit-112:
On the migration branch, application writes use PostgreSQL in staging.
Production still uses SQLite.

Wednesday 17 July, session-051:
"Importer is green on PostgreSQL. Backups still target
SQLite — need to move those before release."

In the canonical history this opens intent-401, which stands open at the 23 August cut and completes with commit-118 on 27 August, three days before release-024 ships on 30 August.

What Matters Right Now?

Mon, 14 Sep 2026 05:00:10 +0100

Chapter 9 finished the first arc. Seven layers now stand between raw history and an answer: retrieval, a persistent graph, associative pathways, routing, support lineage, temporal validity, open-loop status. Each was introduced against a specific failure class, with some already bounded or conditional by its own experiment. None has yet been asked the question that decides whether the accumulated machinery was worth building.

A context window is small and history is not. For every execution, something chooses which fraction of the past the model is allowed to see. So far that choice has been made by one mechanism: similarity to the words of the request. The enrichment of Chapters 4 to 9 sits behind that gate, but query-only similarity cannot condition selection on the work now being done.

Consequences Nobody Wrote Down

Mon, 14 Sep 2026 05:00:11 +0100

Chapter 9 handles work the history states: promises, assignments, follow-ups with an established expectation behind them. This chapter pushes Question 5 past conventional task tracking, to consequences nobody wrote down. The migration broke assumptions encoded in fixtures, documentation, and configuration that no session mentions. A memory that tracks only stated intentions will report the open list as empty while the project quietly rots. Whether anything can be done about that — reliably, without inventing obligations — is treated here as a difficult hypothesis, not a capability.

Does Better Context Change Behaviour?

Mon, 14 Sep 2026 05:00:12 +0100

Chapter 1 defined memory behaviourally. Remove the past, rerun the present task, and ask whether behaviour changed — and whether the change was an improvement.

Eleven chapters later, that test has never actually been run.

Chapters 3 to 11 built a pipeline — retrieval, structure, association, routing, lineage, temporal state, open loops, frames, derived consequences. Each stage was measured against ledgers of what the context contains.

Then an assembly experiment under a tight token budget produced an anomaly. At a 768-token budget, the assembled context holds required-evidence recall of only 0.72, yet the reader answers at 0.955 key-claim coverage — better than the full raw context at 0.879.

When the Frame Is Wrong

Mon, 14 Sep 2026 05:00:13 +0100

Chapter 12 ended with leverage. In the wrong-memory condition, success averages 0.042 across four tasks, with harmful actions on two.

In that controlled intervention, a layer deciding what the model may see can cause a harmful action — not merely fail to prevent one.

So the next question is when the system should trust its own framing that strongly.

Frame establishment here does not rest on classifier confidence. It is derived from explicit, temporal, provenance-preserving evidence relations. A reconciliation records that two representations relate, without ever asserting what is true.

Context Is a Bottleneck

Mon, 14 Sep 2026 05:00:14 +0100

Chapter 10 took selection as far as a frozen run has taken it: which memories the present work needs, admitted by an explicit, traceable policy at a fixed budget.

This chapter shows selection is not enough. Admission assumes the admitted memories fit. Increasingly they do not — and the Chapter 10 run puts a number on the shortfall.

The ledger oracle reaches perfect required-evidence recall on a mean of 587 estimated tokens. The best non-oracle Chapter 10 condition spends 1,161 to reach 0.902 recall. Rendered with the source headers and validity marks the reader actually sees, those become roughly 805 against 1,505. The gap survives rendering.

What Should Memory Keep?

Mon, 14 Sep 2026 05:00:15 +0100

Chapter 14 ended with an unexpectedly useful result. Once the candidate set was already good, elaborate assembly did not uncover a large reservoir of duplicate text waiting to be removed. Extractive deduplication saved only eighteen of 1,174 counted tokens on the frozen C5 bundles. The larger problem was competition: many individually defensible memories still occupied the same scarce working context, and the system had to decide what should continue to matter for the present task.

Learning From Experience

Mon, 14 Sep 2026 05:00:16 +0100

Chapter 15 asked how a long-lived memory system keeps accumulated history manageable without destroying what later work may still need. That remains memory management: the system changes which retained experiences are represented, available, or allowed to compete.

This chapter crosses a different boundary.

Suppose the system performs a migration, observes that it succeeded, and then changes what it will retrieve next time. Suppose it notices that the same sequence of checked actions has worked repeatedly and turns that sequence into a reusable method. The system is no longer only asking what the past contains or which part matters now.

Can Memory Be Trusted?

Mon, 14 Sep 2026 05:00:17 +0100

The book’s definition forces this chapter. Memory is when retained past experience changes present behaviour — and Chapters 12 and 13 showed that change running in both directions, including harmful actions under wrong memory and under some fallback conditions. If a line in retained history can change what the agent does today, then admitting that line is no longer harmless. The progression the book has been climbing ends one step further than behaviour:

The Remembering System

Mon, 14 Sep 2026 05:00:18 +0100

The book began with a deliberately strict definition:

Memory is when retained past experience changes what the system does now.

Everything else — vector stores, graphs, temporal state, context selection, consolidation, procedures — is mechanism.

That distinction changes what a final chapter should do.

The original plan saved the behavioural test for the twentieth chapter and imagined a full stack in front of it: events, claims, provenance, belief, open loops, policy, context assembly, consolidation, compression, forgetting, outcome adaptation, procedures, then behaviour. The experiments did not follow that plan. Selection moved earlier. Context assembly was measured before long-term compression. Derived state produced both benefits and hazards. Simple mechanisms repeatedly matched or beat ambitious ones. Chapter 12 was moved forward specifically to test the behavioural definition before the book accumulated more machinery.

Appendix — Building a Remembering Agent

Tue, 22 Sep 2026 05:00:19 +0100

The book began with a distinction that sounds simple and becomes increasingly demanding the longer we follow it:

Memory is when retained past experience changes what the system does now.

A database is not memory.

A vector index is not memory.

A conversation transcript is not memory.

Retrieval is not memory.

All of those things may participate in a memory system, but none is sufficient by itself. A system begins to remember when something from its past survives, is found again, is interpreted in the right temporal and operational context, is judged appropriate to use, and changes present behaviour.