Own Your Memory: Sovereignty for the AI-Run Company

AI agents can now do all of the computer work in a company. I don’t write code any more, and I described what my job became in I Don’t Write Code Any More. The agents write the code, review it, ship it, file the issues and draft the research.

That changes what a company is. If any capable model can do the work, the work is not what makes your company yours. What makes it yours is the context the agents work from: the code, the product and sales docs, the decisions, the research and the history of why each thing is the way it is. A company run by AI agents effectively is its memory.

So here is my thesis. That memory must live somewhere you control. Not in one provider’s memory feature, not in a chat history, not in a proprietary workspace. In a repository you own. Then no AI provider can hold your company hostage. A ban, a price change or a policy change can cost you a vendor. It can never cost you your business.

Why a provider can destroy you

Platforms change the terms on businesses built on top of them. This is not hypothetical, and it is not a moral failing of any one company. It is what platforms do.

• On January 12, 2023, Twitter suspended access for third-party clients. Tapbots shut down Tweetbot after more than ten years of work (Tapbots). Iconfactory discontinued Twitterrific, which it had built since 2007, blaming an “unannounced and undocumented policy change” (Iconfactory).
• In June 2023, Christian Selig announced that Apollo would shut down on June 30, which its site attributes to “drastic and sudden increases” in Reddit’s API pricing (Apollo, TechCrunch).
• AI providers are platforms too. On June 3, 2025, Windsurf said Anthropic had cut nearly all of its first-party capacity to the Claude 3.x models with less than a week of notice; users could still bring their own key (Windsurf). On August 1, 2025, Wired reported that Anthropic had revoked OpenAI’s access to Claude, saying OpenAI’s use broke its terms of service, while keeping access for benchmarking and safety evaluations (Wired, TechCrunch).

I am not saying any of these decisions was wrong. Each company had its reasons. The point is that access to any one provider can change on short notice, for any reason, including good ones.

If what you lose in that moment is a model, you switch models. If what you lose is your company’s memory, you lose the company.

What “memory” includes

When I say memory, I mean everything an agent needs to do the work as well as you would:

• Code, with its tests and the tools that build and ship it.
• Instructions: the rules every agent follows, and the procedure for each role.
• Product, sales and business docs: specs, brand guides, pricing, positioning.
• Decisions and research: what you chose, what you rejected and why.
• History: every change, who made it and the discussion that led to it.

Most of this is not code. A brand guide is memory. A list of job leads is memory. A rule like “always deploy from the main branch” is memory, and it is exactly the kind of thing that ends up somewhere it shouldn’t.

How we do it

Every Astrohacker project keeps its memory in git, in the same layers:

1. AGENTS.md at the root is the entry point. It holds the hard rules and the roles, and points to everything else. Every harness reads it. On this site a test keeps it under 10,000 characters so no harness ever truncates it.
2. Skills, one per role, under .agents/skills/: issues, code, review, deploy, and project-specific roles. This site also has a finance role and a jobs role.
3. Docs: research reports, design notes, decisions, reviews, journals and meeting notes. The research behind this post is a file in the repo.
4. Code, including the repository’s own management tool.
5. Git history, which records every change.
6. Issues and pull requests, which record why: the request, the discussion, the review findings and the verdict.

The non-code memory sits right beside the code. This site’s repository holds my job search records and CVs, my personal and company finance records, and the brand and image style guide that every cover image follows, with the prompt for each cover committed next to the image.

For scale, across five repositories (this site, Astrohacker, Botpenny, EarthBucks and a health company) that’s roughly 42,000 commits, including recovered history, 27 role skills and about 420 issues and 710 pull requests.

Because all of it is plain files in git, the harness doesn’t matter. Claude, Codex and Grok all work in these repositories from the same AGENTS.md and the same skills. I described how that works in Building Multi-Harness Multi-Agent Swarms. Any one of them can be dropped or replaced tomorrow, and the work continues.

The quiet lock-in

This morning I caught one in my own company. Our Claude issues agent had been saving standing rules in Claude Code’s built-in memory, a per-user folder outside the repository. It was doing what the feature is designed to do, and the feature is reasonable. But Codex and Grok couldn’t read those rules, other Claude sessions only partly did, and nobody reviewed or versioned them.

The rules weren’t trivia. They included the agent naming convention, that the deploy shift keeps polling until I end it, that deploys run from main, and how a blog post gets from idea to live in about 45 minutes. Real operating knowledge, sitting in one vendor’s store.

So I had those files deleted and filed issue #202: “Keep all agent memory in the repo”. Every rule moves into AGENTS.md or the right skill, through a reviewed pull request like any other change. And there is now a rule that no agent uses a harness’s proprietary memory feature.

Nobody did anything wrong here. That’s what makes it a lock-in worth watching for. Proprietary memory doesn’t arrive as a decision. It accumulates, one helpful note at a time, until the vendor knows things about your business that your repository doesn’t.

Others are saying the same thing

Garry Tan, who runs Y Combinator, open-sourced GBrain on April 5, 2026, under the MIT license. It is an agent memory system whose README promises “a memory you control”. Its design is the same idea: Markdown in a git repository is the system of record for what the agent knows, and the database is a search index rebuildable from it. Self-hosting is the default (Vectorize’s overview has a good summary).

The people writing about “context engineering” make the business case. Anthropic defines it as curating the right set of tokens for a model at inference time (Anthropic). Atlan goes further: when every company has the same foundation models, the model stops being the differentiator, and context becomes the moat (Atlan).

I agree, and I’d add one word: if context is your moat, you’d better own the land it sits on.

Botpenny, the company I’m building, made the case that your AI’s memory is your company’s intellectual property in Your AI’s Memory Is Your Company. Own It. This post is the other half: ownership is what gives you sovereignty, and sovereignty is what keeps you free to switch models.

How to start

You don’t need anything I’ve built. You need a repository and a few habits.

1. Put everything in one git repository you control, with a backup outside the host.
2. Write an AGENTS.md. Keep it short enough that every harness reads all of it. Put the rules there and point to the rest.
3. Write a skill per role, so any agent can pick up any job.
4. Move your docs in: product, sales, brand, decisions, research. Plain Markdown.
5. Record why in issues and pull requests, not in chat threads.
6. Turn off or ignore proprietary memory. If an agent learns a rule, it goes in the repository through a reviewed change.
7. Use at least two harnesses. If your second model can’t do the work from the repository alone, you’ve found the memory you don’t own yet.

Models will keep getting better, cheaper and more interchangeable. That is good news, but only if you can switch. Own your memory, and you always can.