Before you build such a complex monster try an LLM Wiki! This approach is currently way faster, agents can auto discover and the context is rich while not growing to crazy. Here is an implementation in a handful of skills and agents that run in Claude Code, Codex etc: https://github.com/theafh/ai-modules/tree/main/plugins/knowledge_management
100% - I love wikis. They are super powerful. I have been using them for the past 6 months or so (before Karpathy made them popular), but they are mostly limited to personal use cases or small-scale applications.
What I presented in this article is for medium-to-large data that works for products shipped worldwide.
You asked where the line sits between what the agent keeps forever and what it's allowed to forget. From where I sit, financial services, LATAM, nobody at the company draws that line. Two obligations draw it, and they point in opposite directions.
Retention says the record survives for years. And the reasoning layer is a record: tool_call and agent nodes are the trace of how a decision got made, which is precisely what gets pulled when someone contests the decision. Erasure rights say the same subject's data leaves on request. Both are law, both land on the same graph.
Which makes forgetting a write-time classification, not a TTL. Every node has to know whether it's derived data I may drop or evidence I'm obliged to keep. You get lineage for free because nodes reference their source documents, but lineage tells you where a node came from, not which regime it falls under. Different edge.
Worth saying: the ontology is the right place for it. It's just one more thing the contract has to carry.
A flag, yes. A learned one, I'd resist — at least from where I sit.
The issue isn't accuracy. Keep/drop in a regulated context isn't a property of the content, it's a property of the regime the source falls under, and someone signed for that regime on a date. A classifier at 97% is wrong on the 3% you only discover when the decision is contested, and "the model inferred it was droppable" isn't an answer anyone accepts in that room.
Two things also break the binary. A node can be both, evidence I'm obliged to keep and subject data someone has the right to erase. That conflict resolves in legal, not in the graph. And regime isn't stable at write time: a reasoning node becomes evidence the moment the decision it produced gets contested, which can be years out.
Where a classifier earns its seat is as a second opinion. The ontology declares, the model proposes, and disagreement between the two is the alert worth having, it catches the pipeline that inherited the wrong regime from the wrong source. Cheap, and it fails in the right direction.
Because MCP makes memory a discretionary tool call instead of ambient context. That means retrieval happens mid-turn (after the model's already framed its response), depends on the model generating the right query, and can simply be skipped, so the "memory" is only as reliable as the model's decision to go fetch it.
Retrieval occurs between the initial query and the final answer, meaning the model hasn't framed the final answer yet. It's still reasoning.
Plus, every memory system bigger than the context window works like that. That's called agentic RAG, which in one way or another sits at the core of every memory layer.
The only exception is the AGENTS.md/MEMORY.md files, which are compact and always loaded into the context window. But you can load a limited number of key details there.
I agree that what you stated are potential issues, but they are not related to MCP; they are related to how you design your system. But nowadays, LLMs are really good at tool calling or following references via progressive disclosure, making this problem less and less problematic.
Yeah, it looks like they have a way to prefetch some context at start-up, which you can always add on top of an MCP server or whatever serving method you use.
Before you build such a complex monster try an LLM Wiki! This approach is currently way faster, agents can auto discover and the context is rich while not growing to crazy. Here is an implementation in a handful of skills and agents that run in Claude Code, Codex etc: https://github.com/theafh/ai-modules/tree/main/plugins/knowledge_management
100% - I love wikis. They are super powerful. I have been using them for the past 6 months or so (before Karpathy made them popular), but they are mostly limited to personal use cases or small-scale applications.
What I presented in this article is for medium-to-large data that works for products shipped worldwide.
On wikis, I wrote last week another piece: https://decodingaimagazine.substack.com/p/llm-wiki-agent-memory?r=1ttoeh&utm_medium=ios
You asked where the line sits between what the agent keeps forever and what it's allowed to forget. From where I sit, financial services, LATAM, nobody at the company draws that line. Two obligations draw it, and they point in opposite directions.
Retention says the record survives for years. And the reasoning layer is a record: tool_call and agent nodes are the trace of how a decision got made, which is precisely what gets pulled when someone contests the decision. Erasure rights say the same subject's data leaves on request. Both are law, both land on the same graph.
Which makes forgetting a write-time classification, not a TTL. Every node has to know whether it's derived data I may drop or evidence I'm obliged to keep. You get lineage for free because nodes reference their source documents, but lineage tells you where a node came from, not which regime it falls under. Different edge.
Worth saying: the ontology is the right place for it. It's just one more thing the contract has to carry.
Great addition, Carlos!
I guess we could generalize this to a keep/drop flag? where, depending on the use case, you can train a high-quality classifier.
What do you think?
A flag, yes. A learned one, I'd resist — at least from where I sit.
The issue isn't accuracy. Keep/drop in a regulated context isn't a property of the content, it's a property of the regime the source falls under, and someone signed for that regime on a date. A classifier at 97% is wrong on the 3% you only discover when the decision is contested, and "the model inferred it was droppable" isn't an answer anyone accepts in that room.
Two things also break the binary. A node can be both, evidence I'm obliged to keep and subject data someone has the right to erase. That conflict resolves in legal, not in the graph. And regime isn't stable at write time: a reasoning node becomes evidence the moment the decision it produced gets contested, which can be years out.
Where a classifier earns its seat is as a second opinion. The ontology declares, the model proposes, and disagreement between the two is the alert worth having, it catches the pipeline that inherited the wrong regime from the wrong source. Cheap, and it fails in the right direction.
Any solution that uses MCP is already handicapped out the gate
Hmm... why do you think that?
Because MCP makes memory a discretionary tool call instead of ambient context. That means retrieval happens mid-turn (after the model's already framed its response), depends on the model generating the right query, and can simply be skipped, so the "memory" is only as reliable as the model's decision to go fetch it.
Retrieval occurs between the initial query and the final answer, meaning the model hasn't framed the final answer yet. It's still reasoning.
Plus, every memory system bigger than the context window works like that. That's called agentic RAG, which in one way or another sits at the core of every memory layer.
The only exception is the AGENTS.md/MEMORY.md files, which are compact and always loaded into the context window. But you can load a limited number of key details there.
I agree that what you stated are potential issues, but they are not related to MCP; they are related to how you design your system. But nowadays, LLMs are really good at tool calling or following references via progressive disclosure, making this problem less and less problematic.
Actually there is one that actually does what you describe: https://tenureai.dev memory is retrieved before the model ever sees the query.
Here is how they stack up when measured: https://github.com/tenurehq/precisionMemBench
Yeah, it looks like they have a way to prefetch some context at start-up, which you can always add on top of an MCP server or whatever serving method you use.
But that's a nice trick, indeed.
It's actually per-turn rather than just at startup. As far as I've seen, Tenure is the only memory system currently doing it this way.