Chapter 20

How Memory Leaves the System

The material of Chapter 19 is only useful once it reaches an Agent. However well a memory system runs inside, if an Agent cannot reach it, that is where its use stops. Vinc joins this boundary with MCP, the Model Context Protocol. It is the door Chapter 2 meant when it said an AI reads and writes the same graph through MCP.

1. A thin bridge

Vinc's MCP server is a bridge. It validates the shape of a call, forwards it to the sidecar over an internal path, and returns the answer. There is no judgment of meaning in it, no structuring, no deduplication. All three already live elsewhere: upstream in the host, downstream in the engines.

That is not modesty. It is the property that makes the second door safe. A tool that interpreted its arguments would be a second implementation of the graph contract, and the two would disagree the first time either changed. Because the bridge is thin, the MCP door and the app's door cannot drift apart.

2. Two transports, one dispatcher

A locally registered host speaks over standard input and output; a remote connector speaks HTTP. Both wrap the same dispatcher and the same tool handlers, so every tool has exactly one implementation.

The dispatcher knows the minimum: initialize, ping, list tools, call a tool, and the role prompts of Chapter 21. Anything else it answers as unknown. There is no streaming; every tool is one request and one response, so a stream would add a path with no benefit. A tool failure comes back as a result marked as an error, not as a protocol error, so that a host can correct and retry instead of tearing the session down.

There is no framework. The server is written on the standard library, to keep outside dependencies down, to match the sidecar's own server, and to add nothing to the size of the frozen binary.

3. The door needs a key

The remote transport refuses to start if no authentication at all is configured. A public door cannot appear by omission.

There are three ways in. A static token, for internal use, carries no identity. A standard authorization flow, bound to no particular vendor, is how two different browser AIs register against the same door. A member API key is verified against the account, and here the hub holds no account database and no account secret: it signs a short-lived assertion with its own private key, and the account verifies it against the hub's public key only. Sharing a public key is not sharing a secret, which is what lets the two services run as one system without merging their trust.

Whichever way in, the owner comes from the authenticated identity and never from the request. A client that could name the owner of its own graph would be a hole into someone else's.

4. Which graph is an argument

One person can belong to a personal graph and several team graphs. At first the address chose the space: one registered endpoint per team. On 31 August 2026 that was reversed. The owner wanted one connector reaching both personal and team graphs, and measurement showed the address had never been a security boundary: whoever held a personal key already reached every team they belonged to, given the address. What the address bought was mistake prevention, not authorization.

Now the space is an argument on the call, and the default is personal. A session connected at a team address stays pinned to that team and ignores the argument. Refusing calls that omit the argument would have been safer, and it would have broken every registered personal connector on day one. The mistake prevention is repaid by three guards: a write reports the graph it landed in, initialization says where you are before anything is asked, and vinc_whoami answers which spaces you can reach and your role in each. What a space is comes in Chapter 26.

5. Tools carry a risk label

Not every tool carries the same risk. Reading is not writing; deleting a document is not searching one.

So every tool carries safety annotations, and they are not optional: a server without them is refused by the remote directory. Read only or not, destructive or not, idempotent or not. One trap: in the specification the destructive flag defaults to true, so a write that is not destructive has to say so or hosts warn about an additive merge as though it deleted something.

The annotations are hints, not a trust boundary. Enforcement is on the server: owner stamping and quota. There is more than one write tool, because merging, deleting a Node, deleting an Edge, folding two Nodes, writing or deleting a document, and recording a decision are different acts with different consequences. The audit boundary is the annotations plus owner stamping, not the count.

Ratifying vocabulary is not on MCP at all. As Chapter 13 said, it is a person's act, so it does not sit where an AI can reach it on its own.

6. Results have a boundary too

A result ends up in an Agent's context. So MCP results have a budget, and a result over budget is reduced in an order fixed per tool. Chapter 19's brief drops excerpts first, then relations, and keeps the grounds to the end. It shrinks by policy rather than truncating, and the response says it was shrunk.

7. What this door does not do

There is no call log. The design had an append-only record of every tool call, and the panel that would read it was never designed, so the log was never built either. Today a user cannot see what a host wrote through MCP except by looking at the graph afterwards. The safety annotations let a host ask before a destructive write, but they leave no record. That gap is written down rather than hidden.

This book does not say how many tools there are. That number is measured by one Record in the graph, and the number written in prose went stale twice. The number that matters more is how many calls it takes to reach an answer, and that is Part 4.

MCP's role is simple: let an Agent outside call Vinc's memory safely and consistently. Above that, the meaning of memory belongs to the Graph, the Document, search and resolution.

The one reading the graph from outside the door is the Agent. How its role stands inside the graph is the next chapter.

Continue with Chapter 21, A Role Is a Node.