Updated 23 June 2026

What is agent memory?

"Memory" is a loose word in agent systems, and taxonomies vary by source. The useful split is between memory an agent keeps about its own past, and the one current source of truth a whole team of agents reads. Below are the seven types people usually mean, then where that shared layer fits — because they're often confused.

The 7 types of agent memory

1. Working memory — what the agent holds during the current run: the prompt, retrieved docs, and its own output, all inside the context window. Volatile; it's gone when the run ends.
2. Episodic memory — a log of past events and interactions ("last Tuesday this deploy failed because…"), so the agent can recall specific prior runs rather than re-derive them.
3. Semantic memory — durable facts and concepts the agent treats as known: API shapes, domain rules, project conventions. Knowledge, not events.
4. Procedural memory — how to do things: the steps, tools, and skills the agent reuses, so a learned workflow doesn't have to be rediscovered.
5. Long-term memory — a persistent store (often a vector or key-value DB) that outlives any single session, where episodic and semantic memories are written and later retrieved.
6. Shared memory — knowledge available across multiple agents, so one agent's finding is readable by the next instead of trapped in its private store.
7. Entity memory — structured profiles about specific people or objects (a user's preferences, a service's config), keyed so the agent recalls the right record.

Memory vs a canonical source of truth

Six of those seven are about a single agent recalling its own past. That's recall — useful, and personal to the agent. It is not the same as the project's current truth. Two agents can each have rich memory and still disagree, because each remembers a different version of "how deploys work."

A canonical context layer is the missing piece: one shared store that holds the single current, authoritative doc per topic, with a freshness marker (canonical, stale, or duplicate), that every agent reads from and writes back to. It's what turns scattered per-agent memory into one source of truth for the fleet. The bridge between the two is the record: an agent writes what it learned back once, and the next agent reads it instead of re-deriving it.

trovex is that shared layer, not a per-agent memory store. It indexes your docs, serves the one current section that answers a query, and lets agents write canonical records back — about 60% fewer tokens per lookup than handing over a pile of candidate files. It runs locally; no cloud, no keys.