A few months ago I was in a workflow automation demo. Standard stuff on the surface, intake form, processing logic, output to a downstream system. Except this one had an AI agent sitting in the middle. The agent wasn't executing a decision tree. It was reading context, making a judgement call, and handing off to a human only when its confidence fell below a threshold.
The demo was clean. The integration looked tidy. But I couldn't stop thinking about one question: "who designed the handoff"
Not the technical handoff, the API call, the webhook, the queue. I understood that immediately. I mean the "decision" about when the machine should stop and the human should take over. Who decided what "low confidence" meant in this context? What was the cost of a wrong handoff , too early, too late? How would you know if the threshold needed adjusting six months into production?
Nobody in the room had a good answer. And that's when it landed: we were building AI into systems using the same thinking we used to build software into systems. Those are not the same problem.
That moment sent me down a rabbit hole I haven't climbed out of yet , not as someone who saw this coming, but as someone who realised they needed to catch up. This series is that catch-up, done in public.
What Traditional EA Gets Right , And What It Was Never Built For
Enterprise architecture, at its best, is about clarity. You make the invisible visible. You draw the map so the organisation can navigate. You define boundaries between systems, the flow of data, the points of integration. You create a shared language between engineering and the business.
That discipline is still valuable. It doesn't go away. If anything, it becomes more important when AI is involved , because the surface area of "things that can go wrong in non-obvious ways" expands dramatically.
But traditional EA was built for deterministic systems. Systems that, given the same input, produce the same output. Systems where a bug is a bug , something broke, you find it, you fix it. Systems where the architecture diagram is a reasonably accurate map of what the system actually does.
AI systems are not deterministic. The same input can produce different outputs. There is no single "bug" when a model starts drifting , it degrades gradually, often invisibly, until something downstream breaks and you trace it back. The architecture diagram can be technically accurate and still completely miss what the system is actually doing in production.
This isn't a criticism of AI. It's a statement about fit. The tools we reach for when we think "architecture" were forged in a different era. Some still apply. Many need rethinking.
Automating a Task vs Delegating a Decision
Here's the distinction that sharpened everything for me.
When you automate a task, you encode existing human logic into a system. A human used to do X manually. Now a system does X the same way, faster and at scale. The intelligence is still human , you've mechanised the execution. If it breaks, you fix the code. The human logic was never really transferred; it was translated.
When you delegate a decision, something different happens. You are trusting the system to reason. To weigh context. To arrive at a conclusion that wasn't pre-specified. The system isn't executing your logic , it's developing its own, within the boundaries you've set.
For most of my career I've been part of that , we called things AI that were really just smarter automation. A chatbot that routes queries. A classifier that tags records. A recommendation engine that surfaces options. These are useful, genuinely AI-powered, and I've architected plenty of them. But they are not the same as what agentic AI introduces.
Agentic systems delegate decisions. They act on your behalf, across time, across systems, without requiring a human to approve every step. They have goals, not just instructions. That changes the architecture problem completely , because you are not designing a system. You are designing an agent's environment: the constraints, the permissions, the feedback loops, the escalation paths, the audit trail. All of it has to be intentional.
Why 24 Years Helps , And Where It Creates Blind Spots
Long experience in technology is a genuine asset when navigating AI. The pattern recognition is real. I can look at an agentic workflow and immediately see where the coupling is too tight, where the failure modes are being ignored, where the vendor is papering over an integration problem with a demo that will never survive contact with a real enterprise data layer.
But long experience also creates specific blind spots.
The biggest one: the instinct to contain. When something is new and uncertain, experienced architects reach for governance. We create committees. We define standards. We build approval gates. This instinct exists for good reasons , uncontrolled proliferation creates technical debt, security exposure, and integration nightmares. The instinct is protective.
With AI, that instinct applied too aggressively produces a different kind of failure. You govern so carefully that nothing gets deployed. The organisation's AI capability atrophies in committee while competitors ship. The models that do get approved are already a generation behind by the time they clear the process.
The other blind spot: assuming integration complexity is the main risk. For most enterprise technology, it is. Getting systems to talk to each other reliably, at scale, is genuinely hard and genuinely where most projects fail. But with AI, there's a second category of risk just as significant: behavioural risk. The system integrates fine. It runs in production. And it gradually does something you didn't design for, didn't test for, and didn't notice until the impact was already in the business.
Knowing you have these blind spots doesn't eliminate them. But naming them is the first step to designing around them.
A Framework That Named What I Was Feeling
I'm not going to reproduce his framework here , I'd encourage you to watch the video directly at drrajramesh.com and make up your own mind. What I will do, across the next seven posts, is use those seven areas as a lens and add what I can from 24 years of enterprise architecture practice, from my work at Avanade in the Microsoft ecosystem, and from the AI-native ventures I've been building on the side.
As I worked through these questions, I came across a video by Dr. Raj Ramesh — an AI and enterprise architecture practitioner with a PhD in AI and a background leading billion-dollar transformation programmes. His framework of seven essential skills for enterprise architects in an AI world stopped me mid-scroll. Not because the ideas were foreign, but because they named things I was already bumping into and gave them structure I didn't have yet. The seven areas he identifies , technology literacy, designing for adaptive intelligence, portfolio management, risk and governance, change management, vendor evaluation, and storytelling , aren't a certification or a methodology. They're a map of where the job is changing. Each one has a version of it I already know, and a version of it that AI makes harder, more important, or fundamentally different.
I'm not going to reproduce his framework here — I'd encourage you to watch the video directly at drrajramesh.com and make up your own mind. What I will do, across the next seven posts, is use those seven areas as a lens and add what I can from 24 years of enterprise architecture practice, from my work at Avanade in the Microsoft ecosystem, and from the AI-native ventures I've been building on the side.
That's what this series is about.
The seven areas he identifies are: - Technology Literacy - Adaptive Intelligence - Portfolio Management - Risk and Governance - Change Management - Vendor and Technology Evaluation - Storytelling They aren't a certification or a methodology. They're a map of where the job is changing. Each one has a version of it I already know, and a version of it that AI makes harder, more important, or fundamentally different.
That's what this series is about.
What This Series Is
Each of the next seven posts goes deep on one area. I'll share what I've learned, what's worked, what I've got wrong. I'll use real examples where I can and honest generalisations where I can't name the client.
This is not a finished answer. I'm writing from the middle of a live problem , as a senior architect, as someone building AI-native ventures outside my day job, as someone who has spent two decades watching how large organisations actually adopt technology: slowly, messily, politically, and then suddenly.
If you're a senior architect, a technology leader, or a business executive trying to make sense of what AI actually means for how your organisation is built and run , this series is for you.
The next post starts where any honest AI journey has to start: with what you actually know about the technology, and whether that knowledge is sufficient for the decisions you're being asked to make.