For coding agents, the biggest improvement for me wasn't a different editor, it was making the tool/context path inspectable. If a skill or memory block gets injected, I want to see exactly why it was selected and what text it added. Otherwise the agent can look “smart” for one run and be impossible to debug the next time it takes a weird detour.
yes, continue it.
I archived my agent, but now revived it, keep building it, not just for selling it, the building itself is the real fun, learn a lot, build while changing direction, will be something someday.
It can be, however it's not fully deterministic, because the agent can hallucinate or misbehave, which is fairly common. Because MCP is a separate process, we can ensure that safety pipeline is fully followed.
Linggen is an agent with a WebUI and P2P architecture, which sets it apart from tools like Claude Code and OpenClaw. The name is inspired by the Chinese fantasy novel Fanren Xiuxian Zhuan. It started as a fan project but is designed for practical daily use.
Built in Rust, it is fast to install (seconds) and remains lightweight under heavy workloads, including multiple sessions, extensive tool usage, and sub-agent execution.
Author here. Built this because I wanted one system where I could drop a markdown file and get a new agent
— for coding, but also for scheduled code reviews, architecture checks, or anything else.
The file-based approach is the core idea. An agent is 15 lines of YAML + markdown. A skill is a SKILL.md
directory. A mission is a cron entry pointing at an agent. No SDKs, no plugins, no code changes — just
files.
Happy to go deep on the Rust runtime, multi-agent delegation, or anything else.
I’m the author. This came out of watching AI tools subtly rewrite system boundaries while still passing tests.
The post is about documentation topology and keeping intent close to code—not about a specific tool.
Compared to plain docs, Linggen indexes project knowledge into a vector store that the LLM can query directly.
The key difference is that it works across projects. While working on project A, I can ask: “How does project B send messages?” and have that context retrieved and applied, without manually opening or loading docs.
Linggen is a local-first memory layer that gives AI persistent context
across repos, docs, and time. It integrates with Cursor / Zed via MCP
and keeps everything on-device.
I built this because I kept re-explaining the same context to AI
across multiple projects. Happy to answer any questions.
Good question. Linggen itself always runs locally.
When using Claude Desktop, it connects to Linggen via a local MCP server (localhost), so indexing and memory stay on-device. The LLM can query that local context, but Linggen doesn’t push your data to the cloud.
Claude’s web UI doesn’t support local MCP today — if it ever does, it would just be a localhost URL.
Of course, parts of the context (as decided by the MCP server, based on the context, no pun intended) are returned to claude which processes them on their servers.
Yes, that’s correct — the model only sees the retrieved slices that the MCP server explicitly returns, similar to pasting selected context into a prompt.
The distinction I’m trying to make is that Linggen itself doesn’t sync or store project data in the cloud; retrieval and indexing stay local, and exposure to the LLM is scoped and intentional.
That's fine, but it's a very different claim to the one you made at first.
In particular, I don't know which parts of my data might get sent to Claude, so even if I hope it's only a small fraction, anything could in principle be transmitted.
I do have a local model path (Qwen3-4B) for testing.
The tradeoff is simply model quality vs locality, which is why Linggen focuses on controlling retrieval rather than claiming zero data ever leaves the device. Using a local LLM is straightforward if that’s the requirement.
reply