Your AI Assistant Is Replaceable. Your Knowledge Is Not.
The durable part of an AI-assisted workflow is the information, working rules, and repeatable routines you own, not the assistant currently accessing them.
I use GitHub Copilot and Claude regularly. I expect both to change, and I expect better tools to appear.
That is why neither one sits at the center of how I work.
Your AI assistant is replaceable. Your knowledge is not.
The center is a repository: personal when it holds my own work, project-based when it supports a team or product. It contains knowledge, working rules, and automations that should remain owned and portable. The assistants are interfaces around it. They can help me search, reason, write, and execute, but they are replaceable.
For technical knowledge workers who already move between assistants, I think this is the more durable architecture. The strategic mistake is not choosing the wrong AI product. It is allowing any AI product to become the only place that understands how you work.
This is not an argument that everyone should become a developer or that Markdown is the best note-taking format. The repository matters because it separates durable working context from fast-changing tools.
Information Is Only the First Layer
Most personal knowledge systems focus on capture: notes, links, documents, and tasks. A repository can do that, but storage alone is not the interesting part.
Much of that information is portable plain text. Markdown provides headings, lists, tables, and links while remaining readable across editors and accessible to scripts and AI tools.
My personal repository contains publishing drafts, priorities, project records, ideas, todos, and recurring reflections. A project repository might contain product context, technical decisions, operating rules, and reusable workflows. These files are not one giant prompt, and no assistant sees everything at once. A tool reads the material relevant to the task, within the access and context it has been given.
The value is not magical total recall, but a coherent source tools can inspect selectively.
The Repository Defines How I Work
The second layer is instructions.
My repositories record more than what I know. They also record rules for how I want to operate. Some principles apply everywhere, such as limiting active side priorities or moving stale todos out of the active list. Other rules belong to a specific project: how ideas move toward a product decision, what a publishable article must contain, or how a particular workflow should be automated.
Publishing is one example. Its repository defines what a finished article requires, how it moves from idea to draft to publication, and where approval is mandatory. Those project rules can differ from the rules of another project, while the underlying principles remain visible and portable. The result is flexibility with structure, not one rigid system imposed on every kind of work.
These rules are versioned beside the work they govern. I can change them once, inspect their history, and let each compatible assistant apply them without surrendering ownership.
Repetition Becomes Infrastructure
The third layer is reusable execution.
My repository also supports recurring work. Automations can read the relevant priorities, todos, projects, and drafts, then produce a personalized briefing or prepare the next step in a workflow. The model and delivery mechanism can change; the source structure and the rules they read remain under my control.
This is what separates the idea from generic note-taking. Notes preserve information. An operating layer combines information, instructions, and repeatable routines.
The repository becomes the stable contract. GitHub Copilot, Claude, another model, a local script, or a future application can work against that contract. Switching tools may require adapters and different instructions, but it should not require rebuilding the underlying memory and operating model from zero.
Portability Has Boundaries
The strongest objection is practical: maintaining a repository has a cost. Git, folder conventions, and small automations are familiar to me after years of software work. For someone who wants effortless capture, real-time collaboration, or no system maintenance, a managed application may be the better trade.
Not everything belongs in Git or plain text, either.
Secrets should live in a credential manager or secret store, not in a repository. Sensitive personal, customer, or company information needs appropriate access controls, retention rules, and sometimes a different system entirely. Large binary files, collaborative spreadsheets, presentations, media, and regulated records often remain better in purpose-built storage.
Even a private Git repository is not a security strategy by itself. Version history can preserve a secret after it appears to be deleted, and connecting an AI tool creates another access decision.
The practical design is not “put your whole life in Markdown.” It is to keep a durable index, operating rules, and suitable working material in the repository, then link to protected or specialized systems where necessary. The pattern is most useful when the cost of rebuilding context across tools is already higher than the cost of maintaining the repository.
Start With the Layer, Not the Tool
The current AI market encourages us to choose an assistant and then move our work into its environment. I think that reverses the dependency.
Start with what should remain when the assistant changes: your information structure, decisions, working rules, and reusable automations. Keep those in formats and systems you can inspect, version, and move. Then let tools compete to provide the best interface to them.
Models will improve. Products will merge, disappear, or change their terms. Your way of working should not have to reset each time.
The durable asset is not the assistant that knows how to work with you today. It is the knowledge, context, and operating model that teach any authorized assistant how you work tomorrow.
If your current AI assistant disappeared next month, how much of your knowledge, working context, and operating model would remain usable?