Semantic Memory

Think about how you know your team uses pnpm. You don't replay the pull request where that got decided — you just know it. That's semantic memory: standing knowledge that floats free of when it was learned.

What the agent just knows

Episodic memory is always pinned to a moment. Semantic memory is where the durable facts live — for our league-app example:

fact store
──────────────────────────────────────────────
project.root        = ~/projects/cricket
app.meteor_root     = meteor/league/
work.allowed_paths  = [imports/api/, imports/ui/]
user "Buddy"        → github: buddy-b
policy.implement    = requires approval comment on the issue

These are the facts the agent should not have to rediscover: repo layout, project rules, the mapping from a human-friendly name to a GitHub assignee, the approval policy itself. This is exactly what your CLAUDE.md / AGENTS.md / memory files hold — standing facts and rules, true across many sessions rather than a record of one event.

In the wild

Semantic memory can be a key-value store, a set of markdown notes, a profile database, a knowledge graph. As with episodic memory, the mechanism matters less than the job: user facts, project conventions, and current state — stored where the harness can inject them at the right moment.

The maintenance problem

Semantic memory creates the most insidious failure mode in the stack, because facts look timeless and aren't.

Files move. Policies change. A stale fact isn't neutral — it's a plausible wrong answer sitting exactly where the right answer should be. So semantic memory comes with standing maintenance questions: what should be saved? updated? retired?

Even with the facts right, though, something is still missing. The agent knows the approval rule exists. Knowing a rule is not the same as knowing how to run the workflow that honors it.