Short videos on AI, in plain language.

What does enterprise architecture actually do for AI? For me the answer is policy as code. Rules built into the platform, not written in a PDF nobody opens. The platform enforces them every time, so nobody has to remember.

That's where architects earn their place. Not drawing boxes, but making the safe way the easy way. If an approved model takes one line and an unapproved one takes a ticket, people choose right without a meeting.

Good architecture removes decisions nobody should have to make.

Identity is one of the basics to get right when governing AI agents.

Today a lot of agents run under someone's personal account, or under a shared technical user that nobody really owns. So when something goes wrong, the log says a person did it, even though they didn't.

Every agent should have its own identity, its own access rights and a named owner who is responsible for it. A new employee gets their own keycard, not a copy of a colleague's, and agents should be treated the same way.

If you can't tell which agent did what, it's hard to trust any of them.

A common rule of thumb for AI is the 10, 20, 70 rule.

10% of the value comes from the algorithms, 20% from technology and data, and 70% from people and process.

Many budgets look the other way around. Plenty of money for models and tools, and much less for changing how the work actually gets done.

If most of the time goes to the model, that's the smallest part of the problem. Start with the people who are going to use it.

Domain specific models are close to peak hype right now, meaning models trained or fine tuned for one field like law, medicine or industrial maintenance.

The appeal is clear. A general model doesn't know your terminology or your rules.

But much of that gap can be closed with better input rather than a new model. Give a general model the right documents, the current price list and the relevant part of the contract, and it will often do better than a specialist model working from old data.

Build the special model when that's no longer enough, not before.

Two parts of agent governance that are easy to overlook are hard limits while the agent is running, and cost control.

When a person gets stuck, they stop and ask someone. An agent that gets stuck usually just tries again, and again. Every attempt costs money, and it might be touching real systems while doing it.

So set the limits before the agent goes live. A max number of steps, a budget per task, and a clear rule for when it has to stop and hand over to a person.

This isn't about distrust. It's the same thing we already do for any batch job that runs at night with nobody watching.

AI governance can be pictured as a set of rings. Governed data in the center, then clear definitions, then controlled outputs, then governed agents, and on the outside a named person behind every action.

Each ring depends on the one inside it, so the center is where you start.

A lot of programmes do it the other way around. They write agent policies before anyone has agreed on what a customer or an active contract actually means.

If two systems disagree on a definition, the agent will just pick one. So fix the meaning first, and then let the machine act on it.

A simple way to look at risk with AI agents is two questions. How much can the agent do on its own, and how sensitive is the data it can see?

An assistant that drafts replies in your inbox scores low on both. A group of agents acting across systems with customer data scores high on both.

Still, most companies put all of them through the same approval process. That's too slow for the first one and too loose for the second.

Sorting your agents on these two axes first makes it easier to decide how much control each one actually needs.

How do you decide today?

The future team looks small. A few people working together with AI agents, backed by one strong platform team.

The platform part is easy to miss. A small team only moves fast if someone has already solved access, security, deployment and monitoring for them.

Without that, every small team ends up rebuilding the same plumbing. Five teams means five ways of calling a model and five separate security reviews.

So if you want small teams, invest in the platform first. It's usually the least visible team in the company, but it's the one that makes the others fast.

If you look at the agentic AI hype right now, almost everything sits bunched together near the peak. Coding agents, multi-agent setups, the standards that connect agents to tools, agent governance.

When everything peaks at the same time, it's often a sign that it's still hard to tell what works from what just demos well.

Coding agents stand out. They already save real hours, because code has tests and a wrong answer shows up quickly.

That's a pattern worth copying. Start with work where mistakes are visible and cheap to fix.

Source: Gartner

With AI memory, stored is not the same as found, and found is not the same as used correctly.

When an assistant forgets something, people tend to blame the model. Often the problem happened earlier. The fact was never saved, or it was saved but the search missed it. Maybe it was found but got buried under other text, or an older version came back instead.

Each of these needs a different fix. So test memory like any other part of the system, step by step, with real questions from real users.

Roles are starting to merge as AI moves into the teams. The business analyst is turning into an AI requirements analyst, and the architect and delivery lead into something closer to a forward deployed engineer, all in one team sitting close to the customer.

With AI the requirements work changes. An AI system doesn't give the same answer every time, so it's not enough to specify screens and fields. You also need to describe what a good answer looks like and what a bad one looks like. And when it does get something wrong, you want someone close to the user who sees it early and can fix it.

Has your role started to shift yet?

Three numbers side by side: 63% of boards rank technology investment as a top strategy, 72% of CEOs see AI as their main driver of growth, and only 11% of CFOs can actually measure the return.

The last number is the one to fix.

Most AI projects start without a baseline. Nobody measured how long the task took before, so nobody can prove it got faster afterwards. Measure first, whether it's hours per case, errors per month or something else that fits.

It's boring work, but it's also what keeps the budget alive next year.

What do you measure before you start?

Source: Gartner

Four ideas are climbing the hype curve at the same time: workstyle analytics, AI agent identity, embodied AI and the employee digital twin.

Put together they describe software that learns how you work, a digital copy of you that can act on your behalf, agents with their own identity, and AI moving around in the physical world.

The technology will get there. The harder question is consent. Who owns the copy of you? Does it keep working after you leave the company? And who gets to look at the analytics?

AI projects need about 25% more training and up to 200% more change management than a normal technology rollout.

The reason is simple. Installing the tool takes a week. Changing how people work takes months.

Most employees sit in the middle. Not against AI, just unsure. They need to see a colleague use it on a real task, and they need to know what it means for their job.

If leaders skip that part, the middle slowly drifts towards giving up. That costs far more than any training budget.

Two concepts are getting a lot of attention right now: Generative UI, close to peak hype, and Zero UI, which is just getting started.

Generative UI means the screen is built for you in the moment. You ask a question and get a table or chart back instead of a fixed page. Zero UI takes it one step further, with no screen at all, just voice, context and actions running in the background.

Both share the same weak spot. People trust what they can see and check. With a fixed screen you know where to look. If the screen is different every time, or there is no screen at all, people need another way to check what the system did, like a short summary of the actions it took.

Picture an AI roadmap from first steps on the left to advanced work on the right. Most companies want to start on the right. An AI product portfolio. A platform team. Governance tooling.

But the left column is where the work is. Decide what you want AI to do for you. Pick a few use cases and agree on success. Check whether your data is ready. Write down the first rules.

None of this is exciting. It is also the part you can't skip. Every advanced box on that chart rests on a boring one to its left.

AI agent adoption can be seen as a spectrum. On one end you have agents with lots of freedom and very little control. On the other end the rules are so strict that little gets done.

It works in the middle, with agents built for one job that you can monitor and explain, and people handling the exceptions.

Many companies end up on the strict side rather than the loose one. Every agent goes through the same sign off as a new ERP system, so not much ships.

It feels safe, but an agent nobody is allowed to use won't teach you anything.