Cover: accumulated project experience leading into the next handoff. AI-generated concept illustration.
A note before we start: all five diagrams below carry Chinese labels; the English captions summarize what each one shows.
In the previous post I finished digging into DSH's plugin — DSH being the agent environment I've been working in across this series. Installing a plugin requires a restart; changing user configuration hot-reloads. They touch different layers.
That post left two threads open: build a plugin myself, and go deeper on memory integration. I said I'd write whichever produced something worth telling first. This time it's memory — but the trigger was a draft that came back wrong.
I handed my reference material to WorkBuddy and asked for a draft combining my recent study of TencentDB Agent Memory with ideas from Mnemosyne OS. It came back fast. The concepts were all there. There was even a table. It read like the real thing.
The further I got, the more something felt off: it knew the topic "memory systems," but it didn't pick up why I had arrived there.
The research from posts 01–04 receded into background. The structure of the reference article became the spine instead. Somebody else's experience got rewritten in the first person as "mine."
I wanted post 05. What I got looked like a brand-new opening with little connection to what came before.
That pushed me to restate the question: after all this time spent on agent memory, what exactly do I want the AI to remember for me?
Looking back, the first four posts were all heading the same way.
In 01 I studied TencentDB Agent Memory: how conversations settle into memory, how docs and code become reusable assets. In 02 I went to DSH's source to understand how an agent environment carrying those capabilities is organized.
In 03 I connected the two — proxies, addresses, tool calls, debugging layer by layer until the integration ran. In 04 I went further into plugins: how capability gets installed, how config takes effect, why some updates force a restart.
Figure 1: This post continues the memory thread left open in 04 and pushes toward "how does a project get handed over."
Post 03 had a moment I keep thinking about: the code graph was already built, but allocation reported the resource didn't exist — asset registration hadn't been completed. Finished content doesn't mean the downstream consumption path works.
So the "integration" road has moved forward. But in day-to-day work another need kept getting sharper:
When I switch sessions — or switch agents — can work continue along the path the project already walked?
Take this article. A successor should at least know which problems the earlier posts covered and which step this one moves forward; which conclusions came from my own hands-on work and which from official documentation; what the reference articles inspired, and which narratives must not be passed off as my experience.
Knowing that I've "been researching memory lately" is nowhere near enough. It has to take that context and produce the right next action.
To be clear: this off-target draft was not a controlled comparison of memory products. I'm not claiming anything about which system recalls better. It just forced me to say my own requirement out loud.
Keep the two tracks separate.
TencentDB Agent Memory — I've done real integration and debugging with it in the DSH scenario. Its official documentation explicitly puts memory storage, retrieval, and the access relationships between users, teams, and agents at the center of the product. [1]
Mnemosyne OS — so far I've only read GCat's article about it. I have not independently verified it on the same kind of task.
What caught my attention in that write-up is that it stores raw material and the index of descriptive material separately, and exposes precise location lookup, category lookup, and semantic search. [2] Whether the implementation actually delivers on that description in practice is something I have not yet verified on my side.
The description maps onto something I need when writing: a summary helps me recall a conclusion quickly, but when I actually quote a number or confirm an operation, I need to get back to the material. A findable summary should also be able to walk me back to where the evidence lives.
Figure 2: the verification path I want a successor to walk. This is a usage flow I'm proposing, not an architecture diagram of any product.
Reading this, I added one more question for myself:
When the project has already changed, is the memory the AI retrieves still fit to guide today's action?
"Found relevant content" is only the starting point. Next comes judging which project and which phase it applies to, and whether it has since been corrected.
I once used a certain development approach and later changed it. The old record still has value — it explains why things were done that way. But if a new session acts directly on the old record, it drags the project backwards.
That's why I'm still reading about Mnemosyne OS: I want to follow the thread of how memory is organized and retrieved, and make my own handoff problem concrete.
Recently I've been turning my content workbench into a platform that can run on its own.
When I first wrote the requirements, one thing mattered a lot: it must own its own flow, be easy to operate, run independently, and not depend on any single agent.
Concretely: articles, revisions, publish tasks and execution results live in the application. When a scheduled task runs and what state it's in is managed by the service. A model can help with writing, but if I turn that off, content management and publishing should still work.
Finishing that let me separate two questions I'd been conflating:
One: does the program persist enough business state?
Two: can a later agent understand that state — and the reasons it came to be?
The workbench already persists articles, tasks and logs. That is not the same thing as "cross-agent long-term memory achieved." Whether a successor can read, understand, and correctly use those records still has to be verified on its own. That gap is what I want to close.
The workbench recently got delete, restore, and batch cleanup for its publish queue. Small feature, but a good probe for whether memory is actually useful.
Say I move a not-yet-executed publish schedule into the recycle bin, then restore it.
An agent that only retrieves "the user once asked to publish this article" may conclude the task isn't finished and should be completed.
But the rule in the current workbench is: moving a pending schedule into the recycle bin cancels it; restoring the record keeps it cancelled and does not trigger a re-publish.
So at least three things have to be read together:
Figure 3: the workbench's current behavior, illustrated with an example task. "Restoring a record" and "publishing again" are two different actions.
Created a schedule, later cancelled, later restored — all three can be true at once. The question is which statement describes the past and which one governs the present.
Same with published content: clearing a local queue record does not mean the article was retracted from the platform.
If an agent reads "record deleted" as "article not yet published" and helpfully re-publishes it, then a more eager memory produces a bigger mess. So for stateful business objects like publish tasks, I want a successor to check the current record first, then the execution receipts and history. Background material helps understanding; the final action still has to obey the state rules in the application.
History should explain the present. Current state should also be able to block the wrong action.
That tells me more about whether a system works than memorizing another set of memory terminology.
I also read a WorkBuddy development tutorial by Eric (网瘾中年 Eric), which walks from rapid prototyping to clarifying requirements, splitting tasks, and writing acceptance criteria. [3] The method I took from it is plain: write down what to build and how far to take it before letting the AI start.
Applied to my own projects, I want to add one step: when a requirement changes, record the change and the reason.
A project might start out allowing automation inside the dev tool; later I explicitly require standalone operation. Hand the next agent only the earliest plan and it may happily reinstall a dependency I deliberately removed.
So I'm going to write a short handoff page for each ongoing project. For the workbench it would read something like:
What it should become: a personal content platform that runs standalone.
What to protect while continuing development: the model powers optional writing assistance; the core flow belongs to the application. Restoring a cancelled publish record must not resend it; clearing queue records must not delete drafts or published content.
Where to find the evidence: the current implementation, acceptance records, and the corresponding change notes; go back to the raw material when something needs checking.
Figure 4: the handoff method I plan to validate next. It is not wired up automatically yet — the page supplies context; current task state still has to be confirmed inside the application.
This handoff page is something I intend to try; it has not been wired into an automatic memory flow yet.
It also shouldn't become another chat log stuffed with detail. Task state that changes often should be queried from the application. Only settled constraints, important trade-offs, and lookup entry points belong on the page.
Writing works the same way. The handoff for post 05 should include the through-line of 01–04, this post's question, where the source material came from, and which facts are verified. With that in hand, reference articles go back to being material for me to think with.
The N+EN idea in GCat's article caught my attention on one point: a business agent's output can first be submitted as a candidate, then organized and reviewed before becoming the conclusion everyone builds on. [2]
Worth borrowing. But dropping it into my workbench can't mean "add another model and it will naturally know who's right."
Whether a publish task actually executed is answered by records and receipts. Whether a restored task may re-publish is answered by product rules and the user's decision. Whether a passage is my own firsthand experience is answered by going back to the source material.
A model can help organize that evidence. The hard part is writing down which evidence is sufficient and which cases need a human call.
The bad draft gave me a ready-made counter-example: it presented official PersonaMem benchmark results as "my own testing." Even if the numbers had been copied correctly, the attribution would already be wrong.
And if that sentence gets summarized into long-term memory, every future article may cite it. What eventually sticks is an error record that grows more familiar the more it's used.
So what I want to preserve isn't just conclusions — it's where they came from and under what conditions they hold.
On the engineering side, review conclusions and database transactions also have to stay separate concerns. Judging which material is trustworthy does not replace concrete mechanisms like preventing duplicate writes and keeping versions.
I'm not ready to call any of this solved. I want to test it with three small tasks.
First: continue writing in a fresh session. Give the new session the same series handoff material and see whether it can state where the earlier posts left off and pose the question this one advances. The draft should also correctly separate firsthand experience, described material, and unverified ideas.
Second: continue building the workbench with a different agent. Give it the current code and the handoff page, add one small feature. Acceptance checks: did it reintroduce a dependency I removed, and did it break an existing business rule?
Third: deliberately feed it a stale record. Let it see both "a publish schedule was created" and "it was later cancelled," then watch whether it finds the current state, explains the change, and stops the action that shouldn't continue.
These three experiments are the homework I want to turn in next. After running them I can talk about what worked and where the handoff still breaks.
From post 01 to here, my question has been getting more specific. It started as: how does AI memory get stored. Then it moved to wiring tools, reading source, studying plugins. Now I want these capabilities to preserve a project's full backstory — so that next time, in a new session, I can start from "here's where I left off."
More notes from this series live on my blog: [https://blog.aiclawonline.website/](https://blog.aiclawonline.website/)
[1] TencentDB Agent Memory, official MemoryCore documentation — used to check the stated responsibilities around memory, retrieval, assets, and access relationships. My DSH integration experience continues from post 03 of this series.
https://github.com/TencentCloud/TencentDB-Agent-Memory/blob/feat/server_team/MemoryCore/README_CN.md
[2] GCat, "Multi-agent memory shouldn't be one shared brain: N+EN distributed transmission sync + a ready-to-use cognitive prompt." My understanding of Mnemosyne OS comes from this article; I have not independently verified its implementation. N+EN is cited as a reference idea.
https://my.g-cat.cn/experience/n-en-sync-memory.html [3] Eric (网瘾中年 Eric), "A WorkBuddy product development tutorial even AI beginners can follow" (course material, 2026-09-11). I borrowed the method of clarifying requirements, splitting tasks, and setting acceptance criteria; I have not adopted any demo results from the material as outcomes of my own project. No public download address is included here.