Where MCP ends and what comes next

Today Obsidian MCP is a working part of my system.

Through it a language model can search Obsidian, open notes, assemble project context and work with files.

That’s exactly the problem I originally wanted to solve.

But with use, the next boundary became visible.

MCP solves the problem of access well.

The model gets a set of tools and decides for itself what to search for, which notes to open and what context to assemble.

But looking further ahead, what I need is no longer just the ability to reach files.

I need a separate system that itself understands how my project memory is organised.

So the next stage became the Obsidian Knowledge Agent.

That project is currently in active development.

To simplify the difference a lot, MCP looks roughly like this:

The LLM reaches Obsidian through tools and assembles the context it needs on its own.

The Knowledge Agent should work differently.

It gets its own search and indexing layer, an understanding of project structure, of links between files and Canvas, of source rules and project boundaries.

So in front of the model there will be a separate system that first determines where to look, what relates to the question and what context really needs to be passed on.

Working with changes shifts too.

In MCP, access to a note and the ability to change it sit quite close to each other.

In the Knowledge Agent, reading, reasoning and changing state are separated.

Finding information is one circuit.

Proposing a change is another.

And actually changing a project happens only through a separate controlled mechanism with safety rules.

As a result the role of MCP itself changes.

It doesn’t disappear.

But from the centre of the architecture it turns into one of the ways of connecting to the system.

If the current architecture can be described like this:

LLM → MCP → Obsidian

the next one gradually becomes:

LLM → Knowledge Agent → project memory

Where project memory means not only Markdown files but also project structure, Canvas, linked sources, its own index and the rules for working with all of it.

Part of this architecture is already implemented, part is still being built.

So I’ll write about the Obsidian Knowledge Agent in detail later.

And this series can end here.

MCP became the first working bridge between an LLM and my memory.

The next stage is no longer about giving a model access to knowledge.

It’s about building a system that knows how to work with that knowledge.