DEV Community: Kang

From a Personal Hermes Memory Plugin to a Skill, MCP Server, and Official Listings in Just 8 Days

Kang — Wed, 14 Oct 2026 01:54:29 +0000

I originally just wanted to switch to a long-term memory solution for the Hermes Agent to address the issue of running out of free quota on Mem0 SaaS. But the project kept expanding, and in the end, I ended up developing a Hermes plugin, a standalone runtime, an Agent Skill, an MCP server, and publishing it all on PyPI. The plugin was even listed in the official Hermes directory, and the MCP made it into the Official MCP Registry.

It took about 8 days—from creating the repository on October 6 to basically finishing all this work on October 13.

Looking back, it’s actually quite interesting, so I’ll write a chronological account to document how this project snowballed into something much bigger.

Here’s the main project:

https://github.com/cnkang/hermes-plugin-qdrant-memory

Background: I originally just wanted to save on SaaS costs

I usually use Hermes Agent to assist with development. Over time, it has learned a lot about project context, technical decisions, and my personal preferences. This feature is actually quite useful, especially when working across sessions—I don’t have to explain the background all over again every time.

I used to use Mem0 Platform, but after accumulating several thousand entries, I ran out of free storage.

It’s not that Mem0 isn’t useful—it’s just that I feel long-term memory is something best kept under my own control. Models can be replaced, and agents can be switched, but it’s best not to have my accumulated memories locked into a specific SaaS platform.

So I started looking into alternatives.

For the local embedding model, I chose Ollama’s qwen3-embedding:4b, and for storage, I went with Qdrant. Qdrant works on local machines, self-hosted environments, and in the cloud, making it easy to switch deployment methods later on.

Exporting from Mem0 took some effort—I ran into pagination, rate limits, and HTTP 429 errors—but I eventually managed to compile over 2,700 unique records.

My initial plan was simply to migrate these memories to Qdrant and then find a way for Hermes to read and write them.

Later, while researching Hermes’ plugin mechanism, I discovered that it already provides a native MemoryProvider interface, and model calls can reuse Hermes’ own configuration.

So there was no need to go through an extra layer of Mem0.

I decided to just build a native plugin instead.

Day 1 | October 6: First, build the foundation

The goal for the first day was pretty simple: get Hermes to store long-term memory in Qdrant so it could be retrieved even after switching sessions.

I created the repository cnkang/hermes-plugin-qdrant-memory and started working on the first version.

I stuck to a few design principles:

First, I wouldn’t touch Hermes’ core code and would stick to its public plugin interfaces as much as possible. That way, when Hermes is updated in the future, I won’t have to modify the main project every time.

Second, we won’t configure a separate LLM; by default, it will inherit the model currently used by Hermes. Embeddings, however, will be configured independently, with local Ollama as the preferred option.

Furthermore, Qdrant should not be limited to a single deployment method. It must support local embedded deployment, self-hosted servers, and Qdrant Cloud.

The first version quickly established the basic framework: automatic memory extraction, vectorization, storage, search, updates, deletion, and data migration from Mem0.

It seems to be working already.

But upon closer reflection*, being able to store memories and being able to confidently entrust long-term memories to it are two different things.*

Day 2 | October 7: Started fixing those subtle but critical issues

This day was mainly spent tinkering with various edge cases.

For example, an AI Agent’s conversations aren’t necessarily limited to a single human user—they might also involve bots, other agents, or shared sessions.

If a bot’s message is mistakenly saved as a human user’s message—or if it directly inherits the memory permissions of the previous user—that’s a problem.

Long-term memory is different from ordinary chat context—a single mistake could affect every subsequent conversation.

So we began implementing identity verification, memory scope isolation, and permission boundaries between different sessions.

At the same time, we discovered that configuration initialization, write locks, and CLI error messages also needed refinement.

For example, in Qdrant Embedded mode, two processes should not be allowed to simultaneously access the same storage. When lock conflicts occur, we should clearly inform the user which part of the process went wrong, rather than just throwing out a bunch of Python tracebacks.

My takeaway from this day is: once the first version of the features is built, real software engineering has only just begun.

Day 3 | October 8: Writing data to memory isn’t hard—the hard part is not losing it

I began focusing on persistence and exception recovery.

Here’s an example:

An Agent retrieved a memory and was preparing to write it to Qdrant when the network connection was lost. What should happen the next time it starts up?

Another example: Qdrant has successfully written the memory, but the program exits before it has a chance to record the success status. If the operation is executed again after a restart, will it generate duplicate memories?

Here’s an even more interesting scenario:

A user has just deleted a memory, but a previous failed write task is still waiting to be retried. After a restart, that old memory gets written back.

This is a bit unsettling. We clearly made the AI forget, yet it remembered again.

Finally, we introduced and continuously refined the SQLite WAL Ledger to record pending events, write operations, and execution status. Combined with deterministic IDs, idempotent writes, and delete barriers, this allows operations to recover after abnormal interruptions while minimizing the risk of old writes bringing back memories that have already been deleted.

The migration process was also refined.

Importing Mem0 cannot simply involve a loop of write operations; it must also support dry-run mode, progress display, resume-from-breakpoint, failure retries, and final validation.

After completing these tasks, it feels like this project is no longer just a simple Qdrant wrapper; it’s starting to take on the characteristics of a standalone Memory Runtime.

Day 4 | October 9: Since others will be using this, we need to get it right

The first three days were mainly about ensuring “it works properly.”

On the fourth day, I started thinking about whether “others would dare to use it.”

First up was memory management.

Originally, you could search, modify, and delete items by ID, but without a complete list, it’s hard to manage the system effectively—especially if you want to know exactly what it’s keeping track of.

So we added a storage list, portable JSON export, and the ability to perform bulk deletions scoped by user or agent.

I believe that, in the long term, a memory system must at least allow users to see what has been stored, export that data, and delete it explicitly.

Next, I continued to examine the relationship between deletion and restoration to prevent certain unfinished tasks from bypassing the deletion process.

Next came CI, security scans, dependency checks, cross-platform compatibility, and various documentation.

Linux, macOS, Windows, Python 3.11, 3.14, and different versions of Hermes all needed to be taken into account.

I also went through the English documentation to format it in the Simplified Technical English style, striving to make the installation steps and operating instructions as straightforward and unambiguous as possible.

Coding Agent was a huge help during this phase, but I’m increasingly realizing that as AI becomes faster at writing code, we need to devote more effort to reviewing and validating design boundaries.

Don’t just release something the moment the CI runs green.

Especially with something like this that stores user data—it never hurts to be a little more cautious.

Day 5 | October 10: Released the first version and submitted it for official inclusion

I finally felt ready to release v0.1.0 for others to try out.

Of course, I didn’t dare call it a mature, production-grade memory system—I still classified it as a Limited Technical Preview.

I put together Chinese and English README files, installation instructions, and usage examples, and even recorded a terminal GIF demonstrating how to save a preference in Hermes, start a new session, and then retrieve it from Qdrant.

I’d always just been testing it over and over in my own development environment, but this time I gave it some serious thought: Could someone who’s never installed this plugin before get it up and running smoothly by following the documentation?

Then I applied to join the Plugin Catalog on Hermes’ upstream project.

Hermes actually already has other Qdrant-related memory plugins, so I needed to make it clear that mine isn’t just a re-packaging of an existing one.

The main difference is that it uses an LLM to extract facts and preferences rather than simply saving the raw conversation; it supports three storage methods—Embedded, Server, and Cloud; and it also offers capabilities such as persistent ledger, fault recovery, and Mem0 migration.

Of course, there are trade-offs—for example, automatic extraction increases LLM calls, and the overall implementation is more complex.

Different approaches have their own use cases; it’s not a matter of one being inherently better than the other.

Day 6 | October 11: Officially Listed in Hermes, but We Still Need to Verify If the Installation Actually Works Well

One particularly exciting development today was that Qdrant Memory was officially added to the Hermes Plugin Catalog.

Note that it’s a Community Plugin—we’ll continue maintaining the code ourselves; it hasn’t been merged into the Hermes core.

But at least users won’t have to mess around with the plugin directory themselves anymore; they can simply run:

hermes plugins install qdrant-memory

to install it from the official catalog.

However, being included doesn’t mean the job is done.

I specifically used a brand-new Hermes Profile to run through the entire process again—from installation from the official repository, to activation, dependency preparation, initialization, actual data writing, cross-session recall, recovery after a restart, and deletion.

Just because it runs in the development environment doesn’t mean users will have no issues when installing from scratch.

The official repository also has its own version review and commit locking mechanisms; future upgrades must follow its rules—you can’t simply assume that a new version on PyPI means the official repository has been updated.

After going through this entire process, I actually came to realize that it’s quite necessary.

Releasing open-source software isn’t just about creating a tag; you also need to be able to clearly explain exactly which version users are actually installing.

At this point, I thought the matter was pretty much settled.

But then a new idea popped into my head.

Day 7 | October 12: Why is it limited to Hermes?

Taking a closer look at what I’ve built so far—Qdrant storage, embedding, deduplication, Ledger, fault recovery, and migration—most of these features are already in place.

These capabilities don’t necessarily have to rely on Hermes.

I also use development tools like Codex and OpenCode on a regular basis. Wouldn’t it be more interesting if different agents could share this memory infrastructure?

So I started expanding it again.

First, I created a generic Agent Skill:

https://github.com/cnkang/skills/tree/main/qdrant-memory

The Skill doesn’t directly implement memory storage; instead, it tells the Agent how to search for, save, maintain, and migrate memories; which operations require confirmation; how to prevent unauthorized access; and how to select available tool interfaces.

Subsequently, we separated the runtime and added a CLI and a standard stdio MCP interface that do not depend on Hermes.

This allows other MCP-compatible agents to manipulate memories using four tools: Search, Add, Update, and Delete.

Multiple interfaces share the same Runtime, eliminating the need to duplicate storage and recovery logic.

Of course, there are limitations: Hermes’ native plugins can automatically extract memories using their own lifecycle, whereas standard MCPs only provide explicit operations and do not automatically remember every round of conversation.

Different Agents can reuse the memory provided that authorization and scope are consistent, but the current version still requires coordinated writes; it should not be treated as a distributed service where any number of Agents can write simultaneously.

This day effectively expanded the original Hermes-specific plugin into a memory foundation that can be used by different agents.

Day 8 | October 13: Going All Out—Skill, MCP, and PyPI Are All Set

At this stage, since the Runtime can already run independently of Hermes, the distribution method should keep pace.

First, we officially released the Runtime to PyPI:

hermes-plugin-qdrant-memory

Then, I set up a separate MCP distribution repository:

https://github.com/cnkang/qdrant-memory-mcp

Instead of duplicating the Python business logic code here, we made the MCP distribution package depend on the original Runtime. This way, when fixing storage or memory handling issues in the future, we won’t need to constantly synchronize changes between two separate implementations.

As it turned out, an issue was actually detected during release preparations.

If the similarity calculated by the embedding for two different text segments is very high—even 1.0—the original deduplication mechanism might mistakenly treat them as the same memory.

When automatically extracting memories from a conversation, the LLM can determine whether facts are duplicated or conflicting. However, when a user explicitly calls Add to save a piece of content, different text segments should not be merged without authorization.

So we made another round of changes, separating the deduplication rules for automatically extracted and explicitly written content.

Finally, we released Runtime 0.2.1 and MCP 0.1.1.

The General-Purpose Skill was also updated to version 0.2.4, adding operational guidelines for standalone installation, MCP usage, migration, and cross-agent memory sharing.

The MCP Server was subsequently added to the Official MCP Registry.

All in all, from the Hermes Plugin, Runtime, CLI, and Skills to MCP, PyPI, and the official catalog, we’ve essentially covered all available distribution channels.

The only remaining task is to finalize the version lock for the official Hermes Catalog. The 0.2.1 update has been submitted to the upstream repository and is still undergoing the review process.

A Few Final Thoughts

Looking back, these eight days of development didn’t strictly follow the initial plan.

On the first day, I just wanted to replace Mem0.

On the second day, I realized that memory permissions and identity isolation couldn’t be handled carelessly.

On the third day, I started worrying about crashes, duplicate writes, and data recovery after deletion.

On the fourth day, I realized that since we were going open source, we needed to address data management, security, and testing.

On the fifth day, we were finally ready to release it.

On the sixth day, it was added to the official Hermes repository.

On the seventh day, I realized that since I had a standalone foundation, it would be a waste not to let other agents use it.

On the eighth day, I went ahead and set up Skill, MCP, PyPI, and the Registry all at once.

Throughout the process, it was basically a case of solving one problem only to discover the next one worth tackling.

I also had one pretty obvious realization: when developing with Coding Agent these days, the code itself is often no longer the most time-consuming part.

What really takes mental effort is clarifying requirements, identifying edge cases, defining behavioral boundaries, and determining whether the implementation generated by the AI is actually reliable.

Sometimes a feature can be written in just a few tens of minutes, but to ensure it works without issues after a restart, timeout, repeated operations, version upgrades, or cross-platform installation, it may require many rounds of review.

This week, I’ve gone through the cycle of writing code, reviewing it, adding tests, updating documentation, and reviewing it again—I’ve lost count of how many times.

Of course, it’s still too early to say the system is fully mature.

The single-writer restriction is still in place; Hybrid Search, Rerank, and the Web UI haven’t been implemented yet, and there’s still plenty of room for improvement in the recall quality of long-term memory.

However, at least for me personally, that initial problem has been solved: there’s no longer a need to completely tie the agent’s long-term memory to a single SaaS service.

What’s even more interesting is that what started as a small “reinventing the wheel” project for Hermes has ultimately turned into a universal foundation that other agents can also integrate with.

Building your own wheels—it’s definitely easy to get carried away.

The project link is at the end. If you’re interested, feel free to give it a try, share your suggestions, or drop a star.

All open source, MIT License.

Next, I’ll continue to refine it bit by bit. After all, when it comes to long-term memory, simply remembering something is just the first step—remembering it correctly, being able to forget it when necessary, and being able to transfer that knowledge are the parts truly worth the effort.

Early prototype: serve a Markdown variant for bots/agents without touching your app. NGINX converts HTML Markdown only for explicit clients; not intended for APIs/streaming/auth pages. Looking for feedback.

Kang — Mon, 02 Mar 2026 07:59:52 +0000

Kang

Mar 2

I tried Cloudflare’s “Markdown for Agents” idea in NGINX (Rust module) — early prototype

#showdev #nginx #rust #markdown

2 min read

I tried Cloudflare’s “Markdown for Agents” idea in NGINX (Rust module) — early prototype

Kang — Mon, 02 Mar 2026 07:21:00 +0000

Cloudflare recently shipped Markdown for Agents: if a client sends Accept: text/markdown, Cloudflare can fetch your HTML and return a Markdown variant.

That idea stuck with me, so I did some vibe coding over a few evenings and built a self-hostable NGINX dynamic module that does something similar on your own infra.

This is a very early / starter prototype — mainly meant to help people try the workflow and share feedback.

Repo: https://github.com/cnkang/nginx-markdown-for-agents

What it does

Only when the client explicitly asks for Markdown:

Browser (Accept: text/html) → original HTML
Agent (Accept: text/markdown) → NGINX converts upstream HTML to Markdown and returns text/markdown

No application changes. This sits entirely at the reverse-proxy layer.

Best for: docs / blogs / news / KB pages

Not for: APIs, streaming responses, or authenticated pages (unless you really know what you’re doing with caching).

Why you might care

Agents and LLM tools often fetch full HTML and end up spending tokens on:

navigation / footer / cookie banners
layout markup
scripts and noisy attributes

A Markdown variant can make downstream parsing cheaper and more predictable.

Quick try (2 minutes)

1) Install (prebuilt module)

curl -sSL https://raw.githubusercontent.com/cnkang/nginx-markdown-for-agents/main/tools/install.sh | sudo bash
sudo nginx -t && sudo nginx -s reload

Note: dynamic modules must match your exact NGINX patch version (nginx -v). If there isn’t a matching build, you may need to compile.

2) Verify content negotiation

# Markdown variant
curl -sD - -o /dev/null -H "Accept: text/markdown" http://localhost:8080/ | grep -iE 'content-type|vary'
# expect:
# content-type: text/markdown; charset=utf-8
# vary: Accept

# HTML variant
curl -sD - -o /dev/null -H "Accept: text/html" http://localhost:8080/ | grep -i 'content-type'

3) See the body

curl -s -H "Accept: text/markdown" http://localhost:8080/ | head -40

Minimal NGINX config

Start small — enable it on one route first.

load_module modules/ngx_http_markdown_filter_module.so;

http {
  markdown_filter off;

  server {
    listen 8080;

    location /docs/ {
      markdown_filter on;

      # Recommended: avoid upstream compression for clean conversion
      proxy_set_header Accept-Encoding "";

      proxy_pass http://backend;
    }
  }
}

A few knobs (optional)

Fail open (recommended for trials): if conversion fails, return original HTML

  markdown_on_error pass;

Limit work (avoid huge pages)

  markdown_max_size 10m;
  markdown_timeout 5s;

Metrics endpoint (localhost only)

  location /markdown-metrics {
    markdown_metrics;
  }

If you cache at NGINX/CDN: make sure variants split by Accept

  proxy_cache_key "$scheme$request_method$host$request_uri$http_accept";

Things that are rough / WIP

It’s early: edge cases will exist (weird HTML, giant pages, odd encodings).
It’s focused on HTML → Markdown only (not PDFs, not arbitrary binaries).
Caching needs care (variant keys + auth-aware behavior).

If you try it… feedback welcome 🙏

If you run into a broken page, a really slow page, or a caching gotcha, I’d appreciate an issue/report with:

a sample URL (or anonymized HTML)
your nginx -v
whether upstream is compressed
any cache/CDN in front

Repo: https://github.com/cnkang/nginx-markdown-for-agents

Cloudflare inspiration:

Showdev: An AI-assisted skill to batch messy changes into Conventional Commits

Kang — Thu, 19 Feb 2026 10:12:51 +0000

Hi DEV community 👋

I’d like to share a small project I’ve been tinkering with: conventional-commit-batcher.

This is my first “skill” I built with the help of AI tools. I originally made it for myself, then a few programmer friends tried it on real work‑in‑progress branches and told me it helped them turn messy, mixed changes into a cleaner commit history—so I decided to open‑source it and invite more people to try it.

TL;DR: It helps you turn a messy, mixed working tree into a clean, reviewable commit history.

Plan first (generate a Commit Plan by intent)
Commit in batches (often with git add -p)
Validate commit messages (Conventional Commits)

What problem does it try to solve?

When a working tree mixes refactors + fixes + docs + chores, it’s easy (especially for junior devs) to end up with:

one giant “misc” commit
vague commit messages
a history that’s hard to review, revert, or git bisect

I wanted something that nudges me toward a more reviewable, traceable history—without turning it into a big ceremony.

What it does (in one line)

Plan-first commit batching + commit message validation — it helps you organize mixed diffs into logical, reviewable Conventional Commits, and validates messages before they land.

How it works (high level)

Plan first: produce a Commit Plan that groups changes by intent (e.g., refactor vs fix vs docs).
Batch staging: stage changes batch‑by‑batch (often with git add -p) instead of “add everything”.
Message validation: enforce Conventional Commits formatting with an executable validator.
Safety gates: stop early if something looks risky (conflict markers, sensitive strings, etc.).

Example: a Commit Plan (by intent)

Here’s a tiny example of what “plan first” looks like:

1) refactor(auth): simplify token parsing

changes: src/auth/*

2) fix(api): handle empty response safely

changes: src/api/*

3) docs: update setup notes

changes: docs/*

Repo / quick try

Repo: https://github.com/cnkang/conventional-commit-batcher

If you use the Vercel skills ecosystem, you can try:

npx skills add cnkang/conventional-commit-batcher

Prefer no agent tooling? You can still use the validator and commit‑msg hook examples in the repo.

A tiny before/after example

Before (typical messy branch)

update stuff
fixes
wip

After (same work, clearer history)

refactor(auth): simplify token parsing
fix(api): handle empty response safely
docs: update setup notes

(You can imagine how much easier it becomes to review, revert, or bisect.)

A small favor: if you have a minute to try it…

I’d really appreciate any thoughts (especially if you can try it on a “messy branch”):

Batching by intent: does it actually help split mixed changes into logical commits?

If not, what kinds of changes are hardest to separate (tests + refactor, formatting + logic, lockfiles…)?
Team conventions: what rules do you follow (types/scopes, subject length, issue references, breaking changes)?
Junior-friendly guardrails: which checks feel helpful, and which feel too strict?
Multi-language commit messages: do you write commits in languages other than English?

If yes, would you prefer type(scope) in English + localized subject/body, or fully localized messages (and how should validation adapt)?

Thank you for taking a look 🙇

If you try it and it helps (or fails), I’d love to hear what happened—either way.