Stop Buying Memory Plugins. Start Writing Documentation.

The AI coding agent on your team can autocomplete a line, draft a migration, and refactor a hook. Ask it why the rate limiter exists, who decided to skip Redis, or what the project agreed about auth last Tuesday, and it loops. It asks the same question twice. It contradicts a decision the team made last week. Every builder of an AI project assistant has felt this.

The memory-plugin market treats that as a recall problem. The standard architecture is simple: take roughly a thousand snippets of past conversation, embed them (turn each snippet into a list of numbers that captures its meaning), and store them in a vector database. On every new prompt, run a similarity search, which ranks the snippets by how close their meaning is to the user's question, and inject the top five into the model's context. The vendor calls this "agent memory." It is, mechanically, a thin similarity-recall layer on top of a project the human actually understands.

That layer is structurally wrong for four reasons. First, similarity is not correctness. A snippet that sounds like the right answer can be the wrong one. Second, snippets lose context: a decision made under a deadline, with three constraints in mind, becomes a sentence stripped of motivation. Third, the past is not the truth. The codebase moves daily, and an injected snippet from two months ago can directly contradict the current code. Fourth, and most damning, the agent cannot search for what it does not know is missing. Similarity only finds what already resembles something. It cannot recover an unstated constraint, an ADR that was never quoted, or a principle the team has not violated yet.

The leverage is upstream. A project that a human can document in plain language, including what it is, why a decision was made, what the constraints are, and what counts as done, is a project an agent can also read. The substrate is documentation: ADRs (Architectural Decision Records, short Markdown files that capture a decision, the alternatives considered, and the tradeoffs accepted), a CONTRIBUTING.md that explains how the code is organized, a CODING_STANDARDS.md for the conventions the team enforces, versioned principles that survive refactors, specs kept in GitHub issues, and an AGENTS.md that tells the agent where the entry points are. None of this is novel. The Hacker News thread on the original essay confirms that senior builders, including Matt Pocock's skills repo, teams that version their principles, and projects that treat ADRs as the canonical agent-readable substrate, already practice this pattern.

The falsifier is straightforward. If a memory plugin is tuned on a small static project, it can look like it works. The test is whether it still answers correctly a month later, after the code has moved, the dependencies have rotated, and the team has changed its mind twice. A similarity layer over a moving substrate is a layer that drifts. Documentation, written in human language and checked into the repo, does not drift in the same way. It is updated, version-controlled, and reviewable.

Memory plugins will be a feature, useful for "what did the user say last time," bounded and cheap. Documentation is the substrate you already know how to write, and it is the only layer of the agent stack that survives model churn, vendor churn, and a moving codebase. The choice is being made in real time, mostly by default, in every procurement email a team sends this quarter.

Three files to write this week: an ADR template and one filled-in ADR for the most recent non-obvious decision, a CONTRIBUTING.md that points the agent at the entry points, the test command, and the constraints the team actually enforces, and an AGENTS.md that names the rules an agent must follow before opening a pull request. That is the layer the agent reads, and the layer the team owns.