AI Sovereign Setup
Set up your AI so you own the context and are not locked to one vendor.
By James Schramko · Updated June 2026
I used to run my entire operation inside one AI platform. A custom project for each client. A master prompt I would paste into every chat. Months of context built up inside the vendor's database.
Then I asked a simple question. What happens if the vendor changes pricing, policy, or product tomorrow.
The answer was: I would rebuild from scratch.
This playbook walks you through setting up an AI system that lives on your own hardware, syncs across your devices, and works with any capable AI model on the market. If the vendor disappears, your work continues.
Who This Is For
You run a business where AI is part of your daily work.
You are comfortable following technical setup steps.
You want control over your systems, not convenience.
Who This Is Not For
You want a plug-and-play solution.
You do not want to manage files or version control.
You prefer simplicity over control.
If you fall into the second group, the simplified path at the end of this playbook is the place to start.
Why This Matters
When your business context lives inside a platform, you are building on rented land. The platform decides pricing. The platform decides feature changes. The platform decides what happens to your data if it shuts down.
When your context lives in plain files you own, on hardware you control, you decide. You can change AI tools. You can change models. You can change your stack. The files do not move. Your leverage compounds instead of eroding.
What You Need
A note-taking app that uses plain markdown files. Obsidian is the standard. Free for personal use.
A code repository for backup and version history. GitHub. Free for private repos.
A sync method. Obsidian Sync handles phone, tablet, and computer sync without setup. Optional but useful.
An AI tool with file access. Claude Code, ChatGPT desktop with file access, or any equivalent.
Buy the AI subscription on the provider's own website, never through the App Store on your phone. Apple adds its cut to any subscription bought inside an app, and the markup grows with the plan tier. One Mentor client paid about a quarter more for the same plan through her phone than she would have direct. If you already subscribed through Apple, cancel it and re-subscribe on the website.
A computer you control. Not a tablet, not a phone, for the initial setup.
An understanding of model tiers. Not all tasks need the same model. Light file work and formatting use the smallest capable model. Content drafting and reasoning use a mid-tier model. Strategy and architecture use the top model. Matching the model to the task preserves your token budget for work that actually needs it.
The Architecture in Plain Language
Plain markdown files on your hardware are the source of truth. Every standard, every client note, every decision, every reference document. Plain text. Editable in any tool.
The repository is the backup and version history. Every change is tracked. You can roll back to any point in time. If your computer dies, you clone the repo and pick up where you left off.
The AI tool reads from the files when you start a session. You point it at the folder. It loads what it needs. The AI is the interface. Your thinking lives in the files.
How Sync Works: Push Up, Pull Down
This is the part that trips people up, so it is worth slowing down on.
GitHub is the single source of truth. The vault on your computer is a local copy of it. Every other device you work on is also a local copy.
Push up means sending your local changes to GitHub. You do it after you make changes. It backs up your work and updates the source of truth so every other device can get the latest.
Pull down means bringing the latest from GitHub onto the computer you are about to use. You do it before you start. It catches your local copy up to anything that changed since you last worked there.
The question that comes up is why you would ever pull down. The answer is that you do not only work on one computer. When you work in the cloud through an AI tool that runs against the repository directly, or on a second device, those changes land in GitHub first. Your main computer is now behind. If you start editing without pulling, you are working on a stale copy, and when you push you get a conflict.
So the rhythm is simple. Pull down before you start. Push up when you finish. Down to catch up. Up to back up. The Git plugin can run this on a timer, but understanding the direction is what keeps you out of trouble.
If you only ever work on one machine and never touch the cloud, you still push up to back up. You just rarely have anything to pull down. The moment you add a second device or any cloud work, pulling down first is what stops the two copies from fighting.
Folder Structure to Start With
Reference. The standards, processes, and methods you operate by. How you make decisions, how you write, how you run a project.
Clients. One folder per client, if you serve clients. Each folder holds the context the AI needs to write to or about that client.
Sessions. Notes from meetings, calls, and work sessions. One file per session, dated.
Memory. A single file holding your current state. What is in flight, what is pending, what was decided recently. The first thing the AI reads each session.
Content. Drafts, scripts, and finished outputs. Whatever you produce.
Data. Performance metrics, observations, anything that informs future decisions.
You can adjust the names. The principle is what matters. Stable folders, stable file naming, plain markdown.
Setup Steps in Order
Step one. Install Obsidian on your main computer. Create a vault folder in a plain local location. Not iCloud Drive. Not Dropbox. A regular folder on the computer's hard drive.
Step two. Create a private GitHub repository. Open a terminal in your vault folder. Initialise git. Connect the local folder to the GitHub repository. Push the empty vault up.
Step three. In GitHub, create a personal access token with repo permissions. Save the token somewhere secure. You will need it for the sync plugin.
Step four. Install the Obsidian Git community plugin inside Obsidian. Configure it to pull from and push to GitHub every ten minutes. Use your username and the personal access token for authentication.
Step five. On any second device, clone the repository to a plain local folder and open that folder as a vault in Obsidian. Install Obsidian Git there too. Use the same token.
Step six. Optional. Obsidian Sync gives you fast device-to-device sync. I do not run it alongside git on the same vault: two automatic sync layers moving the same files can race each other, and I paused Obsidian Sync on my laptop after a near miss. If you want both, understand the overlap before you switch it on. GitHub is the layer a cloud session can read; a local session reads whatever files you authorise on the machine.
Step seven. Create your starter folders inside the vault. Write a single file in Memory called Memory.md. Add a few lines about your current state. Save. Watch the change land on your other devices within ten minutes.
Step eight. Open your AI tool of choice. Either give it access to your vault folder, or paste in the key files (Memory and any active reference documents) at the start of each session. Tell it how you want it to operate. From that point on, the AI reads from the vault every session.
Backup Discipline
Treat the vault as a production system. Do not edit half a thought and leave it. Do not delete files without understanding why.
If you run any automated backup script, make sure it pulls from the repository before pushing. Otherwise a deletion on one device can propagate and overwrite real work. Pull first. Then commit. Then push.
The repository preserves every version you commit. Anything uncommitted is unprotected, so commit often, and keep one backup that is not GitHub: mine is an hourly snapshot commit, a Time Machine drive and a weekly zip. You can recover from almost any mistake within minutes. Day-to-day discipline still matters.
What to Keep in the Vault
Everything that informs how you make decisions. The methods you operate by. Client context. Voice standards. Pending decisions. Past decisions and why you made them. Performance data that drives the next move.
What not to keep. Passwords. API keys. Anything sensitive that should not sit in a repository, even a private one.
Common Mistakes to Avoid
Storing the vault inside iCloud Drive. iCloud sync and git sync fight each other. Use a plain local folder.
Skipping the personal access token. Without it the git plugin fails silently or returns vague errors.
Editing on a second device without pulling first. When two devices push different versions of the same file, you get conflicts. Pull before you start editing on any device that has been offline.
Treating the AI as the place your thinking lives. The AI is a reader. Your thinking lives in the files.
Letting the session run until the AI compacts it. Most tools now summarise a long conversation and keep going, so compaction is not a hard stop, but a summary can lose detail that matters. My practice is to treat the compaction banner as the signal to close: write the session log, then commit and push, then start a new session. Memory and session logs are what make the handover clean. Without them you are trusting the summary.
Duplicating information across linked files. One file owns each piece of information. If a client file and a team member file both describe the same engagement, you have two sources of truth and the AI will eventually draw from the wrong one. The client file owns client information. Other files reference it, not copy it.
Closing a Session
This is where continuity gets lost. You keep working past the point where the session should have ended, or you close without preserving state, and the next session starts blind.
The close sequence is simple. Tell the AI: close this session, update any relevant files, commit and push. If your CLAUDE.md defines what close means, the AI handles the rest. If it does not, you are doing it manually each time.
What to update at close: the active-state memory file if anything changed, and a session log capturing what happened and what is pending. The session log does not need to be long. Date, what was done, any open items. That is enough for the next session to pick up cleanly.
The push at close is also what makes the next session work from anywhere. It updates the source of truth, so when you sit down at another device, or the cloud picks up where you left off, a pull down brings the latest across. Close pushes up. Next session pulls down.
After committing and pushing, archive the session window. Most AI tools have an archive option. Use it. Do not delete the session. My rule is not to keep working in it past the compaction signal unless the task is minutes from done.
Work on one branch. If you use version control, commit and push to your main branch directly. As the only operator you have no team to review branches, and for me feature branches produced merge conflicts across devices rather than safety; isolated branches or worktrees earn their place when two sessions must change the same files at the same time, and that is rare for one person. One rule keeps a single branch safe once you run more than one session at a time (a laptop, a desktop, a cloud session): sync before you save. Fetch, fast-forward if you are behind, then commit only the files your session changed and push. If two lines of history have split, keep both (bookmark the one you are not on) and reconcile them by hand; never force-push and never discard a side you have not read.
The close sequence becomes fast with practice. Under two minutes. The continuity it creates is worth significantly more than the time it costs.
What This Gets You
Your operating context outlives any AI vendor. You can switch tools without rebuilding. Your team can read the same files you read. Version history shows how your thinking evolved. New devices clone in minutes and you are working again.
The cost is a focused setup session and ongoing discipline. The system is simple once running. It requires consistency to maintain. The payoff is leverage that compounds instead of erodes.
What Actually Shifts When You Move From Chat to Vault
This is the operational layer. The architecture above describes what to build. This describes what changes the day after.
Cross-session memory becomes real. In a chat-based setup the AI forgets between conversations. You re-explain who the client is, what was decided last week, what voice you use. In a vault-based setup the AI reads the client extract at the start of every session. Patterns logged three weeks ago surface in today's response. Decisions you made in March show up in May coaching. The vault remembers so you do not have to.
Voice consistency stops being interpretive. In chat the AI tries to match your voice from inference. It drifts. It uses your forbidden phrases. It leaks AI tells. In a vault setup voice rules live as files: hard stops, forbidden phrases, per-client constraints. A file on its own is a reminder the AI reads; enforcement is a check that runs on the output. My Claude Code setup uses a hook to check final replies for specified banned patterns and request a rewrite when it finds one. It has exceptions and cannot judge every voice rule. Drift drops hard with the files and further with the hook. It never reaches zero: the scanner catches what it can match, the rest is judgment, so the rules keep getting sharper.
Specific intel stops being approximated. Numbers, dates, deal terms, client preferences, prior commitments. In chat these blur over time because the AI is summarising from compressed memory. In vault they live in extract files. The reply quotes them exactly. "You handed Helen to Dan this morning" lands because the file says so.
Pattern recognition compounds. Every coaching call, decision, content piece, and outcome lands in a file. A pattern that surfaces three times across two months gets named and tracked. The next time the pattern shows up the AI catches it inside one sentence. This is not memory tricks. It is structured note-taking made readable by the AI.
Operator judgment becomes the moat, not the framework. The architecture is increasingly public. Folder, routing, interface, loops. Anyone can build the structure. What stays scarce is the operator running it. The judgment about which work to cut, which AIs to avoid, which signals matter. The vault holds and applies that judgment consistently. The framework is the floor. The operator is the ceiling.
You stop rebuilding context every session. You start building leverage every session.
How This Applies to High-Value Operator Work
If your business runs on sophisticated buyers, long sales cycles, multi-month engagements, or coaching relationships that compound, the vault model is structurally better than chat for three reasons.
First, sophisticated buyers do not tolerate voice drift. They notice when an email reads off-pattern. Vault enforcement holds the line.
Second, multi-month sales cycles compound on memory. A buyer who showed scope-creep behaviour in February is still that buyer in May. The vault flags the pattern. The chat forgets it.
Third, the patterns you need to spot are cross-engagement, not single-engagement. Same buyer behaviour shows up across deals six months apart. Vault-level memory catches it. Chat memory cannot.
Service businesses, mentor businesses, content businesses with long-running clients, and any work where what you said three months ago still matters today are the strongest fits.
Transactional businesses with short cycles get less compounding benefit. The vault still helps but the gap between chat and vault is smaller for them.
Naming the Stack
The brand-level name for an operator-grade vault system varies. Pick one or use the names that already exist in your space.
Operator OS, Knowledge System, AI Sovereign Setup, or your own brand name applied as the wrapper.
The internal engineering stays internal. The brand wrapper is the consumer-facing layer. Same logic any product business runs by. Internal: code, infrastructure, frameworks. External: the brand customers say out loud.
For Mentor clients running this playbook, the recommended split is a recognisable consumer-facing brand on the outside, plain framework names on the inside. The brand earns the conversation. The frameworks do the work.
If This Feels Too Heavy
Start with a simplified version. Use a single folder of plain markdown files on your computer without GitHub. Build the habit of storing your thinking outside the AI first. Write one Memory file. Add reference files as you need them. Point your AI tool at the folder or paste the files into each session.
Once that habit is running, add version control. Create the GitHub repository. Install the sync plugin. Move to the full playbook above.
You get most of the sovereignty benefit from step one. The rest is leverage on top.
The Starter Prompt
If you want the whole thing built in one go, including your existing Claude projects, this is the prompt I send people. Make a new empty folder on your computer, open Claude Code and point it at that folder, and paste in everything between the two lines below. If it says it cannot see Chrome, install the Claude in Chrome extension first and run it again.
You are setting up my business operating vault. This folder is the single source of truth for how my business runs and for everything you learn while working with me. Build it now.
Step one. Create this structure, all plain markdown files: CLAUDE.md at the root, MEMORY/Memory.md, PROJECTS/, SESSIONS/, REFERENCE/, CONTENT/, DATA/, and OPEN_QUESTIONS.md.
Step two. Write CLAUDE.md as your standing instructions. At the start of every session read MEMORY/Memory.md first, then the PROJECTS file for whatever we are working on. At the end of every session, or when I say close, write a session log to SESSIONS/YYYY-MM-DD-topic.md with what we did, what we decided and what is still open, then update MEMORY/Memory.md with only what changed. Keep Memory.md under 150 lines. Never invent a fact; if you are unsure, write the question in OPEN_QUESTIONS.md. Ask before deleting anything. Plain text, no filler.
Step three. Migrate my existing Claude projects. Use the Claude in Chrome extension to open claude.ai, go to Projects, and work through every project I have. For each one read the project instructions, every file in its project knowledge, and the recent conversations. Write PROJECTS/project-name.md with: what the project is for, the rules and preferences I gave it, what it worked out that worked, what went wrong or wasted time, and open tasks. Copy the knowledge files into REFERENCE/ where they are still useful. Route what you find by type, not by convenience: facts about a client go in that client's folder, voice rules go in the voice file, strategy goes in STRATEGY/, and only live state (what is open now, what is pending, what to watch) goes into MEMORY/Memory.md. Memory.md is a short cockpit read at the start of every session, capped at a page or two. If everything true about me lands there, the AI reads all of it every session and stops noticing what changed.
Step four. Run git init and commit the vault so I have version history on my own machine.
Step five. Show me the folder tree, a ten line summary of what you found, and the open questions. Then close the session properly per CLAUDE.md so I can watch the loop work once.
That is the whole prompt. The first session builds the folder, reads your projects into it and closes the loop once so you can see it work. Every session after that starts by reading the memory file and ends by updating it.
If you want this set up on your own business with guidance from someone who has already made the mistakes, I walk Mentor clients through exactly this build.
End of playbook.