The Room AI Cannot Be In
In Edition 2 of this newsletter, I wrote about AI in architecture work. Not the hype, the application. Where AI is genuinely useful across the solution definition lifecycle. Where architects must stay at the controls. And the people dimension of adoption across a diverse team.
That edition was about what AI can do. This one is about what it is revealing.
Because as AI has become more capable of producing the technical and functional outputs that architects have historically spent their time on, the options papers, the decision records, the requirements synthesis, the architecture documentation, something has become visible that was always there but never acknowledged as a differentiating skill.
The most consequential architecture work has evolved into something that no prompt can replicate. It was not always this way. The role has shifted, from technical specialist, to techno-functional practitioner, to something that is harder to name but easier to recognise. The architect who operates in the room. Who reads what is underneath the conversation. Who navigates the organisation as fluently as the technology.
AI can produce the document. What it cannot do is replace where an architect really adds value. And the gap between those two things is where this edition lives.
Two examples. Neither of them is about technology. Both of them are about what happens when the architecture work is done and the real work begins.
The intervention nobody planned for
A decision had been made by another function within the same matrix. Approved through their governance. Signed off by their senior architecture leadership. From inside their boundary it was a valid decision, a solution to a problem they owned, reached through a process that followed the model.
What the decision required was building on a platform owned and managed by a different function entirely. A platform with its own strategy, its own direction of travel, and its own active programme of work to move away from the very foundations the decision would have built upon. The decision had been made for a platform that wasn’t theirs to decide for.
And what it would have required was the rebuilding of legacy code that had been deliberately decommissioned from that platform, code removed for good reasons, by people who understood where the platform was going, as part of a strategy that was actively being executed. It was wrong for the function that owned the platform. And it was wrong for the enterprise.
Seeing that required operating across boundaries that the matrix had drawn between functions. Understanding both contexts well enough to recognise the collision before it happened. And then navigating, across organisational lines, across competing agendas, across a governance structure that had already approved the decision, to prevent an enterprise-level error from being locked into implementation.
This is where the AI observation lands most directly. If each function had used AI to produce their architecture recommendations independently, which is exactly what would happen in a matrix organisation, both outputs would have been internally coherent, well structured, and technically sound within their own context. The conflict would have been invisible until implementation. What made it visible was a human operating across the boundary with enough contextual knowledge to see what neither function could see from inside its own lane.
The intervention succeeded. The decision was redone. The other function probably still smarts from it. But zooming out it was the better enterprise decision. And no document, however well produced, would have produced that outcome. What produced it was judgment, relationship, and the willingness to intervene across a boundary that the organisation had drawn precisely to prevent that kind of interference.
The decision that had to be defended
A programme was underway to introduce a significant new capability into an existing platform estate. The architecture recommendation had been through the full process, assessed, challenged, and approved through the appropriate governance. It followed established guardrails set at the enterprise level. It was the right decision for the long term sustainability and growth of the platform.
And then it was challenged again.
Not on technical grounds. Not with a better architectural argument. But by a senior stakeholder who wanted the decision reversed in favour of an approach that would have embedded the new capabilities differently, an approach that simplified the complexity in their own mind but did not reflect the reality of the platform or the organisation’s longer term direction. The challenge was grounded in a limited understanding of how the platforms worked and how the organisation was structured to deliver. It was compounded by dynamics that made constructive dialogue difficult to maintain, an environment where positions had hardened before the reasoning behind them had been properly examined.
What followed was not architecture work. It was navigation. Conversations with the business to ensure the decision was understood at the right level. Enlisting senior support to influence one level up. Formal escalations. Eventually the decision was affirmed, not because the governance model worked, but because the right people were brought to the right conversations in the right sequence.
The technical and functional work that underpinned the decision took eight weeks. Defending it took twelve more.
AI could have produced every document in that process. The options paper. The decision record. The escalation summary. None of that was the work. The work was knowing which conversation to have, with whom, in what order, and what each person in the room needed to hear before the decision could hold.
That is the room AI cannot be in. Not because the room is technical. But because what happens in it is not a skill that can be prompted.
The architect role has never been static.
It began as a technical discipline. Deep platform knowledge, system design, technology selection. The architect as the person who understood the stack most completely and could make the decisions that others couldn’t. Technical depth was the differentiator. It was what the role was hired for, developed for, and measured against.
Then it evolved. The architect who could only speak technology became less useful than the architect who could translate between technology and business. Functional understanding, the ability to take a business requirement and shape it into an architectural response, became as important as technical depth. The role became techno-functional. Still grounded in the technology. But operating across the boundary between what the business needed and what the platform could provide.
And then it evolved again. The architect who could design and translate but couldn’t navigate the organisational reality of large programmes became a liability as much as an asset. Good decisions on paper that couldn’t survive the political environment they were made in. Sound recommendations that went nowhere because the architect didn’t know which stakeholder needed to be in which conversation before the decision could hold. The role began to demand something that no technical or functional training had prepared anyone for, the ability to operate inside the organisational complexity of large scale delivery. To read rooms. To navigate agendas. To intervene across boundaries. To know when to hold a position and when to find a different route to the same outcome.
That evolution happened gradually. And it happened without being named. The architects who developed that capability did so through experience, through scar tissue, through years of operating in environments where the technical and functional work was necessary but not sufficient. It was never acknowledged as a differentiating skill. It was just what the good ones did.
AI is changing that.
By automating a meaningful portion of the technical and functional uplift, the documents, the options papers, the decision records, the requirements synthesis, AI is making the invisible visible. What remains is the non-producible. And the non-producible turns out to be exactly what the two examples in this edition describe.
The contextual judgment that determines which problem is worth solving. The political navigation that determines whether a correct decision survives long enough to be implemented. The cross-boundary intervention that prevents an enterprise-level error before it materialises.
These were always the differentiating skills. They are now the visible ones.
Which raises the question that organisations have not yet fully confronted.
If AI is producing the technical and functional outputs that architects have historically been hired, developed, and measured for, what are we hiring architects for now? And are the ways organisations currently identify, develop, and retain architectural talent fit for a role that is being clarified into something different from what the hiring criteria, the career frameworks, and the performance measures were designed to assess?
The organisations that ask that question seriously will develop architects differently. They will hire for judgment and navigational capability alongside technical depth. They will create the conditions for architects to develop the skills that can only be developed through operating in complex environments, not through training programmes or certifications, but through exposure, through sponsorship, through being given the space to navigate and intervene and occasionally get it wrong.
The organisations that don’t ask it will continue to optimise for a version of the role that AI is quietly making less relevant. They will measure document quality and delivery speed. They will mistake the acceleration of output for the development of judgment. And they will find, gradually, that the architects who understand what the role is becoming are leaving for environments that do.
The architect of the next decade is less a technical producer and more a judgment practitioner. Someone who uses AI to accelerate the expression of their thinking and spends the time that frees up doing the thing AI cannot do.
Operating in the room. Navigating the organisation. Intervening across boundaries. Holding the line when it needs holding.
And reading the agendas underneath the agendas.
