Your AI Coding Assistant Should Not Own Your Repository's Memory

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

The Context Problem Is Actually an Ownership Problem

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.

Repository as Memory

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.

DoozCTL Is Not an AGENTS.md Generator

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:

• AI vendors
• programming languages
• frameworks
• company conventions
• artifact filenames

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.

Engine vs Standards

DoozCTL can be thought of as three pieces.

1. DoozCTL

The open-source engine.

It is responsible for things such as:

analyze
render
merge
sync
validate
persist

It deliberately contains very little domain knowledge.

2. Standards Packages

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.

3. Repository Memory

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.

Why Not Just Use an MCP Memory Server?

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.

1. Git versions the memory

Changes to engineering context can evolve with the repository.

2. Developers can inspect it

There is no hidden state.

3. CI can validate it

Repository knowledge becomes machine-addressable.

4. It works offline

DoozCTL has no cloud dependency.

5. AI vendors become replaceable

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.

Brownfield First

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:

<!-- 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.

Deterministic Instead of Magical

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 <repo> <package>

uses persisted repository analysis.

It does not silently re-analyze the project and change generated artifacts because some heuristic changed.

This matters more as coding agents become autonomous.

The agent may be probabilistic.

The governance layer around the agent should not be.

Repository Memory Without Repository Bloat

There is another failure mode worth avoiding.

If "repository memory" simply means saving every agent transcript forever, .ai/ eventually becomes a garbage dump.

That defeats the purpose.

DoozCTL instead treats session memory as compressed engineering state.

The goal is not:

Remember everything the agent said.

The goal is:

Remember what the next engineer needs.

That might include:

• important architectural decisions
• active constraints
• implementation state
• unresolved issues
• relevant discoveries
• decisions made during the session

Not the entire conversation.

This gives us a useful distinction:

conversation history is not project memory.

From Memory to an Engineering Control Plane

DoozCTL 2.0 extends the idea beyond static context.

The CLI currently exposes:

doozctl init
doozctl sync
doozctl analyze
doozctl summarize
doozctl doctor
doozctl status
doozctl plan
doozctl verify

The newer plan, status, and verify commands start turning repository knowledge into a lightweight engineering control plane.

A repository can adopt workflows under:

.dooz/workflows/adopted/
.dooz/workflows/project/

Engineering Plans live under:

.dooz/plans/

A workflow can declare evidence that should exist before work is considered complete.

verify checks whether that evidence exists.

Importantly, DoozCTL does not pretend to know whether the evidence is good.

It checks presence, not quality.

It does not execute tests.

It does not impersonate the engineer.

That boundary is deliberate.

The repository defines required evidence.

Tools produce the evidence.

DoozCTL verifies that the contract has been satisfied structurally.

Why This Matters More in an Agentic World

When one developer uses one coding assistant occasionally, context loss is irritating.

When multiple autonomous agents work on the same repository, it becomes an architectural problem.

Imagine:

Human
  ↓
Planning Agent
  ↓
Implementation Agent
  ↓
Testing Agent
  ↓
Review Agent
  ↓
Another model tomorrow

Without shared repository knowledge, each agent independently reconstructs the state of the project.

That creates:

• duplicated exploration
• inconsistent assumptions
• architectural drift
• contradictory conventions
• token waste
• onboarding latency
• vendor lock-in

Instead:

                 ┌─ Claude Code
                 │
Repository Memory├─ Codex
       │         │
       │         ├─ Gemini CLI
       │         │
       │         ├─ Cursor
       │         │
       └─────────└─ Future Agents

Every execution engine starts from the same durable substrate.

That is the larger idea behind DoozCTL.

Quick Start

Install:

npm install -g @dooziesoft/doozctl

Initialize a repository against a Standards Package:

doozctl init . ./standards

DoozCTL analyzes the repository, renders the artifacts declared by the package, safely merges them into the existing repository, and persists its engine state.

You can then inspect repository health:

doozctl status .

Update managed artifacts:

doozctl sync . ./standards

Capture durable context after an engineering session:

doozctl summarize . ./standards session-name

And validate the repository:

doozctl doctor . ./standards

Current State

DoozCTL 2.0 was released on September 2, 2026.

The repository currently reports:

484 tests
96.21% statement coverage
93.38% branch coverage

All eight primary workflows are implemented:

init
sync
analyze
summarize
doctor
status
plan
verify

The project is MIT licensed.

The Larger Bet

The AI coding ecosystem is currently competing primarily on models and agents.

Claude Code.

Codex.

Gemini CLI.

Cursor.

OpenCode.

And whatever ships next month.

That competition is good.

But engineering organizations should probably avoid making any one of those systems the canonical owner of repository knowledge.

Models will change.

Agents will change.

Harnesses will change.

The repository will remain.

So our design principle is intentionally simple:

The repository remembers. The AI is interchangeable.

That is what we are building with DoozCTL.

GitHub:

https://github.com/DoozieSoftware/doozctl

If you are experimenting with multi-agent coding, repository-level AI standards, AGENTS.md, persistent coding-agent memory, or vendor-neutral AI development workflows, I would particularly like feedback on the model.