Why a solo operator should spend real time on filing and syncing systems
If you run more than one brand, you already know the problem.
You have a thought. The thought is useful to Brand A. It is also useful, in a stripped-down form, to Brand B's content repo. There is a version of it that belongs in your personal journal, because you noticed it while reflecting on something else entirely. And there is a public version of it that one day might become a blog post.
You can:
- Write it once in your main notes app, then manually copy it three times.
- Write it in the brand workspace where it is most relevant, and accept that the other brands will never see it.
- Build a system where you write it once in the right place, and the routing happens automatically.
Most operators pick 1 or 2. That is fine until you have three brands and a hundred ideas a week. Then it stops being fine.
This post is about option 3. It is a generalisation of the multi-vault parallel filing system I run on my own Obsidian setup, written for anyone managing more than one brain.
The actual problem is not Obsidian
The Obsidian piece is incidental. The real problem is that knowledge workers running multiple brands are doing two jobs at once: the work, and the filing of the work.
The filing job is invisible. Nobody bills for it. Nobody talks about it on a podcast. But it eats a real percentage of every operator's day. Every time you finish a piece of thinking and have to decide where it lives, you pay a small tax. Multiply that by the number of brands you run, then by the number of notes you write, then by the number of years you are going to run this setup.
Most people pay the tax. A few people automate it.
The shape of the system
The setup has four moving parts.
One central brain. This is your source of truth. It is where you actually think. Everything starts here. Journal, raw research, planning, people you know, half-formed ideas. The central brain is messy and that is fine. It is for you.
Satellite brains. One per brand or per public-facing surface. These are downstream. Each one has its own folder structure, its own audience, its own rules about what is allowed in. A satellite brain might be a polished operating vault for a business, a content production repo, a public-facing knowledge base, or a research workspace shared with a partner.
A written operating contract. A single file at the root of the central brain that any coding agent reads on session start. It lists the satellites, defines which sync pattern each one uses, lists the universal exclusions, and defines the override commands. The rules live in the file, not in your head.
A coding agent. Claude Code, Codex, whatever. Its job is to read the contract and do the filing for you. It is not making editorial decisions. It is following the rules you wrote down.
The four sync patterns
Not every satellite is the same shape. The system I use has four patterns and you pick one per satellite.
Pattern A: full mirror. The satellite is structurally a twin of the central brain. Same folder shape, same conventions. Notes get straight-copied with a slug adjustment. Useful when the satellite is a dogfood or demo operating vault for a business you run.
Pattern B: narrow mirror. The satellite is a dedicated brain for one brand, with its own structure. Public-facing material mirrors freely. Internal strategy stays in the central brain. Useful when the satellite has a different audience and a different folder shape.
Pattern C: stripped mirror. The satellite is one step from public. A content production repo, a partner-shared workspace, anywhere that customer names or financials cannot show up. Every write runs through a stripping pass that removes the unsafe material before the note lands in the destination. Useful when the satellite is close to a publishing surface.
Pattern D: read-only feeder. The satellite is a context source for the agent but not a write target. The agent can read it for grounding but does not file into it without explicit confirmation. Useful for code repos, partner spaces, or anywhere commit hygiene matters more than note flow.
Pick the right pattern per satellite. Document the choice once. Move on.
The stripping pass is the unlock
The single most useful component of the whole system is the stripping pass.
Most of the resistance to filing into a near-public repo is fear of leaking the wrong thing. A customer name. A pricing decision. A competitor pulse. A meeting attendee. The cost of leaking those things is high and the upside of mirroring the note is low, so by default you do not mirror. The note stays trapped in the central brain. Nobody benefits.
The stripping pass changes the math. You write a rule for what gets removed on the way out: names, dates, financials, internal commentary, internal wikilinks, internal frontmatter. The agent runs it on every write. If the note cannot be cleanly stripped without gutting it, the agent refuses and flags it for a deliberate authoring pass instead.
Now you can write in your central brain with all the internal context you want, and the system handles the cut on the way out. The note exists once. It propagates downstream automatically. Nothing leaks.
Why this is worth the time
A reasonable question: why spend a week building this when I could just keep copying notes by hand?
Because filing is leverage, the same way templates and snippets are leverage. The hour you spend writing a sync rule is repaid every time the rule fires. If you write four notes a day across two brands, the system pays itself back in a couple of weeks and then keeps paying for as long as you run the setup.
There is a second-order benefit too. When the filing is codified, adding a new brand is an afternoon of work, not a quarter. A config row, an entry-point note, a dry-run mirror, done. Every brand you launch from then on plugs into the same system. Your operating overhead does not scale with the number of brains you run.
And there is a third-order benefit, which is the one that actually matters: when the filing happens by itself, you stop thinking about it. Your attention goes back to the work. The number of decisions you make in a day drops. The quality of the decisions you do make goes up.
What to build first
If you run one brand and you are reading this, you do not need any of it yet.
If you run two and you are starting to feel the drift between them, build the central brain plus one satellite first. Pick Pattern A or B. Write the contract. Live with it for two weeks. Iterate.
If you already run three or more brains and you are doing the filing by hand, the order is:
- Pick the central brain. The one you actually live in. It wins every disagreement from now on.
- Write the operating contract at its root. Even a draft is enough to start.
- Register the satellites. One row each. Pick a pattern per satellite. Pick the strictest pattern that fits.
- Wire up a coding agent. Point it at the contract. Run a dry-run mirror on one note. Verify both destinations look right.
- Turn the default on. Live with it. Notice the friction. Update the rules in the contract, not in your head.
The system gets sharper every time you push back on its behaviour. The contract is a living document.
A closing thought
Most operators treat their notes infrastructure as a sunk cost. Something they set up once and never touch. That works fine when you have one brain to manage. It stops working the moment you have two.
The operators I respect most have spent real, deliberate time on their filing systems. They treat the system the way a craftsperson treats their bench. They keep it sharp because everything else they make depends on it.
This is not productivity theatre. It is the operating layer underneath the work. If you are running multiple brands as a solo operator with AI as your force multiplier, the filing layer is one of the highest-leverage things you can invest in this year.
Spend the week. Build the system. Then go do the work.
FAQ
What if I only have one brand? You do not need this system yet. What you do need is a vault and a coding agent that knows how to use it. See the addendum below.
Does this only work with Obsidian? The pattern works anywhere notes are plain text files in folders the agent can read and write. Obsidian is just a nice editor on top of that. Logseq, plain markdown in a code editor, or a folder of .md files on iCloud all work the same way. The contract file is the system.
What about images, attachments, and binaries? Same rules. The agent copies them into the satellite if the note that references them is mirrored. Stripping does not touch the binary itself, but if an image embeds sensitive context (a screenshot of a CRM, a deck slide with revenue) the note that references it gets the stripping treatment and the image is dropped from the mirror.
What if the satellite is a git repo with branches and PR review? Then the agent writes to a working branch and opens a PR for you to review. Pattern C plus PR review is the right default when the destination has its own publishing pipeline. You still get the leverage; you also still get a human gate before anything ships.
How do I stop the same note drifting in two places? The central brain wins, always. If you edit a satellite copy by hand, the next mirror overwrites it. The rule has to be uncompromising or the system rots. If a satellite genuinely needs to be the source of truth for a specific note, that note moves out of the auto-mirror scope and gets a "satellite only" tag.
How long does setup actually take? A working day for one satellite. A week to feel comfortable with the strip rules and override commands. After that, every new brand is an afternoon.
What if the coding agent gets it wrong? Update the contract file. The agent is following written rules. If the rules produced the wrong behaviour, the rules need a line added. This is the same way you would fix any other piece of infrastructure that misbehaves.
Is this a CRM? A content calendar? A project tracker? No. It is the layer underneath all of those. You can absolutely run a CRM, a content calendar, or a project tracker inside the system, and many people do, but the multi-brain pattern itself is content-agnostic. It is about where notes live, not what notes contain.
What about backups? The central brain should be in version control (git, even privately on GitHub). Every satellite that matters should be in version control. You are now treating your notes like code, because the system is code-adjacent. Backups are a side-effect of that.
Addendum: not running multi-brand yet?
If you are reading this and the multi-brain piece is overkill because you have one operating surface and one brand, the upstream investment is still worth making. Get the central brain right first.
Drop vault-seed-CLAUDE.md into a fresh Obsidian vault as CLAUDE.md, open a coding agent in the directory, and let it interview you. You walk away with a working vault, a self note, an inbox, today's journal entry, and a working AGENTS.md calibrated to what you actually do.
When you eventually add a second brand, come back to this post and graduate to the multi-brain pattern. The two files are designed to stack.
Companion files
- The visual map:
Multi-Brain Management System.canvas - A public
AGENTS.mdtemplate based on the one I actually run:AGENTS.example - The agent-facing implementation seed:
Multi-Brain Implementation Seed - The single-vault bootstrap seed for people getting started:
vault-seed-CLAUDE
If you want to see the specific version of this system I run across my own brands, the working reference is Multi-Vault Parallel Filing System.