I find Logseq to be a perfect companion to managing and directing agents. I made nt, a tool that exposes your second brain content to agents. More importantly, it makes retrieval easy.
Hey mlanza,
It’s crazy to see we are tackling the exact same problem at the exact same time! Local-first AI with Logseq OG is incredibly powerful.
I love your approach with nt for context extraction. I’ve just released a complementary approach on PyPI called Matryca (matryca-logseq), which also turns Logseq into a local database for AI agents, but it focuses on the Model Context Protocol (MCP) and headless mutations.
While nt is great for reading and passing context, Matryca allows agents (like Claude Desktop or Cursor) to read, write, refactor, and update Logseq files automatically in the background.
Since it operates completely headless (via an AST parser on the .md files), I built in:
-
OS-level file locking (
fcntl.flock): so agents can safely write to files even while the Logseq desktop app is open, without corrupting data or causing “lost updates”. -
X-Ray Mode: it compresses long Logseq UUIDs (
id:: ...) into tiny aliases (like[0],[1]), saving massive amounts of tokens when sending context to the LLM.
Since it is distributed globally via uvx, it requires zero installation and can be plugged directly into Claude Desktop or Cursor using a simple JSON config.
I’d love to get your feedback on it or see if there is any overlap in our AST parsing logic! You can check it out here: https://github.com/MarcoPorcellato/matryca-logseq-llm-wiki
Keep up the great work! 
1 Like
Howdy, Marco. I think I started here:
And that tool worked with raw files, but I wanted Advanced Queries. And I didn’t want to build facilities that Logseq already provided in DataScript. So my code is a hybrid. Some commands interact with the raw files, some interact with the HTTP API and thus gain access to native Logseq commands like query.
Yes! I am certain all devs are having the same idea about getting their second brain context into agent conversations. It’s just that when I looked I didn’t find everything I was looking for and now I mostly have it. My next layer of work was putting my agent into a Docker container because security is by far my biggest concern, which I’ve done. I run my Logseq instance outside the container and pass in the files and the HTTP endpoint. So via a separate, private project I now have a fully-contained, isolated environment.
I started out on OpenCode but the pi philosophy resonated with me, so I’ve since been retooling using pi. All agents are converging on features. I prefer open harnesses.
I briefly looked over your project and I’m not sure I follow the presentation for what use cases it supports to even compare it to mine. Seems likes its job is maintaining memory, maybe. That is not my focus. I don’t want the AI keeping my second brain for me, except under my direct supervision.
My focus is controlled retrieval. You type prompts with wikilinks to instruct the agent and those links get automatically expanded with all the context the agent needs to fully understand your intention. That expansion is not accidental. It is designed by you. You decide exactly what modular chunks of information the agent needs to do a job.
Although the commands I provide in a simple CLI are useful for the agent to do just about anything, including updates, the focus is predominantly reading and retrieval. Giving the agent sufficient context to interpret the intent behind your demands.
I appreciate your feedback.
I saw that Logseq proper has a CLI, but it doesn’t seem too robust yet. I invite the maintainers to steal whatever ideas they like from my repo. I was initially excited about MCP for the modularity of tooling, but like Mario Zechner, I find CLIs are the better way forward for most use cases. They’re simpler and available to humans and agents alike. The human can demonstrate commands to the agent and vice versa. We teach each other.
i would invite you to look more closely into the CLI. it went through a revamp not long ago and was tuned to be able to work with agents headlessly in a performant manner (including token usage)
1 Like
I sure will! I’d love to have a team providing most of people want in this agentic era.
1 Like
I already had the logseq cli installed, I just can’t seem to get it to do anything all that useful. I have been installing Logseq updates since the beginning and everything I do has been local-first so I can manage it in git. When I logseq list it mentions a graph under “DB Graphs” using a name I never chose. I would’ve thought the name would be the name of the root folder of the repo but I see no “File Graphs” option. At this point, the docs and the tool are not baked enough that I am able to get it to do anything.
As the official CLI matures, I’d encourage the devs to put effort into expounding upon the use cases with more robust docs.
In the meantime, another alternative:
If you are using Logseq DB, you should be using the new cli. Download the latest Logseq db desktop app, install and the go to the terminal to run Logseq —version
Does anyone have any insight into the ease of agent interaction in the case of DB cli vs markdown file? I am most familiar with Codex, so my intuition is it would be easiest to give it access to md files to read directly. I haven’t used much local-first llm, so I don’t have a sense of how good it is at file reading vs too calling. I am trying to set up a logseq-llm system myself, and trying to decide if I should go with the DB or MD version.
There’s a two-way Markdown mirror feature in-progress so it’s likely soon it’ll be the DB version.