Why Agents Forget — and What a Knowledge System Is

The Problem No Context Window Solves

A session has a start and an end. When it ends, the context window — every instruction, every observation, every correction the agent received during that session — is gone. The next session begins at zero.

This is not a flaw. It is the intended behavior of every transformer-based model. Context windows are working memory: fast, large, immediately accessible, and completely ephemeral. They are not storage. Nothing persists unless something explicitly writes it somewhere.

The consequence is predictable: a 24/7 agent platform where every correction evaporates at session end. The team corrects the agent on Tuesday. On Wednesday, the agent makes the same mistake. The team corrects it again. This cycle does not converge. Without a persistent layer, the same error can recur indefinitely — not because the model is incapable of learning, but because there is no mechanism for learning to survive the session boundary.

The hierarchy above names the four layers clearly. In-context memory (this turn) and session memory (this run) are ephemeral. They are where computation happens. Persistent memory (all runs) and organizational memory (all agents) are where knowledge lives. Building a knowledge system means designing all four layers intentionally — not treating the context window as the only layer that exists.

What a Knowledge System Actually Is

A knowledge system is not a "remember this" feature. It is an architecture with four distinct components:

A write path. The mechanism by which knowledge enters the store. Not a log — a gated process that searches before storing, deduplicates, and maintains supersede chains so corrections replace rather than accumulate. The write path is where most implementations fail, because building an append-log is trivial and building a dedupe gate is not.

An index. The embedding and retrieval infrastructure that makes stored knowledge searchable by meaning, not just by exact key. This track builds on top of the pgvector foundation you built in the prerequisite — the same text-embedding-3-small embeddings, the same cosine distance operator, the same HNSW index.

A recall path. The mechanism by which knowledge is surfaced at session start and during task execution. Progressive disclosure: summaries first, full content only when confirmed relevant. Every recalled token competes with task context, so the recall path has a budget discipline.

A lifecycle. The policies that govern how memories evolve, expire, get superseded, and get cleaned. A memory system without lifecycle is a memory system that rots. Facts become stale. Working notes accumulate. Duplicates spread. Lifecycle is what separates a knowledge OS from a junk drawer.

Three Tracks, Three Distinct Problems

Before going further, a precise statement of where this track sits relative to others in this academy.

vs agent-memory-101 (Getting Started tier): that track explains why agents forget and introduces the vocabulary. This track builds the actual system — schema, write path, recall, lifecycle. If you have done agent-memory-101, this is the implementation course. If you have not, the conceptual model you need is in this lesson.

vs production-mcp-servers: that track builds the MCP transport and plumbing an agent uses to reach a memory store — the protocol layer, the tool handlers, the auth guards. This track owns the memory architecture behind any transport. You need both, but they are separate concerns: transport is how the agent reaches the store; architecture is what the store does.

vs rag-in-production (the prerequisite): RAG retrieves from a corpus of documents you curate. A knowledge system accumulates memories the agent itself writes. Same semantic layer — embeddings, cosine search, pgvector — but the write path is inverted. Documents are ingested by an operator; memories are earned by the agent through experience. This is not a semantic distinction. It changes who controls quality, how freshness is maintained, and what lifecycle policies apply.

The diagram above shows the cost of the missing write path concretely. Same five sessions. The amnesiac agent re-learns the same lesson in session 2, session 4 — the correction never accumulates. The compounding agent writes the correction to the store in session 1, hydrates it in sessions 2 and beyond, and never needs to re-learn it. By session 3, it has extended the knowledge rather than replaying it.

The Canonical Schema

Every example in this track touches a single table. Commit the column names now:

CREATE TABLE memories (
  memory_id   TEXT PRIMARY KEY,
  namespace   TEXT NOT NULL DEFAULT 'global',
  memory_type TEXT NOT NULL,            -- 'episodic' | 'semantic' | 'procedural' | 'working'
  heading     TEXT NOT NULL,
  content     TEXT NOT NULL,
  embedding   vector(1536),
  confidence  REAL NOT NULL DEFAULT 0.7,
  source_type TEXT NOT NULL DEFAULT 'derived',  -- 'raw' | 'derived' | 'output'
  supersedes  TEXT,                     -- memory_id this replaces
  expires_at  TIMESTAMPTZ,              -- working-memory TTL; NULL = no expiry
  deleted_at  TIMESTAMPTZ,              -- soft delete; NULL = live
  created_at  TIMESTAMPTZ DEFAULT now(),
  updated_at  TIMESTAMPTZ DEFAULT now()
);
CREATE INDEX ON memories USING hnsw (embedding vector_cosine_ops);

Every column earns its place. memory_type drives lifecycle policy — a working memory gets an expires_at, a procedural memory does not. confidence is a first-class signal for recall ranking and health monitoring. supersedes is the link that turns updates into auditable chains rather than silent overwrites. deleted_at is always a soft delete — you never lose history. source_type records whether the fact came from a human (raw), agent synthesis (derived), or a produced artifact (output).

The TypeScript row type mirrors it exactly:

interface MemoryRecord {
  memory_id: string
  namespace: string
  memory_type: "episodic" | "semantic" | "procedural" | "working"
  heading: string
  content: string
  confidence: number
  source_type: "raw" | "derived" | "output"
  supersedes: string | null
  expires_at: Date | null
  deleted_at: Date | null
}

What This Track Builds

Each lesson in this track implements one component of the knowledge OS. The memory-taxonomy lesson establishes the taxonomy — what types of memory exist and how provenance is tracked. The write-path lesson builds the write path with its dedupe gate. The recall lesson implements progressive-disclosure recall. The second half of the track covers namespaces, lifecycle hygiene, session assembly, and the compounding loop that makes corrections permanent. The capstone assembles all components into a working system.

If you completed the RAG in Production track, you have the retrieval infrastructure already. The pgvector setup, the embedding pipeline, the cosine query pattern — all of it carries forward. What you are building here is the write side of that infrastructure: the agent's ability to learn, and to keep learning, across every session it runs.