Making architecture queryable by agents: the Knowledge Backbone and MCP

An AI agent doesn't read your architecture diagrams; it works with what is put in its context: a prompt, retrieved documents, exposed tools. If the organization's rules — who decides what, which source is authoritative, which constraints are active — live in documents only humans consult, the agent ignores them, without malice. The Model Context Protocol (MCP), now an open standard under Linux Foundation governance, offers a uniform way to expose a repository to an agent (Linux Foundation). The question becomes: what do we have that is reliable enough to expose?

A protocol doesn't replace a source of truth

MCP standardizes communication between an agent and its tools or data. It says nothing about the quality of what is exposed. If the architecture repository holds three contradictory versions of the same rule, the agent will access it very efficiently — and apply it wrongly. This is the textbook case for the Knowledge Backbone: a piece of information has only one authoritative source, and that authority is declared. Without it, the protocol speeds up the spread of inconsistencies.

What the Backbone can usefully expose

In TEAF, the Backbone gathers data, past decisions (Living ADRs), dependencies between capabilities and active constraints. Four concrete uses for an agent:

• Consult active constraints before acting: regulatory, technical, contractual.
• Read decisions and their status, including those marked "to review", so as not to contradict an already settled trade-off or apply an outdated decision.
• Know the dependencies: which capability, system and owner a change affects.
• Know whom to escalate to when the action exceeds its scope.

The essential safeguards

Exposing a repository to an agent means granting access. The same principles as for any privileged account apply, and they belong to the AI Control Plane:

• Read-only by default. An agent querying the Backbone must not be able to modify it without validation.
• Minimal rights per agent, not global access to the repository: an invoicing agent doesn't need security decisions.
• Logging of lookups and actions: without a trace, no audit.
• Treat content read as untrusted: a retrieved document may contain hidden instructions (injection). What an agent reads doesn't carry the status of an instruction.
• Inventory MCP servers as access surfaces, like other integrations.

Limits to keep in mind

Making a rule readable to an agent doesn't guarantee it follows it: independent control of what it actually does remains necessary (the loop's Observation component). Exposed but poorly maintained context is worse than an outdated document, because it is applied automatically. Finally, the real effort is organizational: feeding and reviewing the Backbone is a discipline, not a technical given, as the article devoted to it recalls. TEAF doesn't provide a ready-made MCP server; it describes what should be in it and who answers for it.

Where to start

Pick a narrow, high-stakes scope — expense approval, for example — formalize its rules in the Backbone, name an owner, expose them read-only to a pilot agent, and measure gaps between what the agent does and what the rules provide. That restricted scope is the spirit of TEAF Light and the 1-1-1 principle.

• MCP standardizes an agent's access to a repository; it doesn't guarantee the quality of what is exposed.
• The Knowledge Backbone — a single authoritative source — is the prerequisite to any exposure to agents.
• Read-only, minimal rights, logging and distrust of content read are mandatory safeguards.
• A readable rule is not an obeyed rule: independent control remains.

Sources

• Linux Foundation — Agent2Agent protocol project
• AI Governance Today — MCP for enterprise architecture 2026
• BlueDolphin — Agentic AI: enterprise architecture's shift from control to context