I gave Claude a memory of every CVE from the last six months
Six months of CVEs loaded into a Parametric Memory substrate, then queried by an AI agent to answer which vulnerabilities actually affect a given stack — answered from memory, without re-reading advisories.
About this video
A common first reaction to MMPM is that agent memory is a coding-assistant feature. This walkthrough is the counter-example: the substrate is loaded with six months of published CVEs for a real technology stack, and the agent is then asked which of them affect us.
The answer comes out of memory. No advisory feeds are re-read at query time and no vulnerability data is pasted into the prompt. The retrieval step is the whole interaction.
The point is not the lookup — it is that the substrate is a shared asset. Ingest the vulnerability intelligence once and every project queries the same memory. Across an estate of fifty repositories, the fiftieth check costs close to nothing because the knowledge is already resident. That is what makes memory an unusual piece of infrastructure: the per-use cost falls as usage rises, where a context window only gets more expensive.
None of this is specific to CVEs. Any body of knowledge you care about can be ingested the same way.
What you’ll see
- ▸CVEs stored as atoms with typed edges (affects, supersedes, member_of) in a dedicated vulnerability-intelligence domain
- ▸Every atom committed to a SHA-256 Merkle tree, so a read carries a proof that the memory was not altered after the fact
- ▸A Markov chain prefetches likely-next reads, so most recalls are already warm when the agent asks
- ▸Exposed as an MCP server — one configuration block, and it works with Claude, Claude Code, Cursor, Cline and any other MCP client
- ▸Unused paths decay rather than accumulating, so relevance does not rot as the store grows