What changes in the EA tool when agents do the work

Enterprise architecture tools are moving from the place where architects work to the place agents read from. Questions now arrive through company-wide assistants and agents, and they cross the EA repository, the CMDB, the delivery tracker and the agent platforms. The repository keeps its job as the governed record. The analysis, the reconciliation and the decision drafts move to a layer above it, and EA teams should choose where that layer sits on purpose.

What changed this year

Within twelve months, the large EA vendors all moved toward agents, and said so in public:

• One made its MCP server generally available, so any MCP-capable assistant can query its fact sheets, reports and architecture decisions, and said that hundreds of customers were already querying their landscapes that way.
• Another relaunched as an AI-first platform, with ready-made and custom agents, and bought a graph database for time-aware, provenance-tracked queries.
• A third launched a visual workspace with AI agents that sits on top of EA and portfolio data.

Read together, these say one thing. The vendors expect more of the work on their data to happen through agents, and some of it outside their own screens. Architects see the same shift from the other side: a CIO's question now reaches the EA team through a company-wide AI assistant as often as through the EA tool.

Does the repository go away?

No. It matters more. An agent answering "what does retiring this platform touch?" needs governed records: stable ids, owners, lifecycle phases, and the relations between applications, capabilities and IT components. A repository holds those, and no assistant can make them up.

Two things change:

• Who reads it. More of the reading is done by agents through MCP servers and APIs, and less by people in the tool's own screens.
• What poor data costs. A person who reads a stale owner notices it. An agent repeats it in a board paper. Gaps a team has tolerated for years become errors in front of a steering committee.

What moves out of the tool

The questions that reach an EA team rarely stay inside one system:

• "Which contracts renew next year for applications we plan to eliminate?" needs the repository's TIME calls and the vendor contract dates.
• "Where do our EA repository and our CMDB disagree on owner, criticality and cost?" needs both systems, record by record.
• "Which AI agents touch customer data but aren't in our repository?" needs every agent platform's inventory and the repository.
• "Draft our DORA register of information for this critical function" needs the path from function to capability, application, IT component and provider.

A mid-sized estate is large. 1,200 applications come to about 8,000 records in a typical EA repository, before the CMDB's services and configuration items and the delivery tracker's epics. Answering across that is a job: read in bulk, join across systems, recognise one application under three names, compute, and check every figure. It takes many steps, and sometimes an hour. That job is what moves out of the tool.

Three places the work can land

All three are reasonable, and many teams will use more than one. The mistake is to let the choice happen by default, because an assistant was already installed.

What should an EA team do now?

1. Treat the repository as a product that agents consume. Owners, lifecycle, criticality and cost filled in; ids stable; relations consistent. Reconcile it against the CMDB before any AI project, because every gap turns into an answer.
2. Decide where answers get checked. An answer that goes to a forum should show which record each figure came from, and refuse when the evidence isn't there. Ask for that before you buy, whoever you buy from.
3. Measure on your own estate. Run ten real questions with known answers through any assistant or agent you are considering. A vendor's ROI figure describes someone else's estate. Our 17-question kit is a starting point.
4. Budget AI by the job. Seats and application counts don't measure agent work. Know what a portfolio review or a register draft costs to run, and who pays the model bill.
5. Govern agents the way you govern applications. Agents have owners, data access, capabilities and lifecycles. They belong in the architecture, with the same sweeps for what is unregistered or duplicated. See the AI-agent governance checklist.

The repository's new job

The EA tool doesn't disappear. Its job narrows and matters more: it becomes the governed context every agent in the enterprise reads, and its quality sets the ceiling on every answer built on it. The architect's job moves with it, from maintaining diagrams to deciding which questions agents may answer, from which records, and how those answers are checked before anyone acts on them.

Whether the layer above the repository matters can be measured. EA-Bench asks AI systems 17 questions EA teams get, on a generated 1,200-application estate with the answers planted, and publishes the questions and the scoring rules.