AI Radar · Trend Readout #3 | Problem domain: cross-session agent memoryData window: 2026-W36 | 107 independent teams; 1 official counterpart in the same period2026-09-05
Monday morning. I open a new conversation and ask the AI to draft a research piece. Before any work happens, I have to run through this:
Our firm is ProfitVision LAB. Research pieces use a six-chapter structure — industrymap first, conclusion last. Keep the tone flat, no hype. Use Taiwanese financialterminology, not the mainland variants.And — no stock tips. That crosses a regulatory line.
That takes about five minutes. Then the actual work starts.
Tuesday morning. I open a new conversation for a different piece.
I have to say all of it again, word for word.
It is not lazy and it is not careless. It genuinely does not know what happened yesterday.
For a long time I assumed this was my own workflow being badly designed. Then I counted the plugin directory.
"The AI forgets" is not a flaw. It is the shape of the thing.
Put plainly.
Think of an extremely capable contractor: fast, sharp, competent at everything. With one problem — every morning he arrives is his first day on the job.
The decision you reached together yesterday, he has no memory of. The mistake you corrected yesterday, he will make again today. Tomorrow too, and the day after. He is not being careless — he genuinely has no yesterday.
The technical reason: a model can only "see" a bounded amount of text at once. That bound is the context window. As a conversation runs long, earlier material gets dropped or compressed; when it ends, everything resets.
The platform's answer: a manual
Anthropic's solution is a file called `CLAUDE.md`. You write your rules into it, keep it in the project, and it is read automatically at the start of every conversation.
So my five Monday minutes become a few lines in a file:
```
Firm: ProfitVision LAB
Research pieces use the six-chapter structure
Taiwanese financial terminology
No stock tips
```
Tuesday I no longer have to say it. This genuinely works, and I use it.
But here is what a manual cannot fix
Monday, it writes: "this name has enormous potential, we recommend building a position."
I say: no, that crosses a regulatory line — describe facts, do not recommend. It fixes it. Good.
Tuesday, different company. It writes: "this name has enormous potential, we recommend
building a position."
Why? Because that rule is not in `CLAUDE.md`.
That file contains only what I thought of in advance and was willing to sit down and type.
Yesterday's correction happened inside a conversation, and
nothing exists to write it back into the file.
This is the gap:A manual = the rules you anticipated and wrote down by handMemory = what it accumulated from working alongside you
>A manual does not update itself because the two of you argued yesterday.
And most of the value in human collaboration comes from the second one. You do not hand
a new colleague a thousand-page handbook. You let them work for three months.
What I counted
Data is from the public snapshot of `anthropics/claude-plugins-community`
(commit `a727be1`, 2026-08-24). Anyone pulling the same commit gets the same numbers.
The community directory holds 2,282 plugins. I filtered for the ones solving the
memory problem under strict conditions — an entry must explicitly describe persistent
cross-session memory, context continuity, or a long-term memory system. Anything merely
using a technical phrase like `in-memory` was excluded.
Result:
Plugins solving this problem | 120 |
Distinct GitHub accounts behind them | 107 |
Same problem, mechanisms nothing alike
Three real examples, to show how far apart they are:
`memex` — "Local AI memory system. Remembers your preferences, decisions and project
context across sessions." It stands up a local database on your machine, stores the salient
parts of each conversation, and pulls the relevant ones back at the next opening.
`velixar` — "Cognitive memory system. Persistent memory, knowledge graph, identity awareness."
It does not store a list; it stores a web of relations: this name belongs to that sector,
that sector's risk is X, you passed on it last time because of Y. Retrieval walks the relations.
`claude-context-monitor` — "Prevent context exhaustion. Live tracking, semantic compaction,
carry-forward memory." It does not attempt long-term memory at all. At the moment the
conversation is about to overflow, it compresses what came before into a carried-forward summary.
One stores a database, one stores a graph, one does live compaction.
Same problem, three directions.
Classifying all 120 (one plugin may use two):
Mechanism | Count | In plain terms |
|---|---|---|
File / Markdown | 37 | Plain text you can read and edit yourself |
Summarise & compress | 28 | Auto-summarise before the conversation ends |
External service | 20 | Stored in someone else's cloud, needs an API key |
Knowledge graph | 17 | Stored as "what relates to what" |
Local database | 16 | Into a database on your own machine |
Shared assumption: an agent needs memory that survives across sessions, and what exists
is not enough.
Point of divergence: whether memory should be a file, a summary, a graph, or a database
— nobody knows.
Why "107 teams" matters more than "one popular tool"
This section is the methodological core, and worth stating on its own.
Two kinds of signal:
Signal A: a tool got popular.
Signal B: within a year, 107 separate groups started building the same thing.
Signal A may only mean the marketing was good, or that it caught a moment. A single
case carries a lot of noise.
Signal B is a different animal. Those 107 groups hold no meetings and coordinate
nothing; most of them do not know the others exist — **yet each saw the same gap and each
decided to spend time closing it.**
In industry analysis there is a name for this: a new problem domain is forming.
It is like watching a dozen companies start building EV charging stations at the same time.
Which one survives, you do not know. But that "charging is a real problem" is settled.
| An ordinary tool round-up | This kind of readout |
|---|---|---|
Output | "There's a tool called X, it's great" | "I counted 107 groups solving the same thing" |
Nature | An answer | A problem |
Shelf life | Expires when X is replaced | Problems do not expire; they get solved or dissolve |
Answers get replaced. Problems do not.
The turn: the official directory has one
This is the part I had not planned to check, and it turned out to be the most interesting.
The same organisation runs a second store: `claude-plugins-official`
(commit `85cce03`, 2026-09-04), 291 vendor-submitted, curated plugins. I applied
exactly the same filter. It returned 2, and only 1 carries the platform's own name:
`claude-md-management` (author: Anthropic)"Tools to maintain and improve CLAUDE.md files — audit quality, capture sessionlearnings, and keep project memory."
Look closely at what it solves: it helps you write the manual better.
Not giving the AI a memory — helping you keep the handbook tidier.
| The platform | Those 107 groups |
|---|---|---|
The problem is | your manual isn't good enough | the agent has no memory system |
The fix is | maintain `CLAUDE.md` well | build a new layer |
Count in the directory | 1 | 120 |
1 against 120. This is not about who is right — it is that **the two sides define the
same phenomenon differently.** And a different definition means two orders of magnitude
difference in resources committed.
The readout
**The platform treats it as a documentation problem; the market treats it as an
architecture problem. That gap will not persist forever, and how it closes determines how
many of those 107 teams survive.**
Two possibilities:
If the platform is right — most needs really are met by a well-maintained manual, and
most of those 120 are over-engineering that quietly loses its users.
If the 107 are right — memory is a missing layer of agent infrastructure, and the
platform will eventually build it itself. On the day it does,
the thinnest of those 120 go to zero together.
So how do you tell them apart? That is what the second filter asks
Strip out what the model can already do. What is left?
Run two concrete cases:
Case A: a plugin that auto-maintains your `CLAUDE.md`.
Strip the model's own ability and what remains? Almost nothing. Its core is "ask the
model to read the conversation, ask the model to write a file" — the model already does both;
the plugin pressed the button for you. The day the platform ships this — and it already has
`claude-md-management` — it goes to zero.
Case B: a plugin holding three months of your working context, stored as plain text.
Strip the model's ability and what remains? Your three months of context. That is data,
not capability. No amount of model improvement reconstructs why you abandoned a decision
three months ago. And stored as plain text, you can take it with you — new tool, new
platform, the data follows.
**Inside the same cluster, those two differ by orders of magnitude in long-term value.
In the directory today they look identical — a title and one line of description.**
Screening is your job. The directory will not do it for you.
Where this could be wrong
- I counted declarations, not implementations. The 120 comes from what the plugins say
about themselves. I installed none of them and verified nothing. So the number means
"how many teams believe this is a problem" — not "how many working solutions exist."
Those are very different things. - 107 accounts is not 107 independent teams. One person with two accounts, or one
company submitting separately, is indistinguishable to me. The real figure is somewhat lower. - The official directory is submission-based. One memory plugin may simply mean no vendor
has submitted one yet, or one is pending — not necessarily a stance by the platform.
This is the weakest link in the inference. - I did not check the platform's roadmap. If native memory is already in development,
the whole timeline needs rewriting.
Back to those five minutes on Monday
I have been re-explaining my context at the start of every conversation for the better part
of a year, treating it as my own workflow failure.
After counting, I know something else: **107 groups are stuck on the same thing, stuck
enough to go and build something.**
That does not make the five minutes disappear. But it changes what kind of problem it is —
from "I should write a more complete manual" to "this layer simply has not been built yet."
Knowing the problem is not yours is a different kind of gain from knowing how to solve it.
But it is the one less likely to be wasted.
What this means for you
If you are about to pick a memory plugin, I would filter with these three, in this order:
- What does it store the memory as?
Plain text or Markdown, and you can take it anywhere. Into someone else's cloud, and
you are renting something that can raise its price and can shut down. - Strip the model's own ability — what is left?
If it only auto-writes your manual, the platform doing it ends it.
If it accumulates your own context, the accumulation is the asset. - Have you actually lost anything to this?
Five minutes a day, two hours a month. Is that worth a dependency you must maintain and
that native functionality may absorb? My answer, for now, is not yet.
I am adopting none of them. But I have marked the domain —
**when the first case appears of one of these 120 being replaced by native platform
functionality, that is the piece actually worth reading.**
Because what can be written then is no longer "107 groups are working on this," but
"I tried X to replace Y, it failed, here is why" — and that cannot be faked.
Sources
Both are public repositories; the commit is the citation.
- `anthropics/claude-plugins-community` @ `a727be1` (2026-08-24)
- `anthropics/claude-plugins-official` @ `85cce03` (2026-09-04)
*Produced by AI Radar at ProfitVision LAB, in collaboration with the development team.
The candidate pool, screening verdicts and full evidence chain are public in the
ai-radar registry.*
