System Building
Obsidian Breaks the Day You Add a Second Agent
A personal knowledge tool is designed for one person who already knows where everything is. The knowledge of the kitchen sits in your head. Add a second agent, a second machine, or a second person and the system collapses. Here is the two-layer architecture that scales, and the test you can run today to find out if you need it.
The Problem
Obsidian does not fail when your vault gets messy. It fails the day you add a second pair of hands.
One agent. One other device. One human collaborator. A system built for a single cook has one door, and only one person can walk through it at a time.
The home kitchen analogy is not a metaphor. It is structural. A home kitchen is designed for someone who already knows where the salt is. Knowledge lives in the cook's head. The system is efficient for that cook and unusable for anyone else. A professional kitchen runs on a completely different model: stations, labeled containers with dates, written tickets, everything in the same place every service. A new prep cook can walk in and be useful within an hour.
That is the gap between a second brain and an operating system.
AI agents are not like a second person who will learn your system over time. They read what is accessible and act on it. If the knowledge lives in a local vault on your laptop, an agent running on your server cannot reach it. An agent running overnight on a schedule cannot reach it. A second agent running in parallel cannot reach it.
Obsidian is not going anywhere. If you are a solo operator who will never add another agent or device, keep it. But if you are trying to grow, you are building the wrong kitchen.
The Build Recipe
Two layers. Not one app.
Layer 1: The Harness
This is the agent runner. Claude Code, Codex, or any LLM-based execution environment. It is not your knowledge. It is the hands that work on it.
The harness does not need to be permanent. You rent the model. You can swap Claude Code for Codex tomorrow, and a well-built system does not care. The work lives in the knowledge base, not in the model.
Layer 2: The Live Knowledge Base
This is the kitchen. It is where tasks live, where context is stored, and where agents read before they act and write when they finish.
The critical constraint: it must be live and cloud-accessible. Not sitting on your laptop. Any machine, any agent, anyone with the right access, at the same time.
Notion is the recommended choice for most setups because:
- It is cloud-native (no sync to manage)
- It has a reliable API (agents can read and write)
- It handles structured data (databases for tasks, records, outputs)
- It is human-readable without a technical interface
The app matters less than the fact that it is live. An Airtable base, a Supabase table, or a shared Google Sheet will work. What will not work is a folder on your laptop, a local markdown vault, or anything that requires manual sync.
The Connection
Your harness reads from the knowledge base before it starts. It writes back when it finishes. The next agent, or the next session of the same agent, starts from current state.
What this produces:
- Two agents can run in parallel because they read from the same room
- A human can pick up a task mid-way without a briefing
- Every session improves the system because outputs accumulate
You own the room. Anyone with credentials can work in it.
How to Run the Test
Before building anything, test whether you need it.
Take one task you do every week. Put the context for that task somewhere an agent can reach from any machine. This means writing it down, structured, in a cloud location with an API.
Then point an agent at it. Give the agent the context URL or database ID, not the task itself, and ask it to pick up the task from the context.
If a stranger could walk in and be useful within an hour from what is in that database, you have a professional kitchen. If the task requires you to explain where things are, you still have a home kitchen.
Run this test with one task. If it works, extend it to your most repetitive weekly operation. If it fails, the problem is almost always that the context is in your head, not in the system.
What You Get Back
Once two layers are running:
01. Parallel execution without collision. Two agents reading the same database can split a job without conflicting, because each writes to its own output row and reads from a shared input.
02. Model independence. Swap the harness tomorrow. The knowledge base does not care which model is running the tasks.
03. Compounding. Each run leaves the database better than it found it. Outputs from last week become context for this week. Agents get faster as the system fills out.
04. Remote orchestration. You can direct work from any device, including a phone with a voice-to-text client. If the agent reads from the cloud and writes back to it, your physical location does not matter.
05. Human fallback. Any task can be picked up by a person without a handoff. The database is the briefing.
The Honest Part
Migrating from Obsidian is not instant. You have context in your vault that does not have a natural home in a database. Moving it takes time and decisions about structure.
Start with new tasks, not with migration. Build the two-layer system for one new workflow, prove it works, then migrate old context incrementally as you use it. Do not try to migrate the whole vault at once.
Notion is the recommended choice, not the only choice. If your team already uses Airtable or another cloud database with an API, use that. The specific tool is less important than the cloud-accessible, agent-readable requirement.
The harness does not need to be Claude Code or Codex. Any agent runner with MCP support or API access works. The goal is separating execution from knowledge, not picking a specific execution environment.
If you have built a second brain in Obsidian, that build is still useful for personal notes, writing, and reference. What you are building here is a parallel layer for work that involves agents, and the two coexist fine.
If You Only Do One Thing This Week
Pick one task you do every week. Write its full context into a Notion database: the goal, the inputs, the steps, what a good result looks like. Include everything a new hire would need to complete it without asking you a question.
Then point an agent at that database and ask it to run the task.
If it succeeds, you have proven the two-layer model works for your setup. If it fails, read what the agent got stuck on. That is the gap in your knowledge base. Fill it. Run again.
One task. One database. That is the kitchen.