What does this solve?
The company's knowledge is usually scattered across heads, correspondence and a dozen documents in the cloud, and there is nothing to give it to the AI agent: it cannot read someone else's chat and does not have rights to the corporate disk. Obsidian stores notes like regular notes .mdfiles in a regular folder on the disk - what the agent reads directly and looks for grepand edits with the same tools as the source code. At the same time, a person continues to work in a convenient editor with links, search and feedback, and not in typing text files using a notepad.
How it works
Storage
Storage (vault) - folder. Inside there are markdown files, attachments and a service directory .obsidian with settings, theme and plugins. There is no separate database: if you deleted the application, the files remained and could be opened with any editor. Because of this, the same folder is available to the human, the script, the version control system and the agent, and no one needs to export.
Connections
Record [[Имя заметки]] creates a wiki link by file name with auto-completion as you type. A panel of backlinks appears in the target note - a list of what links to it. Renaming a file updates links throughout the repository. Tags through the bars provide a second, cross-section on top of the folders. The connection graph is drawn automatically.
Note properties
At the beginning of the file - a YAML block between triple hyphens: note type, status, owner, update date, tags, source. The machine-readable part of the database lives here. These fields are used to filter both the person, the plugins, and the agent; everything else in the file is free text.
Organization
Folders with meaning, a table of contents note for each major topic, file naming convention. For an agent, the folder structure is secondary, and three things are critical: one fact - one note; in the title are the words with which this fact will be asked; in frontmatter the update date to distinguish the living from the rotten.
How does the agent come into this?
Three working methods. The first is direct file access: the agent reads, searches and writes to the storage folder, just like any project directory. The second is a repository: the repository is under version control, the agent commits edits, the person looks at the diff and rolls back the unnecessary ones. The third is an MCP server on top of the folder, which gives the agent search and reading as tools.
A layer of context preparation is useful on top of any of them: before answering, collect a canon note on the topic plus search results using the keywords of the question into a hint. The quality of the response is determined by which pieces of the database reached the model, and not by what model it is.
Synchronization
Version control system, Obsidian built-in sync or cloud folder are suitable. There is only one rule: a person and an agent should not write to the same file at the same time. The cloud folder on the conflict silently creates a second file marked as a conflict, and no one will notice it; the repository gives an obvious conflict that will have to be resolved manually.
Useful scripts
- Canon of definitions: one note per metric with wording and a ready-made query, which the agent must read before any calculation.
- Decision log: what was chosen, what was rejected and why - after that the agent stops offering what was already rejected.
- Incident reviews: symptom, reason, what was fixed, how to check what did not return.
- Onboarding: accesses, agreements, who is responsible for what - one source for the person and for the agent.
- Rules of the agent himself: tone, prohibitions, response format - in a separate file in the storage, and not in correspondence.
- Drafts of publications and prepared letters with links to original facts.
Limitations
There are no permissions for an individual note. Whoever received the folder received all the contents. Clients’ personal data, passwords and tokens are not stored in the storage, and this limitation is not circumvented by settings.
Markdown does not replace a database: there are no types, uniqueness, transactions and referential integrity. Accounting for clients, payments and balances lives in a table or in a DBMS, and the notes contain a description of how this accounting is organized.
Plugins work within the application, not in a file. The Dataview query is visible to the agent as text in a code block, rather than as a counted table. Therefore, frontmatter should be machine-readable, while beautiful summaries remain for humans.
The volume produces noise. When there are a lot of notes, the search returns two dozen similar files, and the agent drags everything into context. It is treated not by putting things in order in folders, but by merging similar notes into one and using explicit headings.
The base is rotting. An agent who is allowed to write will produce duplicates within a month: the same idea under a different name. A strict rule in the instructions helps - first search for an existing note using keywords, update it, create a new one only if nothing is found.
The connection graph looks impressive and hardly helps in the work. There is no point in looking into it to make decisions.
How to check the result
Blind question: ask the agent about something that has the answer in exactly one note, without prompting the path to the file. Found it - context assembly works; started composing - the problem is in the search, not in the knowledge.
Search by user words: take the wording from a real question and run it grep by storage. If the note does not contain the words it is asked for, add these words to the title and first paragraph.
Broken links: a script or plugin that checks everything [[...]] with names of existing files. A link to nowhere means either a renaming bypassing the application, or a note that you were going to write and forgot.
Property Validity: a script that parses YAML in all files and prints those where the block is broken or the update date is missing. Such notes are the first candidates for analysis.
Freshness: once a quarter, upload a list of notes that have not been updated for more than a year, and for each decide whether to update, merge with the next one, or delete.
Edit history: viewing diffs for the week shows what exactly the agent wrote. Three new notes with almost identical names are a signal to fix the instructions before there are thirty duplicates.