Model Context Protocol as an architecture knowledge system

Architecture practices have a distribution problem. The standards, the reference patterns, and the decision records all exist, and none of them are open at the moment a developer chooses a hosting pattern at four in the afternoon.

The cause is an interface failure. We publish knowledge in a format optimised for authoring (long documents, reviewed carefully, stored centrally) and then expect it to be consumed in a completely different mode: quickly, in context, mid-task.

The Model Context Protocol is interesting because it closes that gap without asking anyone to change how they work.

What MCP actually changes

MCP is a protocol for exposing tools and context to a model in a structured, discoverable way. The important word is discoverable. Rather than a person remembering that a standard exists and going to find it, the standard advertises itself to the tooling the person is already using.

That inverts the burden. The practice runs on availability rather than recall.

We built an Architecture Playbook MCP, a Model Context Protocol architecture knowledge service deployed on the Alberta Digital Service Platform, on exactly this premise. The content already existed. The change is that it is reachable from inside the delivery workflow rather than from a bookmark.

Retrieval alone stops short

The obvious first move is retrieval, and it is worth doing. A retrieval system over policy and standards (what we run as the Librarian Agent) answers the most common question a practice gets, which is some variation of “is there a rule about this?”

Retrieval alone reproduces the original problem in a faster form. It returns a passage when the question is a decision. Architecture lives in the distance between “here is the relevant standard” and “here is what that means for your case”, and a knowledge system has to close that distance.

Three things make the difference:

Structure over prose. A standard written as a narrative retrieves badly and applies worse. The same standard expressed as a pattern (context, forces, decision, consequences) can be matched against a situation rather than merely quoted at it.

Provenance on every answer. If the system cannot say which document and which version an answer came from, it cannot be used for anything that will be reviewed. Provenance is the property that makes the output admissible.

Explicit currency. Superseded guidance is worse than missing guidance, because it is confidently wrong. Every item needs a date and a status, and the retrieval layer needs to prefer current material rather than whatever embeds most similarly.

Why deploy it on the platform

There was an easier version of this: run it locally, let individuals point their tooling at it, see who bites.

We put it on the Alberta Digital Service Platform instead, for the same reason any shared capability belongs on the platform. It inherits the hosting, identity, and access controls that already exist, it has an owner, and it can be reviewed. It is also subject to the same governance it describes, which is the minimum credibility bar for a system whose job is to tell people what the governance is.

A knowledge service that cannot survive its own architecture review should not be advising anyone.

What it does to the practice

The effect that surprised me was consistency.

When architectural knowledge is only available through people, the answer a team gets depends on which architect they asked and how recently that architect read the standard. Variation accumulates across a six-ministry portfolio until you have six architectures wearing one name.

When the knowledge is available through a service, the baseline answer is the same everywhere. The architects then spend their time on the part that genuinely requires judgment: trade-offs, sequencing, and the cases where the standard does not fit.

That is the real argument for treating architecture knowledge as a system. It stops architects being a lookup table.

Where this is still immature

Two honest caveats.

The tooling around the protocol is young, and the surface is moving. Anything built on it needs to be cheap to re-point, which argues for keeping the content in a durable, structured store and treating the protocol layer as an adapter rather than the system of record.

And the hardest problem is upstream of the protocol entirely. Most architecture practices do not have a clean, current, structured corpus to expose. Producing one is editorial work with no demo at the end of it, which is why it rarely gets funded and always determines whether the rest works.

Reusable beats bespoke at portfolio scale, once the reusable thing is worth reusing.