A Knowledge Base by Manifest: How an AI Agent Structures Your Company's Knowledge

Obsidian and Second Brains are everywhere right now, and everywhere you look, you see the same screenshot: the graph. Lots of nodes, nicely connected, looking great in presentations. But the graph itself tells you nothing about how efficiently an AI can actually work inside the vault. A machine is given a beautiful network with no hard rules. There are no conventions defining what it is allowed to write and how, and no reliable place where it can find out what is currently valid. The graph shows connections, but it is not a memory.

I have been using Obsidian for months. For a long time, my vault was also just a repository with an impressive graph. Projects, research, notes, and personal goals were comprehensively documented and carefully structured. For me, but not for an AI. When I asked my agent what it knew about a topic, I got partial knowledge or fiction. Not because the model was bad, but because the vault had a structure that a human could read, not one that a machine could reliably navigate. I was the bottleneck in the system. Every question meant manual work: assembling context, searching through files, or copying excerpts.

The difference between storage and memory is not the tool. It comes down to three things: • Structure that a machine can navigate. • Rules that define who is allowed to write what. • A way to query knowledge without having to assemble it again every single time.

These are exactly the three things most vaults are missing. The graph is decoration, not an operating system.

An Agent Builds It After 8 Questions

That is why I developed a structure that can be described as a Second Brain. It is not designed to look appealing to humans, but to provide machines with a navigable structure. This allows my agents to work with the current state of knowledge at any time, without me having to manually assemble the context.

My solution does not follow the usual path of building another app or database. It starts with a manifest.

The principle is simple. An agent reads a file called VAULT_BOOTSTRAP_MANIFEST.md. It then asks me about the language, the domains, and agent memory. Based on my answers, it builds the entire knowledge base using three layers, 11 mandatory rules, and five core workflows. Pure Markdown. No Python, no database, no installation.

The system uses the Karpathy LLM Wiki pattern: raw information goes in, structured knowledge comes out, with rules on top. Because it is pure Markdown, it works with any agent that can read and write files, whether that is Claude, Cursor, Gemini, Hermes, or anything else. You can switch agents, or use several at the same time, and the memory remains.

Three Layers, One Hierarchy

The architecture can be explained in one short paragraph. A Raw layer contains immutable sources, a Wiki layer contains knowledge prepared by the agent, and a System layer contains rules and workflows. An ownership matrix defines who is allowed to touch which folder. The human supervises the sources, while the agent writes the Wiki. At the top sits VAULT.md with 11 mandatory rules. Below that, the hierarchy is VAULT.md → AGENTS.md → CLAUDE.md → Skills. Five key steps keep everything working: ingesting information, querying it, validating it, approving it, and measuring it.

Rules You Can Test

But the real difference lies somewhere else. Not in the structure, but in the discipline.

The memory can be tested before it goes into production. The acceptance test has two parts: first, the manifest itself is validated, then the vault that was built from it. Structure, frontmatter, JSON validity, links. If something is wrong, the vault is not considered complete.

During operation, a Lint check monitors seven areas. One of them is outdated knowledge. If a statement in the Wiki is no longer correct because a newer source has corrected it, the system flags it. It also detects orphaned pages, missing concepts, and drifting indexes.

And because multiple agents access the memory in my setup, they coordinate through a Write Log, not through lock files and not through a central instance. Every write operation is appended, never overwritten. The system detects conflicts through overlapping entries. If an agent violates a writing rule, there is a remediation procedure that fixes the damage instead of hiding it.

The Health Score turns this discipline into a number. After the first Ingest, it was at 78%. The starting point was below 100% because orphaned links and missing metadata are things you often only discover during actual operation. All problems were identified and fixed before going into production. As of August 2026, the project is alive and continues to evolve.

A score below 100% may sound wrong at first, but I consider it honest. The score is an operational metric, not a marketing metric. A system that already shows 100% during acceptance either has a test that is too easy or is lying.

Why Not Use a Vector Database?

One question that often comes up is: why not simply use a vector database as the central knowledge base?

Because a vector database does something different from what most people think. It works on a snapshot, the state of the data at the time it was embedded. My agents work on the real, current vault. When a file is added, it is immediately available. When a statement is corrected, the old version is gone.

And if semantic search is needed after all, the system provides an interface for it. The setup explicitly asks whether external storage should be used. The vector database is not the foundation in this context. It is a component that can be connected when the specific use case requires it.

Sovereign Means: You Decide for Each Layer

Another question that often comes up, especially in Germany, is data protection.

The data stays on your server. The vault is pure Markdown. No mandatory cloud. No vendor lock-in. Because the system runs headless, without a desktop application, it can be containerized and deployed in your own Kubernetes environment.

This is where I separate two layers that are often mixed together. The data layer, consisting of the Vault, Manifest, and Write Logs, never leaves your server. For the model layer, you have a choice: a fully local setup, for example with Ollama; an LLM hosted in Germany or the EU, for example via STACKIT; or a US API. In the latter case, prompt and content data are processed by the respective provider in the United States.

Sovereign, in this context, means that you make the decision for each layer instead of leaving it to the tool.

For German companies, this is not an ideological question. It is a question of security. The EU AI Act already requires AI literacy within organizations, with Article 4 applying since February 2025. And anyone who substantially modifies an existing AI stack or deploys it for new purposes can, under Article 25, move into the role of a provider and take on the associated obligations. For high-risk systems, this is the rule rather than the exception. Anyone building their own knowledge system should understand that responsibility does not disappear. It simply becomes more visible.

I have tested this with my own agent in everyday use. I ask a question, the agent accesses the vault, and answers with a source reference. Live and without routing the knowledge base through the cloud.

What Are the Next Steps?

Next, I will introduce a standardized access layer based on MCP, allowing any agent to access the memory through defined tools instead of raw file access. In addition, I am working on a RAG integration for cases where semantic search across huge, unstructured datasets is genuinely needed. The deployment target is a Sovereign Cloud, ensuring that the entire process from code to EU cloud remains consistent and within the intended boundaries.

The entire software is open source: github.com/nakielski/second-brain

An intelligent agent does not read everything. It knows where to find the right information.

What is holding you back from using a file-based memory?