On Friday afternoon, an online store’s AI agent is tasked with increasing weekend sales. It creates offers and launches a campaign. Customers respond, and sales accelerate. On Monday morning, the team discovers a positive problem: there are more orders than the warehouse can process. Customer service later has to explain delayed deliveries. In the warehouse, success is celebrated with overtime.
The scenario is familiar to enterprise architects: improving one function can create problems elsewhere, and the consequences may only become visible afterwards. With agents, those problems can compound much faster.
Vladislav Ivanov opened this blog series by asking what happens to architecture work when producing an understanding of the whole becomes cheaper. He also identified a new bottleneck: as descriptions become faster to create, a growing share of the work shifts to verifying their accuracy. When agents carry out operational work, architecture information has a user that acts exactly on the information it has been given.
Making dependencies visible to agents
Now consider a factory. A maintenance agent detects the early signs of a bearing fault in sensor data. A spare part is in stock and a technician is available on Tuesday, so the agent recommends maintenance. The bearing can be replaced before the predicted failure. From a maintenance perspective, the proposal looks entirely sound.
But the production asset serves two production lines. One is fulfilling an urgent customer order, and a shutdown is already planned for Wednesday. If the bearing can last until then, the repair can be completed during the scheduled shutdown and an additional interruption avoided. Waiting one day would spare production an unnecessary stoppage.
The agent needs information about the machine’s dependencies and an up-to-date production plan. It could use the architecture model to identify which production lines the machine serves, then retrieve their status from the production system. For the maintenance team, the issue is a bearing. For production, it is a customer delivery. The agent must understand both. That is why it needs visibility into the dependencies described in the architecture model.
Some decisions still require judgement
Information alone does not solve the problem. Even if the agent sees the impacts correctly, someone must still assess their significance. Is it worth accepting the risk of bearing failure, or should the customer delivery be put at risk? What level of cost is acceptable? Whose objective can be compromised?
The workflow must define what the agent may do independently and when the matter must be escalated to a human decision-maker. The maintenance agent can prepare the work order. The timing of the production stoppage is confirmed by the person responsible for production, who has the authority to weigh the delivery commitment against the risk of failure. Writing “remember to ask for permission” in a prompt is a weak control mechanism. Approval must be a genuine condition in the workflow. The system must prevent confirmation of the work order until the decision has been made.
Governance must be built into the workflow
In the previous part of the series, Timo Laine described the production line for AI-assisted architecture work. It needs usable information, clearly defined technology boundaries and clear limits on data processing.
The same principle becomes even more important in workflows for agents that operate within the organisation. Here, the production line becomes binding: the agent can do more than read information – it can initiate tasks or write changes back to systems. Workflows therefore need technical guardrails and approval points.
Architecture becomes operational knowledge
At the same time, the role of the architecture model changes. It is no longer merely a description of the organisation for people to read. An agent uses it to identify dependencies, the workflow uses it to define decision points, and a person uses it to resolve the conflicts made visible.
Retrieval based on structured information can use relationships between entities to uncover information that text search alone cannot reach [1]. The accuracy of the architecture model then has a direct impact on how the agent operates.
Trust requires verification
When architecture information updated with AI becomes the basis for an agent’s actions, the accuracy of those updates must be verified.
At Gofore, we have tested several AI use cases. In one experiment, AI was asked to assess how a legislative amendment would affect a public agency’s architecture model. It first read the ArchiMate model and its structure, then analysed the amendment and proposed changes. An architect reviewed the proposals before the workflow wrote the approved changes back to the model.
The experiment showed that element types and relationships in the model can be checked programmatically, while interpreting the substance of legal change still requires expert judgement.
Research on identifying architecture problems also highlights the need for expert review [2]. In a study using synthetic documents, a locally run language model produced a high number of false positives. A cloud-based comparison model found only around one quarter of the problems planted in the material, although most of its findings were correct. The researchers recommend using the results as a preliminary screening step reviewed by an architect.
When verification is built into the workflow, the effort it requires also becomes visible. Organisations can then assess separately how much time the system saved and how much expert work was needed to review its outputs.
Building a shared understanding of dependencies
In Finnish public administration, some of the foundations for this kind of information base already exist. The Act on Information Management in Public Administration requires information-management entities to maintain an information-management model. The model must describe the purposes and responsibilities of operational processes, their links to other processes, and the connections between information resources, operational processes and information systems [3].
Yet the model may have remained little more than documentation created to meet a legal obligation. From an agent’s perspective, an up-to-date information-management model can provide the starting point for a dependency map. It can help identify which processes, information and systems a planned action will affect.
It also makes it possible to assess whether the model describes current operations accurately enough. A real-time view like the one in the factory example additionally requires connections to operational systems. The information-management model is a first step because it brings the links between processes, information and systems into one place.
Enterprise architecture in the age of AI agents
Not all required information will ever be found in architecture descriptions. Some of it must still be gathered from people who understand how the organisation operates. When this tacit knowledge is uncovered, it should be captured in a shared model. Otherwise, the same issue must be investigated again when the next change arises.
When an agent prepares an administrative decision, that decision is still made by the competent public official under official accountability. They must be able to understand the grounds for the decision and assess its consequences. The architect’s role is to help build the whole picture so those consequences can be seen before the decision is made.
Let us revisit the online-store example. This time, the agent recognises that the planned campaign exceeds the warehouse’s delivery capacity and brings the conflict to the business owner before the offers are published. The decision is supported by current data on warehouse capacity and the campaign’s estimated impact.
In the first scenario, the agent saw only sales. In the second, it also saw the consequences of the decision because the organisation had made its dependencies visible.
Even when an agent optimises its own task, responsibility for the whole remains with the decision-maker. Enterprise architecture must therefore make visible the dependencies without which a sound decision cannot be made. As agents become more common, the value of architecture work will increasingly come from making those dependencies visible before decisions are taken.
References
[1] Peng, B., Zhu, Y., Liu, Y. ym. (2026). Graph Retrieval-Augmented Generation: A Survey. ACM Transactions on Information Systems, 44(2). https://dl.acm.org/doi/epdf/10.1145/3777378
[2] Pagels, C., Hacks, S. & Bemthuis, R. H. (2026). Large Language Models for Analyzing Enterprise Architecture Debt in Unstructured Documentation. Proceedings of the 41st ACM/SIGAPP Symposium on Applied Computing (SAC ’26), 815–822. https://dl.acm.org/doi/epdf/10.1145/3748522.3779725
[3] Act on Information Management in Public Administration (906/2019), section 5. Finlex. https://www.finlex.fi/fi/lainsaadanto/2019/906#chp_2__sec_5
Gofore’s architecture experts help organisations build sustainable architecture capabilities, leverage AI responsibly and create a strong foundation for long-term transformation.
