Developer moves AI agent context from chats into the repository with doubled-graph

When you switch from Claude Code to Codex or another tool, the first thought is how to transfer the chat history. The author of an analysis published on Habr argues that this is the wrong question. For six months, he has kept project context not in conversations but in the repository, and says switching agents is no longer painful.

Why chat history is poor memory

A conversation preserves discussion about a project, not the final decisions. It contains noise, repetition, abandoned ideas, and polite "OK" messages. A new agent has to read and reinterpret all of it, with no way to verify that interpretation: the chat has no contracts, module boundaries, or acceptance criteria that can be checked against the code.

There is another drawback. Reconstructing context becomes a tax on every new session. Every time the tool changes, the knowledge has to be assembled again, and someone must determine which of the conflicting messages was the final one.

The author proposes a simple portability test. Open the repository in an agent that has never seen the project and give it a single prompt: "Read what is here and explain how the project is structured and what is happening in it right now." If the answer is accurate, the context truly lives in the repository.

What lives in the repository

The foundation is the GRACE methodology by osovv, released under the MIT license: intent, module boundaries, and checks are stored alongside the code. The author added three elements: a migration workflow for existing code, a call graph through CodeGraphContext, and an MCP wrapper. Together, they form the doubled-graph utility.

The code is annotated with paired comment anchors. A module has a MODULE_CONTRACT describing its purpose, scope, and dependencies; a function has a CONTRACT covering inputs, outputs, and side effects; and logic is divided into blocks. The LINKS field connects a file to a module, so a regular grep for an identifier such as M-AUTH-VALIDATE gives the agent a couple of relevant paragraphs instead of 40 files. A linter verifies that anchors are paired and unique and that they match the actual exports.

There are two graphs. Declared describes the intent and is stored in .grace/graph/. Computed is built from the AST and shows the facts: who calls whom. The detect_changes tool compares them and finds discrepancies: code without a module, a module without code, stale dependencies, a module without checks, or a file without annotations. A post-commit hook updates the computed graph, while detect_changes can run in pre-commit or CI. Before making an edit, the agent also asks what the change will affect.

Migrating old projects

"Specification first, code second" approaches usually fail on a decade-old project where no specification exists but the code works. That is why there are two modes. In migration mode, the code is the source of truth: the agent reconstructs intent, annotates files, and passes human-approval gates. In post_migration mode, the artifacts are the source of truth, and any discrepancy is suspicious. There are then three options: update the artifact through a change bundle, roll the code back to match the contract, or record the issue in DRIFT.md and block the module.

A separate idea is belief-state tracking. At critical points, the agent logs the non-obvious assumption it made, together with an anchor and session_id. When a production log arrives months later, the AI's state at that point can be reconstructed.

Limitations and conclusion

The author is candid about the limitations: there are no numbers, he did not run a controlled experiment, and everything is based on subjective impressions. The methodology is also demanding: he argues that all ten principles must be adopted together and that partial implementation is not worth the effort. Anchor annotations add noise to the code, while approval gates slow down quick edits. For small projects, this may be excessive.

Still, the idea is worth considering even without the full methodology. If you work with several agents, put at least the module contracts, dependency graph, and checklist in the repository, and let CI catch discrepancies with the code. Testing the result is easy: give a fresh agent the same single prompt. To try it, run pipx install doubled-graph, then doubled-graph setup and use the starter prompt from the prompts directory.