Who Owns the Enterprise Context Layer in a World of Agents?

Sovereign context operating model

An AI agent is only as good as the context it can reach. For a regulated enterprise, that context — the architecture repository — is also one of its most sensitive assets.

The operating model that matters is not "expose the repository over MCP"; it is "govern what context leaves, to whom, and under which residency and audit constraints".

• Decide which object types are queryable, and which are never exposed
• Keep context fresh: reconcile the repository against live sources, not a yearly snapshot
• Make every answer traceable to a governed source the user is entitled to see

When agents do the clicking, the UI stops being the moat

For two decades, enterprise software competed on the surface a human looked at: the dashboard, the workflow, the report builder. The interface was the product, and the prettiest, fastest UI often won the deal.

Agents change the geometry of that contest. When an AI agent reads your application portfolio, drafts the impact analysis and writes back the decision, fewer humans navigate the screens. The agent does not care whether a chart is elegant; it cares whether the underlying data is correct, complete and current. As mediation shifts from human clicks to agent calls, the question quietly moves from 'whose interface is best?' to 'whose context can the agent trust?'.

This is not a prediction that screens disappear. It is an observation that the centre of gravity moves — from presentation toward the substance the agent consults.

The real contested ground: the enterprise context layer

Agents need a place to reason from. Alongside the Systems of Record — the ERP, the CRM, the ITSM that hold transactional truth — a second layer is emerging: a System of Context, the model that tells an agent how the enterprise actually fits together.

Enterprise architecture is the natural home of that layer. It already holds the living map of capabilities, applications, dependencies and data flows — exactly what an agent needs to answer 'what depends on this system?' or 'what breaks if we retire it?'. The enterprise context layer is not a new buzzword for a dashboard; it is the connected model agents reason on.

If agents become the primary consumers of enterprise knowledge, then whoever owns the most trusted, complete and governed context layer holds a stronger position than whoever owns the nicest front end. That is the shift worth taking seriously.

The trap: a bare MCP is a commodity

It is tempting to conclude that the answer is to 'own the protocol' — to ship a Model Context Protocol endpoint and declare victory. That is the trap, and it is worth naming plainly.

MCP is a protocol, not a product. The right analogy is HTTP. Nobody won the web by owning HTTP; the protocol was a commodity, and the value lived in what travelled over it — the content, the services, the data. By the same logic, an MCP endpoint is table stakes, not a moat. Once a protocol is standard, supporting it is expected, not differentiating.

We hold this discipline about our own work too. ArchiLU does not ship a sovereign MCP server today — we describe it as a conviction and a direction we are building toward, not a delivered feature. The argument is never 'we do MCP'. The argument is what sits behind it.

• The protocol is the pipe; the value is what flows through it
• Supporting MCP is expected, not differentiating
• A protocol over a stale or shallow repository is worthless
• Build order is context first, governance next, protocol last

The moat is the governed context graph, not the protocol

If the protocol is a commodity, the defensible asset is the governed context graph behind it: the connected model of the enterprise, and the rules around who may read it, change it and account for it.

Three properties decide whether that graph is trusted. Completeness — does it actually represent the estate, or a fraction of it? Freshness — is it a living, continuously refreshed model, or an eighteen-month-old snapshot that quietly lies to every agent that reads it? Governance — is there a controlled, reviewable, auditable path for how the context is maintained? A beautiful protocol over a stale or partial graph is worse than useless, because agents will reason confidently on wrong context.

So ownership is not won by the protocol. It is won by being the most trusted, complete and governed source the agents converge on.

For regulated firms, sovereignty and governance decide ownership

There is a second reason ownership is contested, and it matters most in regulated finance. An enterprise architecture map is close to a full blueprint of the organization: the system inventory, the critical dependencies, the obsolete components, the sensitive data flows, sometimes the security measures themselves.

Letting agents reason over that without controlling where the data goes is not a UX choice — it is a DORA, NIS2, GDPR and EU AI Act exposure. Sending a near-complete map of a bank's systems to a US-cloud model is exactly the kind of decision a CSSF-facing team cannot wave through. So for these buyers, 'who owns the context layer' is inseparable from 'where does the context live and who can be held accountable for it'.

This is the sovereign context layer: governed enterprise context an AI can use without the data leaving your control. To be clear, that is a tooling and documentation aid, not a guarantee of legal compliance — a tool helps you document and prove, it does not make you compliant on its own. For regulated firms, sovereignty and governance are not features on a comparison grid; they are the conditions under which any agent is allowed near the context at all.

• The architecture map is a near-complete blueprint of the organization
• Uncontrolled agent access is a DORA/NIS2/GDPR/EU AI Act exposure
• Sovereignty means context an agent can use without the data leaving your control
• Tooling documents and proves; it does not by itself make you compliant

Curation does not die — it becomes governance

It would be dishonest to claim that the human craft of modeling simply vanishes. It does not. As the UI recedes, the work of deciding what is true, what is current and what is allowed moves upstream — from the end-user screen into governance.

Incumbents understand this. ServiceNow, SAP and the established EA platforms hold deep, real assets — vast Systems of Record, mature modeling, large install bases — and they are well placed to expose context to agents. Their strength is genuine. The open question is the intersection they serve less naturally for European regulated finance: living context, regulatory reasoning and sovereignty together. That is the seam, not a claim that the giants are absent.

The decision-oriented takeaway: stop optimizing for the prettiest screen and start asking who can be trusted with the context your agents will consult. If you are a regulated institution, weigh that question on sovereignty and governance, not on dashboards. A grounded place to begin is your own maturity — our free EA Maturity Assessment scores ten dimensions in about ten minutes and shows how ready your context actually is for agents.

Regulated AI context KPIs

Measure whether your context is trustworthy and governed, not how many queries the agent runs.

• Context freshness: median age of architecture objects vs live reality
• Share of answers traceable to a governed, permission-scoped source
• Sensitive object types covered by redaction/residency policy
• Audit coverage: prompts and responses logged and reviewable

Common mistakes

Most MCP-for-EA initiatives fail on context quality and governance long before they fail on the protocol.

• Exposing the full architecture repository to external LLMs without data-residency controls
• Treating MCP as the differentiator instead of the governed context behind it
• Connecting an 18-month-old, hand-maintained repository an agent cannot trust
• No permission-awareness, logging, or redaction of sensitive object types

Practical checklist

Run this before connecting any AI agent to your architecture repository.

• Confirm where prompts and responses go, and whether data stays in your region
• Enforce permission-aware access so the agent only sees what the user may see
• Classify and redact sensitive object types (vulnerabilities, data flows, controls)
• Log prompts and answers for audit, and keep a human in the loop for any change