Your AI Coding Assistant Should Not Own Your Repository's Memory DoozieSoftware has released DoozCTL, an open-source repository standards engine designed to persist project knowledge as deterministic artifacts in the repository, rather than relying on AI coding assistants to rediscover context in each session. The tool converts architecture, conventions, and current context into files like AGENTS.md and .ai/current-context.md, which any AI agent can read, making the repository the memory layer and AI the execution layer. AI coding tools have become extremely capable. Claude Code can understand a large codebase. Codex can execute multi-step engineering tasks. Gemini CLI can navigate repositories and implement features. Cursor, OpenCode, and the next generation of coding agents are increasingly capable of operating like autonomous engineers. But there is still a fundamental problem: AI coding tools lose context. Your repository shouldn't. That is the problem we are trying to solve with DoozCTL . GitHub: https://github.com/DoozieSoftware/doozctl https://github.com/DoozieSoftware/doozctl Most AI coding workflows implicitly make the assistant responsible for understanding the project. You open Claude Code. It explores the repository. It discovers the framework. It reads some documentation. It learns conventions. It figures out architecture. It understands what you are currently building. Then the session ends. Tomorrow you open Codex. The discovery process starts again. Then you try Gemini CLI. Again: Repository ↓ Explore ↓ Infer architecture ↓ Discover conventions ↓ Understand current work ↓ Start coding We are repeatedly asking increasingly expensive AI systems to rediscover information the repository already knows. That model does not scale particularly well. The underlying assumption is wrong. The AI assistant should not own repository knowledge. The repository should. DoozCTL starts from a simple idea: Persist the minimum knowledge required for the next engineer or AI agent to continue successfully. Instead of leaving architecture, conventions, decisions, current context, and engineering workflows trapped inside an AI session, DoozCTL converts them into deterministic repository artifacts. A typical repository can contain: .ai/ current-context.md repository-analysis.json sessions/ Now project memory lives beside the code. Claude Code can read it. Codex can read it. Gemini CLI can read it. Cursor can read it. OpenCode can read it. A future coding agent that does not exist yet can read it. There is no proprietary memory API involved. There is no requirement for every tool to support the same MCP server. The repository becomes the memory layer. The AI becomes the execution layer. This distinction is important. Generating an AGENTS.md file would be useful, but it would be solving the surface-level problem. DoozCTL has no hardcoded knowledge of AGENTS.md . In fact, the engine does not need to understand: Those concerns live outside the engine. DoozCTL itself is essentially a deterministic Repository Standards Engine . Its pipeline looks like this: Repository ↓ Analyze ↓ Load Standards ↓ Resolve Variables ↓ Render Artifacts ↓ Merge ↓ Validate ↓ Persist The engine performs the mechanism. A Standards Package defines the policy. That separation is deliberate. DoozCTL can be thought of as three pieces. The open-source engine. It is responsible for things such as: analyze render merge sync validate persist It deliberately contains very little domain knowledge. Standards Packages define what a repository should contain. For example: @dooziesoft/standards @dooziesoft/standards-laravel @dooziesoft/standards-react A package might declare artifacts such as: AGENTS.md .ai/current-context.md .ai/sessions/ engineering workflows repository policies The engine simply renders whatever the package declares. A package is intentionally boring. It is just a directory containing a manifest and artifacts: standards/ package.json artifacts/ schemas/ No plugin runtime. No embedded code execution. No custom DSL. No complicated inheritance system. That simplicity gives us something particularly important for AI engineering: determinism. The third layer is the repository itself. For example: .ai/ current-context.md repository-analysis.json sessions/ This becomes portable AI memory. The key word is portable . The memory does not belong to Claude. It does not belong to OpenAI. It does not belong to Google. It does not belong to Cursor. It belongs to the repository. MCP servers are useful. External memory systems are useful. Vector databases are useful. But they solve a somewhat different problem. External memory typically means knowledge lives here: AI tool ↓ MCP / service ↓ database DoozCTL deliberately moves durable engineering knowledge in the opposite direction: Repository ↓ .ai/ ↓ Any AI assistant There are several practical consequences. Changes to engineering context can evolve with the repository. There is no hidden state. Repository knowledge becomes machine-addressable. DoozCTL has no cloud dependency. Switching assistants no longer requires rebuilding project context from scratch. This does not mean MCP becomes unnecessary. A useful architecture may eventually look like: Repository Memory + Organizational Knowledge + Runtime Tool Access ↓ AI Agent DoozCTL focuses specifically on the first layer. AI infrastructure often looks excellent in a greenfield demo and becomes painful inside a ten-year-old repository. We designed DoozCTL around the opposite assumption: the repository already exists and humans have edited it. Therefore generated content should not casually overwrite developer content. DoozCTL supports explicit merge strategies: overwrite append replace-generated managed-blocks managed-blocks is particularly useful for developer-facing files. For example: php < -- DOOZCTL:BEGIN:v1 repository-rules -- Generated repository rules live here. < -- DOOZCTL:END:v1 repository-rules -- Developers can maintain their own content outside the managed region. When standards change: doozctl sync . DoozCTL updates what it owns while preserving what it does not. There is another important safety property: overwrite does not mean "destroy whatever happens to be at this path." If a file existed before DoozCTL owned it, the engine refuses the first overwrite rather than assuming ownership. That is boring behavior. For repository tooling, boring behavior is usually good behavior. AI development tooling is increasingly probabilistic. The infrastructure surrounding it does not need to be. Given identical repository analysis, standards, and input artifacts, DoozCTL aims to produce identical output. For example: doozctl sync