Semantic Memory (Agent)

You remember that Paris is the capital of France, but not the afternoon you learned it. That split — the fact kept, the episode discarded — is what semantic memory names. For an agent it is the store of durable general knowledge: facts, definitions, user preferences and relationships, held free of the particular run in which they were acquired.

How it is built
In practice it is a retrieval store rather than a transcript. Observations from a run are distilled into standalone statements — the deploy script lives in the ops directory; this user wants dates in ISO format — then embedded and written to a vector or graph store. On later runs the agent retrieves the few statements relevant to the current step and places them in its context window. Writing is a deliberate act: something has to decide a fact is worth keeping, deduplicate it against what is already stored, and resolve the conflict when a newer observation contradicts an older one.

Why it matters
Semantic memory is what makes an agent useful on the second day. Without it every session rediscovers the same project layout and re-asks the same preferences, and the only alternative — replaying whole past transcripts — exhausts the context window. It is the counterpart to episodic memory, which keeps what happened, and procedural memory, which keeps how to do things. Its failure mode is quiet: a stale fact retrieved with full confidence is worse than no memory at all, because the agent then acts carefully on a world that has already moved on.