Enterprise architecture as a translator between business, technology, and AI agents
Today, architecture is taking on an active role in the process, moving away from being just a decision-support tool, distant from execution.
I read a LinkedIn post claiming that the architect's role changes based on the size of the organization they work in. In startups, a large part of their work is technical—meaning programming—whereas in larger companies, this role evolves into that of a generalist strategist, someone capable of guiding decisions by looking at the big picture.
This is where the classic vision of enterprise architecture comes in as the bridge between business and technology, the peak of this perspective. Today, we can say a new player has joined the equation. It is no longer just about connecting business with technology. Now, technology itself is separating into traditional systems and the "agentic" view brought by the latest evolution of artificial intelligence (AI). And that completely changes the practice.
AI does not understand PowerPoint presentations. Or rather, it does, but not in the way traditionally expected. As a tool for accelerated development through agents, AI does not understand a roadmap on a slide, an architecture committee, an organizational chart, or architecture documentation—which is hopefully only slightly outdated.
What it does understand is structured context, formed by explicit rules, measurable constraints, and operational limits. In short, clear specifications. If this isn't provided as part of the process, it improvises. And when it improvises in production, the cost is real. That is where modernized and updated enterprise architecture becomes critical again.
In the traditional view, an architect interacts with business stakeholders, information technology (IT), security, infrastructure, and product. However, this view is now falling short. Today, we must include development copilots, agents that write code, agents that generate decisions, and autonomous workflows. These latest guests to the party are not tools, but active actors in the software value chain. And if they are actors, they must be treated as such.
In a cybernetic engineering model, where development is enhanced by the integration of human judgment and agentic speed, the acceleration is brutal: product specifications in the traditional model—user stories—become specifications co-created with agents. Development cycles go from weeks to hours, with quality and documentation ensured, among other examples.
But if there is no clear framework of structured specifications, versioned rules, traceability between decisions, and automatic validations, what we are accelerating is not value, but complexity.
We used to think of architecture as a way to accelerate and align decision-making by people, which is why the focus was on being clear when communicating to different audiences. However, our new audience requires a different way of communicating, where documentation is often not even necessary. Is there anything clearer about how a system works than its code, if we know how to understand it? AI can already do that, and very well.
Changes in Enterprise Architecture
Today, architecture takes on an active role in the process, ceasing to be a decision-support tool distant from execution. Faced with this scenario, architecture must first become formal—and governed—contracts, so agents do what they are expected to do, through the design of standard rules, skills, and logic that standardize how agents function. "Cursor rules" or "Claude code memory" are good examples.
At the same time, what we expect the system to do must be represented in specifications readable by models and understandable by humans. This is where methods like "Spec Driven Development"—a software engineering methodology powered by AI that prioritizes writing detailed, structured technical specifications before writing or generating code—play a major role.
Finally, it must become a structured organizational memory, automatically guided by the most reliable source of truth: source code, infrastructure configuration, and automated business flows. In other words, architecture must become executable, not just as code, but as a governance system for decisions made by humans and agents.
Faced with this new reality, a question arises. If agents design, implement, evaluate, and recommend, who governs the agents? Today, many organizations use isolated copilots, which is good news for scale. But without traceability, versioning of rules, or control of alignment with strategy, that is a structural risk.
If we add traceability between business requirements and decisions generated by AI, along with systematic impact and risk assessment, we get the new architecture decision governance system, without bureaucratic burden, but as architecture adapted to a world where systems also decide.
If we don't redesign the way we govern decisions and IT assets in organizations, every team will have its own prompts, every agent will operate with partial context, every decision will be difficult to audit, and technical debt will grow exponentially. AI will not generate chaos, but it will amplify the chaos that already exists. At this moment, we should no longer ask ourselves whether to use agents or not, but think: Do we have an architecture capable of governing them?
