Why Most EA Repositories Are Too Stale to Feed an AI Agent

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

An agent over a stale repository is worthless: garbage context in, confident nonsense out — the battle is acquisition, not exposition.

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

• Primary query focus: Why Most EA Repositories Are Too Stale to Feed an AI Agent
• Decision scope: strategy, governance, operating model, and execution constraints
• Expected output: clear next actions with ownership and measurable indicators

Everyone is racing to expose the repository. Almost no one checks if it is alive.

The pitch is everywhere now: "talk to your architecture." Ardoq, Bizzdesign and a dozen others are wiring AI agents to the enterprise architecture repository so a CISO or a CIO can ask a question in plain English and get an answer back about the whole estate. It is a genuinely good idea — and it rests on an assumption almost nobody states out loud.

The assumption is that there is a populated, accurate, current repository on the other end of that connection. In most organizations, there isn't. And that single gap is the difference between an AI agent that is useful and one that is quietly, confidently dangerous.

This piece is about that gap. The argument is simple and uncomfortable: an MCP server over a stale repository is worthless. The market is competing on context exposition — the protocol, the integration, the "talk to" demo. The real battle is context acquisition: keeping the model alive. That is the harder problem, and it is the one that decides whether any of this works.

The market's dirty secret: most repositories are already too stale

Walk into a typical enterprise and look honestly at the EA repository. By most industry estimates, the great majority of them — a figure often put at around nine in ten — are in one or more of these states: incomplete, twelve to eighteen months out of date, hand-maintained by one or two people, and disconnected from the systems that actually describe the running estate. This is not a precise audited statistic and we will not present it as one; it is the consistent, observed pattern across analyst commentary and practitioner experience. Treat it as a directional truth, not a citation.

The reasons are structural, not a failure of any one team. Repositories are populated in a project burst, then maintenance falls to manual updates that compete with everyone's day job. The estate keeps moving — cloud migrations, decommissions, shadow IT, mergers — while the model sits still. Drift is the default state of an enterprise architecture repository, and it sets in fast.

For human consumption this has always been tolerable. An architect reading a two-year-old diagram knows to distrust it, cross-checks with the team, fills gaps from memory. The repository was a starting point for a conversation, not the final word. That tolerance is exactly what breaks when you put an agent in the loop.

Why agents don't just inherit the staleness — they amplify it

A language model has no instinct for freshness. Hand it a record and it will reason over that record as though it were true, then express the conclusion in fluent, confident prose. It does not hedge because the data is old; it does not know the data is old. The staleness that a human silently discounts, an agent silently launders into a clean, authoritative-sounding answer.

That is the amplification. A wrong fact buried in a forgotten spreadsheet is inert. The same wrong fact, retrieved by an agent and delivered as "the application has no upstream dependency on the legacy payments core, so decommissioning is low-risk," is now an input to a decision — phrased with exactly the confidence that makes people stop double-checking. Garbage context in, confident nonsense out.

The danger scales with how good the agent sounds. The better the writing, the more the freshness problem hides behind it. A clumsy answer invites scrutiny; a polished one invites trust. So the worse your repository's freshness, the more an articulate agent works against you — not for you.

"Talk to your architecture" assumes a populated, fresh repository that rarely exists

Read the incumbent demos carefully and you will notice they all run on a beautifully complete, current model — the vendor's reference dataset, or a customer environment curated specifically for the demo. The capability map is full. The dependencies are wired. The application portfolio is current. Of course the agent gives a brilliant answer; it is reasoning over a repository in a state that almost no production environment is actually in.

There is nothing dishonest about a clean demo. The problem is the silent leap from "the agent answers well here" to "the agent will answer well on your repository." That leap is only valid if your repository is as alive as the demo's — and the whole point of the previous section is that it usually isn't.

So the right question to ask any vendor selling you "talk to your architecture" is not how good the conversation is. It is: what keeps the model behind this conversation true? If the answer is "your team maintains it," you have bought a faster interface to your own staleness.

What a living, agent-ready repository actually requires

"Living context" and "agent-ready repository" are not slogans — they describe a concrete, demanding standard. Three things separate a living repository from a snapshot, and a repository that lacks any of them is not ready to be the ground truth for an agent.

First, continuous reconciliation against the sources of truth. The model should be checked, automatically and often, against the systems that describe the real estate — the CMDB, the cloud inventory, the deployment pipelines, the field. Reconciliation is not a one-off import; it is a standing process that surfaces where the model and reality have diverged so the gap can be closed instead of forgotten.

Second, ownership. Every element — each capability, application, dependency — needs someone accountable for its accuracy, not a vague collective responsibility that means no one looks. Ownership is what turns a detected drift into a fixed fact.

Third, freshness signals. The repository should carry, per element, when it was last verified and against what. This is the quiet superpower for agents: a model that knows its own freshness lets an agent say "this dependency was confirmed six days ago" or, just as importantly, "this hasn't been verified in over a year — treat it with caution." An agent that can flag its own uncertainty is worth far more than one that always sounds sure.

• Continuous reconciliation vs source systems — drift detected and closed, not accumulated
• Clear ownership per element — accountability for accuracy, not collective neglect
• Freshness signals per element — so the agent knows, and can say, how much to trust each fact
• A structure built to be reconciled, rather than a document that is populated once and decays

Acquisition is the hard part; exposition is the easy last mile

Step back and the competitive picture inverts. Adding MCP — exposing the repository so an agent can query it — is the easy, commoditizing part. It is a protocol; it will be a checkbox on every EA tool within a year. Exposition is the last mile, and last miles are not where moats live.

Context acquisition — populating, continuously reconciling and governing the model so it stays true — is the hard part, the slow part, the part that actually determines whether "talk to your architecture" produces insight or hallucination. This is where the real engineering and the real value sit. It is unglamorous: integrations, reconciliation logic, ownership workflows, freshness tracking. It does not demo as well as a chat box. It is also the only thing that makes the chat box trustworthy.

We will be honest about our own position here, per our own discipline. ArchiLU is building toward continuous, sovereign context — that is our conviction and our direction, not a shipped magic button. We do not claim an auto-populator that keeps your repository fresh while you sleep; anyone who claims that is selling the easy story. What we are committed to is the harder one: an enterprise context layer that is acquired and kept alive under your control and EU data residency, structured so reconciliation is possible rather than left to manual heroics. That is the work. We would rather tell you it is work than pretend it is magic.

How to assess your own repository's readiness before you wire up an agent

Before you connect any agent to your architecture, run a five-minute honesty test. Pick five business-critical applications. For each, answer three questions: When was this element last verified against reality? Who is accountable for its accuracy? Does its recorded dependency graph still match what production actually does today?

If you can answer all three for most of the five, you have the beginnings of an agent-ready repository — and exposing it to an agent will likely create value. If you cannot answer the first question for most of them, stop. You do not have a living context layer; you have a document. Connecting an agent to it will not surface that problem — it will hide it behind confident prose, which is the worst possible outcome for a regulated institution that has to defend its decisions.

The constructive move is to treat readiness as the project, with exposition as the reward at the end of it. Decide what "verified" means for your context, assign ownership, stand up reconciliation against your real sources, and only then turn on the agent. Build order matters: context first, then the conversation. If you want a structured starting point, our free EA Maturity Assessment scores ten dimensions in about ten minutes and will tell you, honestly, how far your repository is from being something an AI agent can safely trust.

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