A CIO I spoke with recently put it better than any analyst deck I have read this year: “We bought the models. We have the use cases. What we don’t have is a way to tell the AI what our company is.” Their pilot agents could draft contracts and summarise incidents beautifully — and then confidently routed a procurement request to a department that was dissolved in a reorg two years ago. The model was fine. The context was missing.

I keep watching this pattern repeat, and I have come to a conclusion that would have sounded self-serving five years ago: the enterprise architecture repository — the thing we apologise for at parties — is about to become the most strategically important data source in the company. Not because our diagrams got better, but because for the first time there is a consumer that desperately needs what EA has been quietly curating all along, and that consumer reads faster than any stakeholder we have ever had.

The context gap

Large language models arrive knowing everything about the world and nothing about your enterprise. They do not know that “Atlas” is the billing platform and “Apollo” is the one being decommissioned, that the customer-onboarding capability is delivered by four applications and a heroic spreadsheet, or that the org chart on the intranet is eighteen months stale. Every enterprise AI failure I have been asked to look at reduces to some version of this: the agent acted on the world’s knowledge where it needed the company’s.

The industry’s first answer was retrieval — point the model at your document stores and let it search. That helps, and it also faithfully retrieves your contradictions: the 2021 target-state deck, the abandoned integration strategy, the wiki page nobody deleted. Retrieval over an uncurated corpus gives you confident answers sourced from documents that were wrong when they were written. What agents actually need is not more text. It is a model: which systems exist, what they do, who owns them, what depends on what, and which of several conflicting descriptions is the one the enterprise currently believes.

That is a very specific artefact. It has a name. We have been maintaining it for decades.

What EA already owns

Strip the ceremony away and an EA function owns exactly one irreplaceable asset: the only deliberately curated, cross-silo model of how the business hangs together. Application portfolio, capability map, data flows, ownerships, lifecycles, the dependency web between strategy and running software. HR knows people, finance knows money, the CMDB knows servers — only the architecture repository connects them into something with meaning across the silos.

Jeanne Ross and her co-authors argued twenty years ago that the point of enterprise architecture is a foundation for execution — an operating model made explicit enough to build on. The argument in Enterprise Architecture As Strategy has aged into something its authors could not have anticipated: an explicit operating model turns out to be precisely the grounding an autonomous system needs before you can trust it to act. The foundation for execution is now also the foundation for delegation.

But — and this is the uncomfortable part — it only counts if the model is machine-consumable. A repository that exists as diagrams-as-pictures, or as a beautifully formatted document library, is invisible to an agent. PowerPoint is where context goes to die.

From repository to ontology

The repositories that will matter in this transition share three properties, and none of them is exotic.

Graph-shaped, not document-shaped. The questions agents ask are relationship questions: what breaks if this is decommissioned, who owns the system this data flows through, which capabilities does this vendor contract actually underpin? Those are graph traversals. If your repository stores connected things — components, capabilities, people, data — as a queryable graph with a metamodel that mirrors your business rather than a framework diagram, agents can walk it. If it stores pictures of connected things, they cannot. The knowledge-graph and ontology vocabulary suddenly everywhere in vendor briefings is this observation wearing a new suit.

Alive, not archived. An agent grounded in stale context is worse than an ungrounded one, because its errors come with citations. The only repositories that stay current are the ones fed by automation — discovery from the cloud estate, the CMDB, the identity provider, deployment pipelines — with humans curating meaning on top: this is strategic, this is being retired, this conflicting record is the truth. Hand-maintained inventories die; the AI era just raises the price of the corpse.

Accessible as an interface, not an export. The emerging pattern — visible in open standards like the Model Context Protocol — is that agents consume context through well-defined interfaces at decision time, not through quarterly extracts. A repository with a real API becomes something you can hand an agent as a tool: before you act, ask the architecture. That phrase is worth sitting with. It describes a governance mechanism that operates at machine speed, which is exactly the thing review boards cannot do.

Who curates what the AI believes?

Here is the new governance question hiding inside all of this: once agents ground their actions in the repository, the repository stops being documentation and becomes what the AI believes about your enterprise. An error in it is no longer an embarrassing detail in a slide — it propagates into every automated decision downstream. Curation stops being hygiene and becomes a control.

This reframes the EA role in a way I find genuinely energising. The architect-as-librarian is dead; the architect-as-epistemologist — deciding what the enterprise’s machine-readable self-knowledge contains, how conflicts resolve, how fast corrections propagate — is a first-class engineering responsibility. Maher Dahdour’s Enterprise Architecture in the Age of Agentic AI circles the same territory from the discipline side: autonomy compounds, and whatever grounds that autonomy had better be governed like it matters.

A 90-day starter path

None of this requires a moonshot. It requires treating context as a product, starting embarrassingly small.

Weeks 1–4: pick one question. Choose a single high-value question agents or humans keep asking — “what does this application actually support, and who owns it?” is the classic — and make your repository answer it correctly, completely, via an API, for one domain. Not the whole estate. One domain, genuinely trustworthy.

Weeks 5–8: wire in freshness. Connect two or three automated sources so that slice of the model updates without anyone remembering to. Measure staleness explicitly — time since last confirmation is a perfectly good starting metric, and it turns “is the repository current?” from a vibe into a number.

Weeks 9–12: give it to a consumer. Expose the slice to one real AI use case — an internal assistant, a change-impact check in a pipeline — and watch what happens to data quality the moment the repository has a consumer that acts on it. Nothing improves an inventory like something downstream depending on it. Then expand domain by domain, following demand.

The teams that do this will spend the next decade owning the layer every enterprise AI initiative quietly depends on. The teams that keep shipping diagrams into slide decks will discover that the org found its context somewhere else — probably by letting the agents guess, which is how billing platforms get procurement requests. The repository was always meant to be a system of record for the enterprise’s structure. Its promotion to system of context is the most interesting thing to happen to this discipline in twenty years, and it is happening whether we show up for it or not.