One agent rereading docs is a cost problem. Several agents, or several teammates, do something worse: they re-derive the same answers in parallel and write what they learn into scattered files that quietly drift out of sync. The fix is one shared read/write path, so a thing learned once is canonical for everyone who reads it next.
tsukumo
Short version: one agent on one repo wastes tokens rereading docs. Several agents, or several teammates, do something worse: they re-derive the same answers in parallel and write what they learn into scattered files that quietly drift out of sync. The fix is not more docs or a bigger context window. It is one shared read/write path, so a thing learned once is canonical for everyone who reads it next. This post is about the write side of that, the part that only shows up once more than one agent touches the repo.
A single agent rereading docs is a cost problem. We did the token math on that in the token cost of agents rereading your docs. Add a second agent, or a teammate, and you get a consistency problem on top of it. Three things start happening:
Parallel re-derivation. Your agent works out the rollback steps on Monday. Your teammate's agent works out the same rollback steps on Tuesday, from scratch, because it has no idea the first one already did. You pay twice for one answer.
Drift. Each agent writes its findings into its own markdown, or a chat log, or a comment. Now there are three notes about rollback, written at three times, and nothing says which is current. The next reader guesses, and sometimes guesses wrong.
Lost knowledge. An agent figures out why the API returned 504s after a deploy, writes it into a session that ends, and the knowledge evaporates. The next incident re-runs the investigation.
None of this is fixed by a smarter agent or a larger window. It is a structural problem: there is no single place where "what we know" lives.
Why doesn't CLAUDE.md or a shared wiki solve this?#
They solve a slice and then stop.
A CLAUDE.md or AGENTS.md is a single hand-maintained file. It works until the knowledge outgrows one file, which is fast on a real project. It also assumes a human keeps it current, and agents generate knowledge faster than a person curates it, so it lags. A wiki or a docs folder is many files with no canonical signal: exactly the pile the single-agent post was about, now also being written to by several actors at once. More writers, more drift. We weighed those files honestly in do AGENTS.md and context files actually help.
What is missing in both is a write path with a notion of canonical: a place an agent can save a finding such that the save itself makes it the current answer, and the older note is marked superseded rather than left to compete.
The idea is small. Give every agent one place to read from and one place to write to, and make that place the source of truth by construction. Concretely, with trovex an agent can:
Write what it learns once. An incident, a decision, the rollback steps that actually worked, saved as a record through the shared write path. Not into a new loose file.
Read it back by meaning, at the section level. The next agent asks a question and gets that record as the canonical answer, with a freshness marker, not a list of candidate notes to compare.
Supersede instead of duplicate. A newer record on the same topic becomes canonical; the old one is marked, not deleted and not left to masquerade as current.
Because reads and writes go through one point, there are no copies to sync. The fleet and the humans see the same store.
Monday: agent A hits a 504 storm after a deploy, works out the cause (a connection pool exhausted by a migration), fixes it, and writes a record: "incident: api 504s after deploy, pool exhausted by long migration; mitigation: cap migration concurrency."
Tuesday: agent B, a different session on a teammate's machine, sees 504s again. It asks "why would the api 504 after a deploy?" and gets agent A's record back as the canonical answer. It applies the known mitigation in minutes instead of re-investigating.
Wednesday: the mitigation changes. Someone lands a real fix. An agent writes the new record; the store marks it canonical and the Monday note as superseded. Nobody has to remember to delete the old one.
A plain database (or a vector store, or a notes app) gives you storage and retrieval. It does not give you canonical: ask it a question and it returns whatever matches, ranked by similarity, with no opinion about which is current. The unit of output here is the one current answer with a freshness marker, and the write path supersedes rather than appends. That is the same distinction we drew across the three MCP context patterns.
The second difference is that it is the same store the agents already read code-context from, reached through the same MCP tool, local-first. There is no separate system for "agent memory" to wire up and keep in sync. The read path and the write path are one path. If you are thinking about agent memory as its own layer, we laid out the trade-offs in a five-layer memory for an AI agent.
If you run one agent, in one session, on a small repo, the write path is a nice-to-have. The single-agent token math is your main win.
It starts to matter the moment there is a second actor on the same repo: a second agent, a second session that should remember the first, or a teammate. That is where re-derivation and drift cost real time, and where keeping things consistent by hand stops scaling. If that is your situation, the shared write path is the point, not a footnote. It is also where multi-agent orchestration either holds together or quietly falls apart.
Rolling agents out across a team and watching the drift-and-re-derivation tax show up is the kind of thing we fix for a living, after running it on our own fleet first. We bring the shared read/write layer we use ourselves, fit it to your repos, and train your people to keep one source of truth as the fleet grows.
We map where your agents re-derive and where findings drift, then show what one shared canonical store would change for your fleet and your bill.
Running more than one agent and watching knowledge drift?
Three things. Parallel re-derivation: two agents work out the same answer from scratch on different days, so you pay twice. Drift: each writes findings into its own file, and nothing says which is current. Lost knowledge: an agent solves something in a session that ends, and the next incident re-runs the investigation. None of it is fixed by a smarter agent.
Why doesn't CLAUDE.md or a shared wiki solve this?
They solve a slice and stop. A CLAUDE.md is one hand-maintained file that goes stale and does not scale past a handful of topics; agents generate knowledge faster than a person curates it. A wiki or docs folder is many files with no canonical signal, the same pile, now written to by several actors at once. What is missing is a write path with a notion of canonical.
What does a shared write path actually change?
Every agent reads from and writes to one place, and that place is the source of truth by construction. An agent writes a finding once; the next agent reads it back by meaning as the canonical answer with a freshness marker; a newer record supersedes the old one instead of competing with it. Because reads and writes go through one point, there are no copies to sync.
When does this matter, honestly?
If you run one agent in one session on a small repo, the write path is a nice-to-have and the token math is your main win. It starts to matter the moment there is a second actor on the same repo: a second agent, a second session that should remember the first, or a teammate. That is where re-derivation and drift cost real time.
