How devtwin compares
There are three common places to keep context for a coding agent. They solve different problems, and most people end up using more than one.
- Repository instruction files, such as
AGENTS.mdandCLAUDE.md, committed to the repository. - Built-in agent memory: the memory features of an agent product, kept by that product, either in its hosted service or in its own local folders.
- devtwin: private, source-linked records kept on your disk, outside both the repository and any one agent.
At a glance
Section titled “At a glance”| Repository instruction files | Built-in agent memory | devtwin | |
|---|---|---|---|
| Where it lives | In the repository, under version control | Wherever the product keeps it: its service or its own config folders | A private store on your disk, outside every repository and the kit |
| Who can see it | Everyone with access to the repository | You, within that product | You. Others only get a handoff packet you choose to send |
| How it reaches a session | The agent loads it automatically | The product loads it automatically | You or a bundled skill fetch a brief explicitly |
| How it is written | Edited by hand and reviewed like code | Often captured automatically by the product | Previewed and applied by you; agent writes are proposals you publish |
| Evidence and freshness | None built in; it says what it says | Depends on the product | Every record can cite sources, and briefs flag records whose source files changed |
| History | Git history | Depends on the product | Records are immutable; replacing one keeps the old one on disk |
| Across agents | Only agents that read that file name | Tied to one product | Claude Code and Codex through the same CLI |
| Separation between organizations | One repository at a time | Depends on the product | Explicit scopes, one per organization or client |
| Best for | Team conventions: how to build, test and contribute | Personal convenience inside one tool | Private, per-developer project knowledge you want to carry between sessions and agents |
“Depends on the product” is deliberate: agent products differ in what they store, where, and how you can review it. Check your agent’s own documentation.
Repository instruction files
Section titled “Repository instruction files”AGENTS.md, CLAUDE.md and similar files are the right place for anything the whole team should follow: build and test commands, code style, review rules. They are versioned with the code and loaded automatically, which is hard to beat.
They are a poor fit for context that is private to you or to one client engagement, because everything in them is shared with everyone who can read the repository. They also have no built-in notion of where a statement came from or whether it is still true.
devtwin does not replace them. Onboarding reads AGENTS.md and CLAUDE.md when they exist and records that the repository’s own instructions govern. When a stored record and a repository instruction disagree, the repository wins. devtwin never writes to these files.
Built-in agent memory
Section titled “Built-in agent memory”Many agent products can remember things between sessions. That is convenient: there is nothing to set up, and the product decides what to keep.
The trade-offs follow from the same design. The memory belongs to one product, so switching agents means starting again. What gets remembered, and why, is up to the product rather than a step you review. And if you work for several organizations, keeping their context apart depends on how that product separates it.
devtwin takes the opposite approach: nothing is remembered unless you, or an agent you approve, record it, and every write is a preview you apply. The cost is that it is explicit. Someone has to run the CLI, and a brief reaches the session only when you or a skill fetch it.
devtwin
Section titled “devtwin”devtwin is built for one developer carrying private knowledge across sessions, agents and organizations:
- Context is private by default and lives outside the repository, so it can’t be committed or pushed by accident.
- Records are immutable, cite their sources, and carry a freshness label in every brief.
- Scopes keep one client’s context out of another client’s brief.
- The same brief works for Claude Code and Codex.
What it does not do: it does not capture anything automatically, does not verify that a record is true, and does not back up or sync your store. See Limitations.
Using them together
Section titled “Using them together”A setup that works well:
- Keep team conventions in
AGENTS.mdorCLAUDE.md, in the repository. - Keep your private decisions, open questions and handoff notes in devtwin.
- Let your agent’s built-in memory handle personal habits inside that one tool, if you like it.
At the start of a session, the agent reads the repository’s instructions as usual, and you give it the devtwin brief for the project. Repository instructions and you still have the final say.