Business AI setup: 3 instruction layers instead of an Obsidian vault
Vault + iCloud + auto-git breeds duplicates and leaks. Replace it with policy, skills, and scoped project memory — plus a 15-minute migration map.
Discuss this post in AI
Send a pre-filled prompt to ChatGPT, Claude, Gemini, or Perplexity — get a summary, ask follow-ups, or compare ideas from this guide.
Teams often start “AI memory” with an Obsidian vault: hundreds of Markdown files, iCloud sync, auto-git every five minutes, and a 480-line CLAUDE.md that says “read five files at session start.” It looks like architecture. In practice you get duplicate conflict files, NDA material in a git remote, broken symlinks, and eight thousand tokens loaded before a two-line answer. Neuro OS replaces that pile with three instruction layers — each with an owner, a lifecycle, and a scope the runtime loads only when needed.
What teams build first
The pattern is familiar across founders, operators, and engineering leads who live in Claude, ChatGPT, or Cursor daily. Memory between sessions is non-negotiable — otherwise every chat re-explains who you are, which project is active, and which rules apply.
The “responsible” path looks like this:
- A vault with 500+ linked notes and tags.
- Git with auto-commit every few minutes (Obsidian Git or similar).
- iCloud or Dropbox so notes work on phone and laptop.
- A giant instructions file — CLAUDE.md, AGENTS.md, or “system prompt” — with role, principles, lessons learned, and “always read these five files on start.”
On paper it is a knowledge base. In operation it becomes five sync mechanisms fighting over one folder tree — and Claude paying full context price on every short question.
What breaks
Failures arrive one at a time. Each seems fixable. Together they mean the system is not production-ready — especially for a company.
Duplicate files from dual sync
Git and iCloud both decide which file version wins. When they disagree, you get conflict copies — dozens or hundreds over a quarter. Neither tool is wrong; they cannot share one write path.
Sensitive material in the wrong remote
Client folders dropped into the vault for “easy Claude access” get picked up by auto-commit and pushed to GitHub — private repo or not. Data left your boundary. NDA and security reviews treat that as an incident, not a settings tweak.
Symlinks and path drift
Pointing ~/.claude/CLAUDE.md at a vault file breaks when iCloud moves the folder. Obsidian still shows notes; Claude Code sees nothing — and you lose half an hour finding “where memory went.”
Context tax on every session
A 480-line instruction file plus “read five more files” can burn ~8,000 tokens before the first real task. Half of it is “just in case” history that never applies to the current message — but you still pay for it.
Company signal: when one person’s vault becomes the team’s hidden dependency, ownership, review, and rollback disappear. That is not memory — it is operational debt.
The insight: layers, not a warehouse
Products already split instructions by scope — if you use them deliberately instead of re-implementing storage in files.
- Personal Claude: General Instructions (all surfaces), Cowork settings (desktop automation),
CLAUDE.md(CLI only). - Company Neuro OS: operating policy in
neuro.yaml, reusable skills in git, project memory scoped per role.
The mistake is treating one folder as “everything Claude must know.” Layers complement each other; they should not duplicate. Load policy always, mount skills for the task, pull project memory only for that role’s namespace.
For corporate rollout on top of personal tools, read Corporate AI is a company asset — context is the foundation.
Three layers — what goes where
Most people need Layer 1 only. Add Layer 2 when repeatable procedures exist. Add Layer 3 when a role or project needs durable local facts — not full chat history.
| Layer | Personal Claude | Company Neuro OS | Who owns it |
|---|---|---|---|
| 1 — Policy / identity | Settings → General → Instructions for Claude | neuro.yaml: models, environments, Allow/Ask/Block, connector boundaries |
Security + ops; short and stable |
| 2 — Procedure | Cowork settings (if used) or role-specific project instructions | Skills in repo: inputs, steps, validation, escalation, earned examples | Role keeper + engineering review |
| 3 — Local memory | ~/.claude/CLAUDE.md for CLI; Claude Memory for chat-derived facts |
Project memory namespace: glossary, decisions, open risks, links to source records | Project owner; explicit writes only |
Do not copy the same paragraph into all three layers. Policy says what may happen. Skills say how work runs. Memory says what is currently true for this project — with owner and date.
How to migrate in one pass
You do not need another vault. You need a structured inventory and fifteen focused minutes per layer — then ongoing review like any other operational config.
-
1
Inventory the vault
List folders, note sync paths (git, iCloud, Dropbox), flag anything client-confidential or credential-bearing.
-
2
Extract Layer 1
Move stable rules into General Instructions or
neuro.yaml— models, tone, Ask on sends, blocked systems. Delete duplicates elsewhere. -
3
Promote procedures to skills
Repeatable workflows become versioned skills with tests — not 24 “lessons learned” paragraphs in one file.
-
4
Promote facts to scoped memory
Confirmed definitions, decisions, and metrics — one namespace per role. Never bulk-import chat transcripts.
-
5
Leave personal notes personal
Private thinking can stay in Obsidian — for you, not as a production dependency. Link to approved sources instead of dual-syncing into company git.
-
6
Rotate and verify
Rotate any credentials found during the pass. Run adversarial checks: cross-role memory bleed, blocked connectors, write without Ask.
What belongs in each layer
Layer 1 — always loaded
- Who the agent works for: org, role, data classes.
- Governance: external sends, CRM updates, payments, deletes → Ask or Block.
- Approved models and environments — not meeting notes or example libraries.
Layer 2 — mounted per task
- Inputs, steps, output schema, validation rules.
- Escalation when confidence is low or data is missing.
- Examples that earn their token cost — not “everything we ever tried.”
Layer 3 — scoped writes
- Current campaign hypothesis, qualified-lead definition, glossary.
- Decisions with owner, date, and link to source record.
- Explicit promotion from chat → memory via Ask; archive stale state.
A two-minute classification job should not load sales skills, legal caveats, and last quarter’s retrospective. Resolve role and task first; mount only what the run needs.
Vault vs three layers
| Memory vault | Three layers | |
|---|---|---|
| Storage | 500+ files, git + cloud sync, multiple paths | Policy file + skills in repo + scoped memory namespaces |
| When context loads | Start of session — if agent reads the right files | Policy always; skills and memory by role and task |
| Context cost | Often 5,000–8,000+ tokens upfront | Hundreds of tokens for policy; rest on demand |
| Leak risk | High — auto-git pushes folders you forgot | Lower — company repo with review, no accidental client sync |
| Ownership | Unclear — “whoever maintains the vault” | Named keepers per layer; changes via pull request |
| Setup time | Weeks of accumulation + ongoing conflict repair | One focused migration + monthly trim |
Five lessons from the vault trap
- Git + iCloud on one tree guarantees duplicates. Pick one system of record for company context.
- Any folder in the vault becomes publishable. Without explicit excludes, auto-commit is delayed upload.
- Symlinks to cloud paths break on first move. Prefer repo-relative paths the runtime controls.
- Long “just in case” instructions tax every session. Move history into skills loaded only when relevant.
- A warehouse you never open is not knowledge. If you do not review it, neither should production agents depend on it.
Monthly Layer 1 trim
- Remove finished projects and outdated goals
- Confirm Ask/Block rules still match how the team works
- Check no client-only paths remain in git remotes
- Re-run one adversarial memory-boundary test per role
What to do next
Today: open your vault or giant CLAUDE.md. Highlight what must be true in every chat — that is Layer 1. Everything repeatable becomes a skill candidate. Everything confirmed and project-specific goes to scoped memory. Everything else stays personal or gets deleted.
For a team: stop sharing one person’s sync folder. Stand up a company repo with policy, skills, and role namespaces in Neuro OS — then expand one role at a time.
What to remember
- Three layers: policy, procedure, project memory — different owners and lifecycles.
- Do not duplicate the same rules across layers or sync paths.
- Mount skills and memory per task; never preload the whole warehouse.
- Personal notes can stay personal; company context lives in reviewed git.
- Test memory boundaries like infrastructure — not like prompt trivia.
Should I delete Obsidian entirely?
No — if you actually use it for thinking, writing, and linked notes. Stop using it as Claude’s boot loader. Move “must know every session” facts into Layer 1; keep Obsidian as your human reference.
Does this work with ChatGPT or Gemini?
Same principle: separate stable instructions from task procedures from project facts. Button names and limits differ; the layer model does not.
What about Slack or Notion as team knowledge?
Those are for people. Agents see what you explicitly mount — settings, repo skills, scoped memory, or attachments. Do not dual-purpose a team wiki as silent agent boot context without governance.
How is Neuro OS different from Claude Team org instructions?
Org instructions are Layer 1 for chat. Neuro OS adds versioned skills, connector least privilege, per-role memory boundaries, sandboxes, Ask on writes, and an execution trail — what you need when agents act, not only answer.
Can I migrate without Neuro OS first?
Yes. Trim Layer 1 in your vendor settings, split procedures into separate files, stop “read five files on start.” Neuro OS is the company-grade next step when multiple roles, connectors, and audit matter.