AI built into an EA tool knows that tool's repository. Most EA questions cross several systems, the tool's pricing was built for seats and applications rather than long agent runs, and practitioners still can't trace an answer back to its records. These limits come from where the AI sits, so a new release rarely removes them. Know them before you plan your team's AI work around the tool's assistant.
This isn't an argument against EA tools. The repository is the governed record of the enterprise, and it matters more as agents read it. The argument is about where the AI that does the work should sit.
1. It sees one repository
An EA tool's assistant reads its own repository well: the fact sheets, the relations, the metamodel. The questions that reach an EA team rarely stay there:
- a retirement shortlist needs the repository's TIME calls and the CMDB's view of what actually runs;
- a renewal review needs vendor contract dates;
- a shadow-AI sweep needs every agent platform's inventory;
- a root-cause question needs change and incident records.
The usual answer is an integration that copies part of another system into the repository. Integrations sync a subset, on a schedule, and the repository's answers are only as good as those feeds. So the assistant answers confidently about the part of the estate it can see.
2. Its pricing wasn't built for agent work
EA tools are priced by seats or by the number of applications. When questions arrive through an assistant, seats stop measuring use, and agent work costs real inference. Vendors have answered in three ways, and each has a catch:
| How AI is priced | What it means for a long agent run |
|---|---|
| Included, without limits | The vendor pays for inference. Hour-long agent runs are expensive, so expect caps, shallower agents or new terms at renewal. Check that "unlimited" covers features released after you sign. |
| Credits or consumption units | Cost follows use, but a shared pool can drain when many casual users ask questions, and next year's bill is hard to forecast. |
| Bring your own model key | The bill is visible and on your provider contract. You need that contract, and you pay for every run. |
Ask any vendor one question: how is a two-hour portfolio analysis priced?
3. You can't trace the answer
Architects say the same thing about AI answers: they read well, and they can't put them in front of a steering committee. The reasons are concrete. The answer doesn't say which records each figure came from. Nothing checks a figure against the record. When the evidence is thin, the model writes something plausible instead of saying so.
Checking is a mechanism, not a promise:
- match every cited value against what the source returned, and mark it verified, mismatched or unverified;
- let a recommendation rest only on verified evidence;
- refuse a judgement that falls under a confidence floor, with the reason, instead of guessing.
Few EA tools do any of this today.
4. AI lands in the newest product first
Several EA vendors carry more than one product, often from acquisitions, and some are building an AI-native successor beside the product customers run. AI goes where it is easiest to build: the new product. Customers on the established one wait, or plan a migration they didn't budget for.
5. The data model is too rigid, or it drifts
A fixed metamodel makes a repository quick to start and consistent, and it strains when a new kind of thing arrives: AI agents, data products, platform teams. A flexible one takes anything, and over years it drifts into conflicting types and ad hoc relations. Agents amplify both problems. They can't use what the model can't express, and they repeat what the drift has made inconsistent.
Eight questions to ask about an EA tool's AI
- Which systems can the AI read besides your repository, and how fresh is that data?
- How is a two-hour agent run priced, and does "unlimited" cover features you release next year?
- Can every figure in an answer be traced to the record it came from?
- When the evidence is thin, does it refuse or guess?
- Can we bring our own model provider, and where does inference run?
- Does your MCP server expose everything your AI can read, so our own agents can use it?
- Can we test it on our own estate, with our own questions and known answers, before we sign?
- Which of these features are in the product we run today, and which are in the next one?
Where an agent layer fits
Keep the repository as the system of record, and keep it clean. Put the work that crosses systems in a layer above the tools: one that reads each system through its MCP server, matches records with evidence, checks every figure, refuses under uncertainty and runs for as long as the question needs. Whoever builds that layer, your own team or a vendor, hold it to the eight questions above.
How much the layer matters can be measured rather than argued: EA-Bench asks AI systems 17 questions EA teams get, on an estate where the answers are planted, and publishes the questions and the scoring rules so you can run them on your own assistant.
Get the 17 questions, and the results when they're out
The questions EA teams get, what a right answer contains and the traps that should fail it. Run them on the AI you use today.