What a shared memory cannot know about its reader.

Put an organisation's memory behind an open protocol and an agent whose harness speaks that protocol can read from it and write to it, whichever vendor's model it runs on: the knowledge stops belonging to one tool. That is a real property, and it is narrower than it sounds. The memory decides what is served; it does not decide whether it is read, cannot see which model read it, and cannot tell a stale sentence from a true one.

§1The memory sits behind a protocol, not inside a model

The three papers before this one describe what a read returns. This one is about who can ask. The memory is exposed through the Model Context Protocol, whose Streamable HTTP transport specifies that "the server MUST provide a single HTTP endpoint path … that supports both POST and GET methods".^[1] The specification lets a server assign a session; this one does not, so every request stands alone and carries its own credential. Behind it sit the same scopes, the same ranking and the same brief described in Papers 001 to 003, whichever agent is asking.

Two routes reach the same store and the same ranking. An agent that runs on a developer's machine connects through a small local bridge that speaks the protocol over standard input and output, works out the repository scope from the directory it was started in, and calls the memory's own interface. On one workstation that bridge was registered on 19 September 2026 with Anthropic's Claude Code, OpenAI's Codex CLI and Google's Gemini CLI, each pointed at the same store. An agent that runs in a vendor's cloud would connect to the endpoint directly: xAI, for instance, documents remote MCP tools configured with a server_url — "Only Streaming HTTP and SSE transports are supported" — and an optional authorization token that "will be set in the Authorization header on requests to the MCP server".^[2] That is a configuration these notes rely on but have not exercised (§4).

§2The harness decides when the memory is read

A protocol endpoint answers requests; it cannot make one. Whether an agent consults the memory at the start of a task, halfway through, or never, is decided by the program the model runs in — the harness — and by the model's own choice to call a tool it has been offered. Where the harness supports it, a hook can fetch a brief before the model's first turn, so the reading does not depend on the model remembering to ask. Where it does not, the memory is one tool among many, and a model confident it already knows the answer may not call it.

Writing is the same in reverse. A lesson reaches the organisation only if something in the agent's loop decides it is worth recording and calls the write. The memory can make that call cheap and well-scoped; it cannot make it happen. So the second layer is only as complete as the habits of the agents and people around it, and the agents' habits are configured separately in each harness, by whoever runs it.

§3A credential names an organisation, not a model

Every request carries a key, and the key identifies the organisation whose memory it may read. It does not identify the model on the other side of the harness. The protocol lets a client name itself when a session starts; that names the harness, not the model, is not checked, and is not kept by an endpoint that holds no session. Where a client forwards the person it acts for — the configured git user, a CI actor — each write is recorded against that name; otherwise against the key's fingerprint. The record can say on whose behalf the client claimed to write. It can attest neither that claim nor which model wrote the memory, or read it.

Two things follow for anyone relying on it. The organisation's own decisions — its strategy, how it prefers to work, what it has ruled out — reach an agent only if a person states them at the organisation's level; distillation from repositories produces what repositories say, not what the organisation decided. And retiring a sentence that has stopped being true is a deliberate act that somebody has to own, because nothing in the read path will do it for them.

§4What is open, and what would settle it

None of these is a reason not to share a memory across repositories and vendors. They are the reasons to describe what sharing it does accurately: one store, one set of rules, one brief for any agent that asks — and a store that is only as current, as curated and as consulted as the people and harnesses around it make it. Nothing above is committed; each item is open until someone settles it, and these notes settle none of them.