I’m trying to get a clearer picture of how Logseq’s official development roadmap relates to the broader shift toward agentic AI, tools that don’t just answer queries, but can take actions, automate workflows, and operate more like assistants embedded in our personal knowledge systems.
I’m aware of the ongoing database work and the last official update from December 25, but beyond that, I haven’t seen much consolidated information about how (or whether) Logseq plans to integrate with this new wave of AI‑driven capabilities.
So I’d love to ask the community:
Is there a summary, discussion, or any compiled information about Logseq’s direction regarding agentic‑AI features?
Some angles I’m particularly curious about:
Long‑term vision: Has the team shared any thoughts on how Logseq might evolve in an era where AI agents can read, write, and act on our notes?
Plugin ecosystem: Are there ongoing community or third‑party efforts to bring agentic‑AI workflows into Logseq?
Official stance: Has Logseq commented on whether agentic‑AI integration is part of their roadmap, or if the focus remains primarily on the new database and core stability?
Interoperability: With more tools adopting open standards for AI‑driven automation, is Logseq planning to support any protocols or APIs that would allow agents to interact with the graph safely?
If anyone has links, summaries, or insights, whether from Discord, GitHub issues, community calls, or developer notes, I’d really appreciate it. This seems like an important moment for PKM tools, and it would be great to understand where Logseq fits into that landscape.
Thanks in advance to anyone who can shed some light on this topic.
For now the switch from md storage to database seems like a move away from easy integration with AI tools. Markdown files can be easily added as context and they could be easily created / modified by agents.
But a great API could be equally good if wrapped up in an MCP. I have even found an existing one but didn’t try it yet.
It would be cool to be able to give AI strict permissions to only access the data needed. And this could be tricky as in logseq it is spread throughout.
I personally hope the core app has no specific AI features whatsoever.
The development of general purpose tools like logseq should be guided by solid time-proven technologies and theories, not “trends”.
Sure, logseq should provide a robust API , which can then be used by plugin developers to create whatever they want. This keeps the app flexible, while still ensuring a performant lean core.
Logseq could have developed a very small MCP server that gave Markdown users AI abilities. Instead the team, which is basically one guy, is moving towards something easier to monetise on the cloud. They will say the new version offers these new features, which is true and fail to disclose that the old version could have offered most of that too. The new “db” version uses only a single table and includes nearly every performance penalty of the Markdown file version.
Logseq DB has an MCP server. try it out.
Logseq DB is still Local First and Privacy first.
Both Logseq MD and the DB use the same data model based on datascript. The output was persisted to several MD files and reconstructed into the datascript db, and now with Logseq DB, it is still datascript but with sqlite. Much more reliable and faster in various ways.
The reliability and performance challenges led to the rearchitecture of the app, and that was communicated in this forum and in discord. If you think those can be addressed with the MD version, I recommend you do some experimentation with the code and share your finding. The code is here GitHub - logseq/og: Logseq og (file version) now.
Also, logseq is not a one person band. It is a team of 4.
@daviddelven Somehow, the fact that over 93% of your Question is Ai generated (according to ZeroGPT) is emblematic for the point you’re making. Why should anyone in this forum bother to answer a question that you didn’t even bother to write?
What’s important is the end result of his post, which is clearly structured. Who cares HOW he wrote it? It’s about the end result. If he used a tool to save him time then I would encourage it.
Markdown offers the best support for LLMs. Therefore, it is crucial to keep Markdown files accessible for LLMs to query, enabling them to use any classical text processing tools—such as grep, awk, sed, or any other tool for reading and writing—just as they would with any code base. However, because LogSeq Markdown includes double links, annotations, properties, it is no longer purely plain text. Hence, it is important to implement some MCP (Model Context Protocol) or CLI tool that allows LLMs to query and make use of this structured note.
I have some concerns about moving to a database-based version. While databases are good for structured information and may offer advantages from a computer science perspective—such as synchronization and cloud services—they are not well-suited for unstructured information like sloppy notes. However, new breakthroughs in text processing techniques, such as LLMs, are emerging and can handle unstructured content effectively.
AI coding, AI writing, and agentic AI techniques should work well with Logseq. The system needs version control like git, and the note folder should function as much as possible like a code base. Moving to a database seems to go in a different direction. To access a database, LLMs would need a bridge, such as queries. Moreover, version control like git would not work. I think this is also why many users have moved away from Notion.
Logseq DB has backup built-in. It automatically backs up every hour and does a daily rollup.
It also has a recycle feature that offers decent undo/redo.
Soon, we should have a node history feature.
It is true that LLMs do fine with unstructured content. Logseq MD and Logseq are both structured under the hood. And that is a multiplying factor when using LLMs with the outlined/graph-like data.
With Logseq DB, an LLM will interact with one or more graphs via the new Logseq CLI, which I suspect most will use. Logseq DB already has an MCP server (this needs another update, given recent MCP best practices in the industry). Last, we have the HTTP API Server.
The interoperability of Logseq DB with other tools has drastically improved.
@Neo_Tang I’ve been using Claude Code with Logseq MD daily for the last 3 months. Initially I tried the MCP server, but quickly moved to direct API as far more powerful.
With a few explicit rules, I can query my graph and write to my graph seamlessly. From what I’ve seen of the DB version there is already native AI integration for agents.
This sounds too harsh. Devs are doing their best moving the app where they think is best.
I think this is a good enough solution. I really hope that everything will not turn to markdown just for the AI. If it is so smart it should (and can) read from whatever)))
In addition, Logseq DB can export to MD or EDN, which can be used with AI, if a user prefers textual format.
A user could use AI to read from MD and write to the graph via the CLI, or just use the CLI both read and write.
Soon, there will likely be a feature to “mirror” the pages to markdown files.
This is an incredible discussion. It highlights a real challenge: how to embrace the agentic AI era while keeping Logseq lightweight, private, and local-first.
To answer @danzu’s open invitation to experiment with the Markdown (OG) file ecosystem, and addressing exactly what @ivangretsky and @Futile_Ferret mentioned about needing a lightweight, dedicated standard for Markdown graphs—I built exactly that.
I recently released Matryca LLM Wiki (matryca-logseq on PyPI). It is a pure headless, local-first Model Context Protocol (MCP) server and CLI companion designed natively for Logseq OG Markdown graphs.
Here is how it acts as the bridge discussed in this thread without bloating the app:
Pure Headless & Safe Writes: It interacts directly with your .md files via strict AST parsing—no need for the Logseq desktop application to be running. To solve the concurrency problem, it uses OS-level file locking (fcntl.flock) and atomic file swaps. Background agents (like Claude Desktop or Cursor) can safely write, update outlines, and refactor your notes even if the Logseq desktop UI is open, with zero race conditions or data corruption.
Lean Core Philosophy: It perfectly aligns with @BBob’s perspective. Matryca is an independent sidecar tool. It requires ZERO refactoring, zero dependencies, and zero changes to Logseq’s core codebase.
X-Ray Token Economy: Agents consume massive amounts of tokens reading raw notes. Matryca automatically compresses long 36-character block UUIDs into short positional shortcuts (like [0], [1]), reducing context window token overhead up to 35x.
Because it is globally distributed via uvx, it requires zero installation. You can plug it into Claude Desktop or Cursor with 3 lines of JSON and start treating your local graph as a secure, production-grade AI data plane today.
It is 100% open-source and backed by 162 strict passing integration tests. I would love to hear your thoughts, especially from the local-first AI builders here!
As mentioned by others in this thread, there’s an MCP server and CLI. I think those are the foundational things one needs to build agentic AI tooling on top of. I think that is exactly the right level of toolig to be implemented by the core team. Anything more is distracting away from the core focus.
is Logseq planning to support any protocols or APIs that would allow agents to interact with the graph safely?
“safely” is a loaded term. What do you mean here? The CLI should be able to write to Logseq? Not write to Logseq? It’s a very loosely defined term, and I think the right level for this to be at is “read only” access vs. not. Anything more than that (obeying specific write rules, not deleting stuff, etc) should be on the agent side, not on the CLI.
