A Hacker News Post Says Agents Need Documentation, Not Memory, and Its Author Wrote the Plugin That Does That

Kevin Liao's post "Agents Don't Need Memory. They Need Documentation." reached 348 points on Hacker News by Oct. 5, two days after he published it. The post is also the launch argument for a plugin he built, so the claim and the product arrive together. Neither is wrong for that reason, but a reader should price it in.

The argument as written

Liao's post, dated Oct. 3, 2026, opens with its thesis: "Agents don't need memory. They need documentation." He describes memory plugins as one architecture with cosmetic variations: capture a transcript, cut it into snippets, store them in a retrieval database, and attach the most similar few to each prompt.

He lists failure modes, as the fetched text reads. Snippets surface by similarity with no check on accuracy, they are stored without context, the past is treated as truth after the codebase has changed, and the store cannot be audited. His proposed loop is "prompt → consult → build → update", with the agent reading and rewriting a structured workspace instead.

His own illustration of scale is a store of 10,000 embeddings in SQLite holding 500 snippets about authentication. The post, as fetched, reports no measured comparison between the two approaches.

What Operator Memory is

The Operator Memory README describes a BSD 3-Clause plugin with 259 stars and 7 forks. Install is npm install --global @aerovato/operator-helper, then harness-specific setup. Supported harnesses are Claude Code, Codex, OpenCode V2, Pi and the DeepSeek Harness, with OpenCode V1 on legacy support.

The first-run commands are /operator:user-init and /operator:project-init. The README promises no background services, embeddings, vector databases or model configuration. In Liao's words, "Everything is a plain Markdown document that you can read, update, commit, and share."

What the comparison leaves out

Our earlier look at Claude-Mem is the design Liao is arguing against. It records tool calls into a local SQLite file and feeds them back next session. It also has a <private> tag that keeps marked text out of storage, so secrets depend on the user tagging them. Liao's audit complaint is real there, since a SQLite file is harder to review than a pull request.

Documentation fixes the review problem and creates another. A Markdown workspace is only as current as the last agent that updated it, and Liao's post, as fetched, names no limitation of its own approach. A stale spec that an agent trusts is the same defect he assigns to old snippets, with better formatting.

A third position from September

Atul Kumar, listed as Chief Product & Innovation Architect at Spotlyf, published a HackerNoon essay on Sept. 23, 2026. His claim: "The problem is not always that the agent cannot remember enough. The problem is that it does not know which information represents the current truth."

Kumar's examples come from operations. An agent gets API confirmation of a refund but cannot verify the money moved. Two agents that both read version 42 of an account record can overwrite each other unless the write checks the version. His line that "relevance is not the same as truth" applies to documents as well as to vector stores.

Position	Where truth lives	Failure it names
Memory plugins, per Liao	Retrieved snippets	Similarity without accuracy, unauditable store
Liao, Operator Memory	Markdown files in the repo	Single AGENTS.md files too thin
Kumar, Spotlyf	The system that owns the data	Stale state, write races

What a team choosing between them would check

The practical question is who has to maintain the thing. A memory plugin asks nothing of the team after install, which is its appeal and, in Liao's telling, its flaw. A documentation workspace asks reviewers to read agent-written Markdown in pull requests, the same way they read code.

That cost is real. Operator Memory scaffolds a project with /operator:project-init and then updates canonical project files as the agent works, so every session can produce a diff. Teams that already review every change will absorb that. Teams that merge on green checks may find the docs drift quietly, because nobody is assigned to read them.

Kumar's framing adds a third test that neither tool addresses: whether the agent can tell which source owns a fact. For a coding agent the owner is usually the code itself, and a document that disagrees with the code should lose. Neither the post nor the Operator Memory README says how that conflict is resolved.

What would change this read

Take a coding task on a repository where a decision changed two weeks ago. A snippet store may surface the old decision; a document store surfaces whatever the last agent wrote. Which fails less is an empirical question, and the post offers no measurement. A paired run on the same repository, with both tools and the same prompts, would settle more than the thread has.

The Hacker News score also tells us little. The Ponytail ruleset drew 154,000 stars on a benchmark of four runs, and attention has not tracked evidence in this category.

Until someone publishes that comparison, the defensible reading is narrow. Documentation is easier to review than a vector store, and Operator Memory is a small, BSD-licensed project whose author is also its loudest advocate. The next signal is an independent run that shows either tool changing task outcomes.