Why 0dai

Every coding agent you run starts the same way: it reads whatever files happen to be open, guesses at conventions, and asks you to re-explain decisions you already made last week. The model is capable. The context is missing. 0dai is the project memory that fixes the second problem, so the first one can do its job.

The problem: agents start from zero

A coding agent has no memory of your project beyond its context window. Close the session and the window is gone. The next time you open Claude Code, Codex, or Gemini, the agent knows nothing about the auth refactor you debated, the library you rejected for a good reason, or the test that is flaky on purpose. You pay for that gap twice: once in the tokens spent re-reading the codebase, and again in the time you spend re-explaining what the code already told the last agent.

It gets worse when more than one agent is involved. Teams rarely standardize on a single tool. One developer prefers Claude Code for architecture, another runs Codex for fast edits, a third keeps Aider in the loop for test writing. Each tool reads a different config file in a different format. Claude Code reads .claude/. Codex reads .codex/. Gemini reads .gemini/. Aider reads .aider/. A decision written into one of them is invisible to the others. The project ends up with several partial, drifting copies of its own conventions, none of them the source of truth.

The symptoms are familiar. An agent re-introduces a pattern the team already removed. A second agent picks a different HTTP client than the one the codebase standardized on, because nobody told it which one won. A third agent confidently edits a file another agent is mid-refactor on, because there is no record that the work is in flight. None of these are model failures. They are memory failures. The fix is not a smarter model; it is a place to write things down that every agent reads.

The principle: one ai/ directory

0dai keeps a single ai/ directory in your repository. It is the source of truth for everything an agent needs to know that is not already in the code: project manifests, the decisions log, agent personas and the work each one owns, skills and playbooks, the delegation policy that routes tasks to the right model, and the session state that records what is happening right now.

From that one directory, 0dai sync generates the native config each tool expects. You edit ai/ once; the command writes .claude/, .codex/, .gemini/, .aider/, AGENTS.md, and .mcp.json so that every agent reads the same facts in the format it understands. There is no daemon, no broker, and no service to run. The memory is files in git, which means it is versioned, diffable, reviewable in a pull request, and gone the moment you delete the repo.

Three rules follow from keeping memory in the repo:

• Decisions stick. Architectural choices live in ai/docs/decisions.md. An agent reads them before it re-debates a question that was already settled. The next agent inherits the conclusion, not the argument.
• Mistakes stay flagged. Outcomes are recorded as structured experience. A pattern that failed once is visible to the agent that would otherwise try it again.
• Context travels. Active session state is a file, so one agent can hand a half-finished task to another agent — or to a human — without losing the plan, the files touched, or the reasoning.

The design constraint is deliberate: passive memory is dead memory. A file nobody reads changes nothing. So 0dai pairs the static layer with a retrieval interface — an MCP server that returns ranked, relevant rules and prior experience at the moment an agent is about to act, rather than hoping the agent scrolled past the right paragraph. The point is not to store more. It is to put the right fact in front of the agent at the moment of the decision.

The proof: context that survives a CLI switch

The clearest demonstration is session roaming. Start a task in one agent, save the session, and pick it up in a different agent — the goal, the plan, the files touched, the key decisions, and the free-text handoff note all transfer. The second agent does not re-read the world from scratch; it reads the handoff and continues.

# In Claude Code — save the active session
0dai session save --goal "implement auth" \
  --summary "designed API, need implementation"

# Switch to Codex or Gemini — the next agent sees:
# [ai-layer] ACTIVE SESSION DETECTED — pick up where the last agent left off:
#   Goal: implement auth
#   Status: in_progress
#   Roaming: claude -> codex (session handed off to you)
#   Handoff: designed API, need implementation

Nothing here is round-tripped through a server. The session is ai/sessions/active.json; completed work archives to ai/sessions/archive/. Because it is a file in the repo, the handoff works across machines and across tools, and it survives a laptop reboot. The full mechanism — what is captured, how the next agent detects it, and what the schema looks like — is in Session Roaming.

Roaming is the visible tip. The same property — context as files — is what lets several agents work the same repository without colliding, which is the subject of the multi-agent workflow: role allocation, the handoff protocol, swarm delegation, and how conflicts get resolved before they become merge pain.

The comparison: per-tool config vs a shared layer

You can run agents without 0dai. Most people start there: a hand-written CLAUDE.md, a separate AGENTS.md, maybe a .cursorrules file. That works for one tool and one person. It breaks at the second tool and the second person, because there is no single file that all of them agree to read.

0dai is not the only tool in this space. Editor-first agents like Cursor and CLI-first tools like Aider solve overlapping problems with different premises, and each is better than 0dai at some things. The honest head-to-heads are at 0dai vs Cursor and 0dai vs Aider; both concede where the other tool wins.

What adopting it looks like

The mechanics are small enough to describe in a paragraph. You install the CLI and run 0dai init in your project. It detects the stack — Next.js, FastAPI, Flutter, Go, and others — and writes the ai/ directory plus the per-tool configs: .claude/, .codex/, .gemini/, .aider/, an AGENTS.md, and an .mcp.json. From then on, the loop is: edit the source in ai/, run 0dai sync to regenerate the outputs, and commit the result like any other change.

npm install -g @0dai-dev/cli
cd your-project
0dai init      # detect stack, write ai/ + native configs
0dai sync      # regenerate outputs after editing ai/
0dai status    # maturity, active session, swarm state

Day to day, the layer mostly stays out of the way. You notice it at the seams: when a new agent picks up a task and already knows the conventions, when a decision you made last month stops an agent from re-proposing the thing you rejected, when you switch tools mid-task and nothing is lost. None of those moments are dramatic. The value is the absence of the re-explaining you used to do, which is exactly the kind of cost that is easy to stop noticing once it is gone.

Because everything is files, removal is symmetric with adoption: delete the directories and the layer is gone, with no service to deprovision and no data held anywhere but your repo. A memory layer you cannot cleanly remove is a memory layer you should not adopt; this one is just text in git.

Honest objections

A memory layer is not free, and a few objections are worth stating plainly rather than waiting for you to find them.

• It is another thing to maintain. True. The bet is that maintaining one ai/ directory is cheaper than maintaining four drifting config files and re-explaining the codebase on every session. If you only ever use one tool alone, that bet is weaker.
• Generated files can go stale. If you edit .claude/ directly instead of ai/, the next 0dai sync will overwrite it. The discipline is to edit the source, not the output — the same rule as any code-generation setup.
• The model still has to read it. A memory layer cannot force a model to use a fact. It can only put the fact in reach. That is why the retrieval interface ranks and surfaces rules instead of relying on a wall of text the agent might skim past.

If your work is one developer, one tool, one afternoon, you may not need any of this. The moment a second agent, a second person, or a second day enters the picture, the cost of starting from zero starts compounding — and a shared, versioned memory is the thing that stops it.

Next up

• Multi-agent workflow — roles, handoff protocol, swarm delegation, and conflict resolution.
• Session roaming — the architecture behind context that survives a CLI switch.

Related reading: Why AI agents need shared context, One config, five AI agents, and Config files compared. See what shipped on the changelog, or try a guided play such as adding OIDC auth to a Next.js app.