A second memory layer next to the graph: pairing codebase-memory-mcp with a wiki that keeps the why

[neo37]

We have been running codebase-memory-mcp as the structural memory for our agents, and ended up building a companion for the half it deliberately does not cover. Sharing it in case the idea is useful to others here.

The gap we hit. The graph answers where things are: files, functions, calls, imports. For cardflow/services/status_transition.py it knows the name and the callers — but not that this is "how a deal card moves between statuses", not which decisions shaped it, and not what the contract with the neighbouring service is. That second kind of knowledge is what our agents kept asking for, and it has no natural home in a code graph: it changes for different reasons, it is written by people as often as by agents, and it needs history.

What we built. go-wiki — a Markdown wiki with full revision history, a REST API and a built-in MCP server, as a single Go binary with no Postgres, no Redis, no Node. SQLite holds only the current version of a page; every superseded revision is written out as a plain .md file on disk, so the history stays readable with cat and diff even if the service is gone. Apache 2.0.

The pairing is the point. An agent connects both servers at once and asks each what it is good at:

{
  "mcpServers": {
    "codebase-memory": { "command": "codebase-memory-mcp" },
    "go-wiki": { "type": "http", "url": "http://wiki.internal:8080/mcp" }
  }
}

• Where does this live, who calls it, what breaks if I change it → the graph.
• What is this domain, why was it decided this way, what does the spec require → the wiki.

In practice the two are joined by a domain map: changed files from a diff resolve to a domain through the graph, and the domain resolves to a subtree in the wiki (product/<domain>/overview, product/<domain>/contracts, specs/<domain>/<ticket>). A page written by an agent through MCP is indistinguishable from one written by a person in the browser — one history, one revision mechanism, optimistic locking so ten agents writing at once cannot silently overwrite each other.

Things that turned out to matter once several agents wrote into it: mandatory base_rev on updates (a convention that clients pass it is not a mechanism), honest 409 on write races, verified authorship instead of a free-text author field, moving a subtree without losing history or leaving dangling links, and a tree endpoint so an agent walks one level at a time instead of pulling every page.

No affiliation and nothing to install on your side — this is just a note that the "where" layer and the "why" layer compose well, and that the second one is small enough to be a single binary. Happy to answer questions if anyone wants the details of how the domain map is built.