System of Context vs System of Record: The Layer Missing in the Age 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

Execution focus for this topic

Agents query a new layer — the System of Context — and whoever governs it becomes strategic; EA is its natural home.

Use this page as a decision support asset: align stakeholders, validate trade-offs, and connect architecture choices to measurable business outcomes.

• Primary query focus: System of Context vs System of Record: The Layer Missing in the Age of Agents
• Decision scope: strategy, governance, operating model, and execution constraints
• Expected output: clear next actions with ownership and measurable indicators

For 20 years, value lived in the System of Record

For two decades, the most valuable software in the enterprise was the System of Record. Salesforce became the authoritative store for customers, SAP for finance and supply chain, ServiceNow for IT operations, Workday for people. Each one won by becoming the single, trusted place where a domain's transactions were written down. The market rewarded that role richly: a System of Record is sticky, audited, and impossible to rip out casually.

But a System of Record is built to answer one question well: what happened, inside this domain. Salesforce knows your pipeline. SAP knows your ledger. ServiceNow knows your tickets. None of them knows how those systems connect to each other, which business capability each one serves, or what would break if you switched one off. That cross-cutting knowledge was never their job — and for two decades, it didn't have to be.

Agents need a different question answered: the System of Context

AI agents change the question. Ask an agent to assess the impact of decommissioning a core banking module, or to flag which systems touch personal data before a migration, and it immediately needs knowledge no single System of Record holds. It needs to know what exists, who owns it, what data it touches, what regulation applies, and what depends on what.

That is a different layer. Call it the System of Context: the governed map of how the estate fits together, sitting above the records rather than inside any one of them. A System of Record answers "what happened." A System of Context answers "what breaks if…", "what is redundant", and "what is at risk". The first is a ledger; the second is a graph of relationships — and a graph is exactly what an agent must traverse to reason about anything that spans more than one system.

• What exists — the full inventory of systems, not one domain's slice
• Who owns it — accountability an agent can route a decision to
• What data it touches — the sensitive flows that trigger regulation
• What regulation applies — DORA, NIS2, GDPR, EU AI Act scope per system
• What depends on what — the dependency graph that turns a change into a blast radius

Today that context is scattered — and that is the opportunity

The reason no one has won the System of Context yet is that it doesn't live anywhere clean. It is smeared across a Visio diagram from last year, three spreadsheets, a Confluence page nobody updates, a CMDB that drifted, and the memory of two architects who are about to retire. An agent pointed at that mess produces confident nonsense, because the context it reasons over is partial, stale and contradictory.

This scatter is precisely the opening. Whoever consolidates that context into one place — and, crucially, keeps it living and governs who can use it — turns scattered tribal knowledge into a strategic asset. It becomes the layer every agent, every impact analysis and every transformation decision routes through. The Systems of Record spent twenty years becoming indispensable by owning a domain's truth. The next decade's equivalent is owning the truth about how the domains relate.

Enterprise architecture is the natural home of the System of Context

Here is the part most discussions miss: the System of Context is not a new category to invent from scratch. One discipline has spent its entire existence modelling exactly this. Enterprise architecture describes capabilities, applications, technologies, data flows and the dependencies between them. Its whole purpose is to describe how the estate fits together — not what any single system recorded.

A well-maintained EA model is therefore the closest thing most organizations already have to a System of Context. The gap is not conceptual; it is operational. Too many EA repositories were built as a documentation exercise — accurate the day they were finished, then frozen into an 18-month-old snapshot. An agent cannot reason on a snapshot. The work, then, is to treat the EA model as a living, agent-ready repository: continuously refreshed, owned, and queryable — context, not archaeology.

• EA already models capabilities, applications, technology and data flows
• EA already encodes dependencies — the graph agents must traverse
• The missing piece is freshness and governance, not a new data model
• A living EA model is a System of Context; a stale one is a museum

For regulated finance, the context layer must be sovereign

Consolidating context is powerful, and that is exactly why it raises the stakes. A complete System of Context is a near-complete blueprint of the organization: its full system inventory, critical dependencies, obsolete components, sensitive data flows. The convenient move — wiring Claude, ChatGPT, Gemini or Copilot directly to it — quietly assumes that sending that blueprint to a US-cloud LLM is acceptable. For a regulated European bank or insurer, it often is not. That is a DORA, CSSF, GDPR and EU AI Act question, not a feature toggle.

So the defensible System of Context is a governed one: permission-aware about who can query it, and data-residency-aware about where the data goes. The point is not who asks the question; it is whether the answer can be produced without the context leaving your control. This is the conviction ArchiLU is building toward — a sovereign context layer, EU-hosted or on-premise, that an institution's agents can trust and an auditor will accept. To be clear: the connected EA model exists today; the fully agent-queryable sovereign layer is roadmap, and we will never pretend otherwise.

Start from your context, not from the hype

The category is being named while it is still up for grabs. Systems of Record will not disappear — they remain the authoritative source for their domains. But the strategic question of the next decade is who owns the System of Context, and for regulated institutions the answer has to be sovereign by construction.

The practical first step is unglamorous and concrete: find out how living your context actually is. If your architecture is a snapshot, no agent and no consolidation strategy will save it. ArchiLU's free EA Maturity Assessment scores ten dimensions and returns a prioritized action plan in about ten minutes — a fast way to see whether your organization has a System of Context worth governing, or an archive worth refreshing first.

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