Ask a room of enterprise architects what they think of their EA tool and you will hear the same complaint in a dozen variations: it cost a fortune, and nobody trusts what is in it. The recurring thread on every architecture forum — this month it was the top post on the EA subreddit — is not really about licence pricing. It is about the moment, six months after the big modelling push, when someone opens the repository, finds an application that was decommissioned last quarter still marked as strategic, and quietly goes back to asking people things in meetings. The tool did not fail. The upkeep did.
This is EA’s oldest problem, and it has outlived every generation of tooling that promised to solve it. The repository is a snapshot of the past pretending to be the present. I want to make the case that large language models are the first technology that plausibly changes the economics of keeping it current — and to be precise about where that claim holds up and where it falls apart.
Why every repository goes stale
The staleness is not a discipline problem, however much we like to frame it as one. It is structural, and it comes from two properties of manual modelling.
First, the repository is a secondary artefact. Nobody needs it to be correct in order to ship. The CMDB entry, the integration contract, the deployment pipeline — those break loudly when they drift from reality. An ArchiMate view breaks silently. Work that can silently rot always loses to work that visibly burns.
Second, the cost of currency scales with the rate of change, and the rate of change has left the building. A portfolio that shifted meaningfully once a quarter could be maintained by a small team doing interviews and workshops. A portfolio being reshaped weekly by product teams — increasingly with agents writing part of the code — cannot be documented by hand at any headcount you will ever be granted. I made a version of this argument about governance in architecture governance at agent speed; the repository is the same mismatch wearing different clothes.
The consequence is a doom loop. The model drifts, so people stop consulting it, so keeping it current stops being rewarded, so it drifts faster. Every EA tool migration I have witnessed was justified as a tooling problem and reproduced the loop within two years, because the loop was never about the tool.
What LLMs actually change
The interesting shift is not “AI draws diagrams now.” It is that the evidence of your actual architecture already exists in machine-readable form — code, infrastructure definitions, API gateways, CMDBs, contract documents, ADRs, incident reports — and LLMs are unreasonably good at reading exactly the messy, unstructured half of that evidence that parsers never handled.
The research is young but pointed. A 2026 study by Pagels, Hacks and Bemthuis had an LLM scan unstructured organisational documentation for indicators of EA debt — the architectural smells that normally surface only when an expert reads the documents. Notably, they got useful signal out of Llama 3.2 in its small 3B variant: this is not a capability that demands a frontier model, which matters enormously for running it continuously over an enterprise’s entire document estate. On the modelling side, a systematic review in Springer’s Discover Artificial Intelligence tested LLMs on enterprise modelling tasks and found they produce genuinely useful preliminary models and gather domain information well — a competent first draft, not a finished one.
Put those two capabilities together and a different architecture for the repository suggests itself. Not a canvas that humans populate, but a pipeline: extractors that continuously mine evidence sources, an LLM layer that proposes model changes (“this contract mentions a data flow to a vendor that is not in the model”; “these three ADRs describe a service the portfolio does not contain”), and the repository as the reviewed output. The model stops being something you write and becomes something you accept — closer to a pull-request queue than a drawing tool. It is the repository-shaped version of the shift I described in from system of record to system of context.
The trust problem
Here is where the honest version of this essay diverges from the vendor version. The same Springer review that found LLMs useful for first drafts also found them producing models that violated basic BPMN sequencing rules, omitting stakeholders that every human expert included, and — worst of all — presenting incorrect details confidently. Its conclusion was blunt: LLMs cannot replace domain experts in modelling the enterprise as it is. They are a supporting tool.
For a repository, confident wrongness is the fatal failure mode. A stale model at least fails predictably — everyone knows the last big update was in March. A hallucinated model fails randomly, and one discovered fabrication poisons trust in every entry around it. An auto-generated repository that is 95% right and silent about which 5% is wrong is worse than the stale one it replaced.
So the design constraint is not extraction quality. It is provenance. Every generated assertion needs to carry its evidence — the source document, the code reference, the CMDB record — and its confidence, and the human review queue needs to be the only door into accepted state. High-confidence, low-impact changes might flow through on spot-check sampling; anything touching the views that decisions actually rest on gets eyes before it lands. This is the same architecture as agentic governance: automate the flow, reserve humans for the irreversible.
Where to start, pragmatically
Nobody should try to boil the whole metamodel. The tractable first slice is the application portfolio — the inventory of what exists, who owns it, and what talks to what. It has the richest machine-readable evidence (CMDB, gateways, IaC, contracts), the most painful staleness, and the clearest ground truth to measure against.
Start with one pipeline and one metric: detected drift — how many discrepancies between evidence and model the pipeline surfaces per week, and how long they take to resolve. That number does two jobs. It proves the machinery works, and it quantifies for your leadership something EA has never been able to price before: how wrong the map was all along.
What it means for the tool market — and for you
If the repository becomes a pipeline output, the centre of gravity in the EA tool market moves. The moat stops being the modelling canvas and becomes the evidence connectors and the review workflow — and incumbent vendors know it, which is why every roadmap suddenly has an AI assistant on it. When you evaluate those features, ask one question: show me the provenance of a generated statement. A tool that generates without evidence attached has automated the creation of plausible fiction, and you already had a backlog of that.
For architects, this is the opposite of a threat. The dreariest part of the job — chasing people to confirm what is already true — gets automated. What remains is the part that was always the actual job: deciding what the map means, and what to do about it. The repository finally becomes what we always claimed it was. Not a deliverable. An instrument.