Obsidian Is Optional: Build an AI Second Brain With Plain Markdown

No, you do not need Obsidian to build a second brain for yourself or an AI agent. A folder of plain Markdown files can provide the durable memory layer, links, search, history, and retrieval rules. Obsidian can make that folder more pleasant for a human to browse, but it does not have to own the system.

That distinction matters. If your knowledge only works inside one application, the application has become part of your memory contract. If the source of truth is ordinary files with portable links and explicit conventions, you can open the same memory with Obsidian, VS Code, a terminal, a coding agent, or a tool that has not been invented yet.

Obsidian's own documentation supports this model: it stores notes as Markdown-formatted plain text files in a local folder called a vault. The app adds indexing, navigation, backlinks, graph views, properties, plugins, and a polished editing experience around those files.

The useful question is therefore not “Obsidian or plain text?” It is “Which parts must remain durable, and which parts can be replaceable conveniences?”

What a second brain actually needs

A dependable external memory system needs five things:

1. A source of truth. The original knowledge must live somewhere you control.

2. Stable references. Notes need links or identifiers that other notes and agents can follow.

3. Retrieval. You need a predictable way to find the right material without loading everything.

4. Curation rules. The system must distinguish raw capture, reviewed knowledge, decisions, and archives.

5. Recovery. You need history and a separate backup when a person, agent, sync service, or disk makes a mistake.

None of those requirements demands a particular notes application.

For an AI agent, the file contract is usually more important than the interface. For a human who spends hours browsing and connecting notes, Obsidian's interface may be worth using every day.

A minimal file-first architecture

Start with fewer folders than you think you need:

memory/
  MEMORY.md
  inbox/
  daily/
  projects/
  people/
  decisions/
  knowledge/
  archive

Give each location one job:

• MEMORY.md is the map. It explains the structure, naming rules, trusted sources, and the order an agent should read.

• inbox/ receives unprocessed captures. Nothing here is assumed to be correct or durable.

• daily/ records chronological observations and work logs.

• projects/ holds active outcomes, state, constraints, and next actions.

• people/ contains appropriate relationship context. Keep sensitive personal data out unless you have a clear reason and protection boundary.

• decisions/ records what was decided, why, alternatives considered, and when to revisit it.

• knowledge/ contains reviewed concepts, procedures, and reference notes.

• archive/ holds inactive material that should remain retrievable but should not crowd the active map.

Folders help with scope, but they are not the knowledge graph. Links between notes create the graph. Index files tell humans and agents where to enter it.

Use a portable note contract

Consistency beats a clever plugin. A useful note can stay simple:

---
id: decision-2026-08-29-memory-source-of-truth
created: 2026-08-29
updated: 2026-08-29
status: active
tags:
  - memory
  - architecture
---

# Keep Markdown files as the memory source of truth

## Summary

The canonical memory lives in plain Markdown. Editors and indexes are replaceable.

## Evidence

- Source and observation with a URL or local file reference.

## Related

- [Memory map](../MEMORY.md)
- [Retrieval protocol](../knowledge/retrieval-protocol.md)

## Revisit when

- File count or retrieval latency makes the current search workflow unreliable

The exact fields can change. The important part is that the contract is documented, readable without a plugin, and stable enough for an agent to follow.

Prefer standard relative links

Use standard Markdown links when portability matters:

[Memory architecture](../decisions/2026-08-29-memory-architecture.md)

CommonMark defines Markdown as a plain-text format for structured documents and specifies ordinary inline and reference links. Obsidian supports standard Markdown links as well as its shorter [[wikilink]] syntax. Its documentation also warns that block references are Obsidian-specific and will not work outside Obsidian.

Wikilinks are fine if every important reader supports them. Standard relative links are the safer default when the same memory must work across repositories, editors, static-site generators, and agents.

Make references searchable

Use a stable id in frontmatter and include a readable date-and-slug filename for decisions and events. Then a backlink is just a reverse search:

rg -n --glob '*.md' 'decision-2026-08-29-memory-source-of-truth' memory

This is less polished than a backlink panel, but it is transparent and scriptable. You can later generate backlink sections or a graph from the same links without changing the source notes.

Keep indexes curated

Do not make one giant file that tries to contain everything. Keep MEMORY.md short and link to small index files when a domain grows:

memory/MEMORY.md
memory/projects/README.md
memory/decisions/README.md
memory/knowledge/README.md

An index should answer three questions: what belongs here, which notes matter now, and where should the reader go next? It is a route map, not an exhaustive database dump.

Give the agent a memory protocol

Files alone do not create good memory. The agent needs rules for reading, writing, and promoting information.

Put a protocol like this in MEMORY.md:

1. Read MEMORY.md before memory-dependent work.
2. Follow the smallest relevant index; do not load the whole memory folder.
3. Treat inbox and daily notes as unverified observations.
4. Cite the file path behind any durable claim or decision.
5. Write new captures to inbox first unless the destination is unambiguous.
6. Do not silently rewrite decisions, source records, or personal facts.
7. Update related links and the relevant index when promoting a note.
8. Put secrets in the credential system that owns them, never in memory files.
9. End significant work by recording changed decisions, open questions, and next actions

This protocol prevents two common failures. First, the agent does not need to stuff the entire knowledge base into its context window. Second, every chat does not automatically become “memory.” Unreviewed transcripts and speculative answers should not quietly harden into facts.

Tool-specific files such as AGENTS.md or CLAUDE.md can point to this shared protocol. Keep the durable rules in one place instead of maintaining conflicting copies for every agent.

Search first, index later

For a small or medium collection, filenames, frontmatter, and recursive text search are often enough:

rg -n --glob '*.md' 'customer objection|pricing concern' memory/
rg -l --glob '*.md' '^status: active$' memory/projects/
rg -n --glob '*.md' '## Revisit when' memory/decisions

When retrieval becomes slow or imprecise, add a derived index. SQLite FTS5 can provide local full-text search. A vector index can help with semantic retrieval. Both should be rebuildable from the Markdown files.

That boundary is crucial:

Markdown files = source of truth
Search, backlink, graph, FTS, and vector indexes = disposable projections

If an index is corrupted, stale, or tied to a vendor, you rebuild it. You do not lose the knowledge.

Use Git history, but still make backups

Git is a strong fit for reviewed text because it records snapshots, makes changes inspectable, and lets you restore earlier versions. Commit meaningful memory changes with messages that explain why the state changed.

Git is not automatically a complete backup. Untracked files are not included in commits, and a repository stored on one disk still shares that disk's failure risk. Use an independent backup to a separate location. Obsidian's own backup guidance makes the same distinction: synchronization keeps files aligned across devices, while backup preserves a recoverable copy after loss or corruption.

Also define an agent write boundary:

• permit direct writes to inbox/ and designated working notes;

• require review before changing durable decisions or personal records;

• inspect a diff before accepting broad rewrites;

• exclude credentials, tokens, private keys, and sensitive exports; and

• test recovery before trusting the system.

If you choose Obsidian as the editor, protect the vault before giving Claude Code write access. The storage model does not remove the need for permissions, review, and backup.

When Obsidian is worth using

Obsidian earns its place when its human experience removes real friction. Use it if you value:

• automatic backlinks and unlinked mentions;

• graph and local-graph navigation;

• fast link completion and automatic link updates after renames;

• a polished reading and editing interface;

• mobile access and a familiar notes workflow; or

• selected plugins whose behavior you are willing to maintain.

You can adopt Obsidian later by opening the existing memory/ folder as a vault. If you used standard Markdown and kept application-specific metadata optional, migration is mostly an interface decision rather than a data migration.

Skip it when the agent is the primary reader, terminal or editor search already works, plugins would become another maintenance surface, or you simply do not enjoy using the app. A tool you avoid opening does not improve your memory.

Where Aident Loadout fits

Aident Loadout is not the storage layer for this system. The Markdown folder remains the source of truth. Loadout becomes useful when an agent needs current evidence from an external service and you want discovery, credentials, schemas, risk, and execution to stay explicit.

For example, an agent can use one reviewed, read-only research Action, write the returned source URL and retrieval date into inbox/, and let you decide what deserves promotion into knowledge/. Keep the raw provider response out of durable memory unless it is appropriate, necessary, and safe to retain.

Install or update Aident with the canonical setup prompt:

Follow https://aident.ai/SETUP.md

Then ask your agent to discover one read-only Action for the source you actually need, inspect its schema and cost, and stop for review before execution.

Set up a file-first agent workspace

The practical answer

Start with plain Markdown, standard relative links, one short memory map, a documented agent protocol, recursive search, Git history, and a separate backup. Add Obsidian when its human interface makes the system easier to use. Add full-text or semantic indexes only when retrieval evidence justifies them.

The durable second brain is not the app. It is the combination of owned files, stable references, selective retrieval, curation rules, and recoverable history. Everything else can be a replaceable view.

Sources

• Obsidian: How Obsidian stores data, reviewed August 29, 2026.

• Obsidian: Internal links, reviewed August 29, 2026.

• Obsidian: Backlinks, reviewed August 29, 2026.

• Obsidian: Back up your Obsidian files, reviewed August 29, 2026.

• CommonMark specification 0.31.2, reviewed August 29, 2026.

• ripgrep project documentation, reviewed August 29, 2026.

• Git: What is Git?, reviewed August 29, 2026.

• SQLite FTS5 extension, reviewed August 29, 2026.

Refresh this guide when Obsidian changes its storage or link model, CommonMark changes the relevant link specification, or the recommended Aident setup and Action review flow changes.