Weekly email and new playbooks for established founders SUBSCRIBE

← The Schramko Playbooks

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.

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. Subscribe to Obsidian Sync if you want a fast device-to-device sync layer alongside GitHub. Works in parallel without conflict.

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 of every file. 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 forces a compaction. When the context window compaction banner appears, that is the signal to close. The session has run too long. Commit, push, archive the session window, start a new one. Memory and session logs are the mechanism that makes this seamless. If you do not have them, compaction is a hard stop. If you do, it is a routine handover.

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. Do not keep working in it past the compaction signal.

Work on one branch only. If you use version control, commit and push to your main branch directly. Feature branches create merge conflicts when you are working across multiple devices as the only operator. There is no team to review branches. They add friction with no benefit.

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. The rules apply at output time, mechanically. Drift drops to near zero. The voice you teach the system once stays applied across every output forever.

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.

End of playbook.

The playbooks show you how the system works. Mentor is where I look at your business, tell you what to do next, and adjust it with you every week.

Discover Mentor