Nobody could say who used it, what it fed, or what would break if it stopped. Some of it was still being patched, backed up, and paid for. A few of those systems were on the migration plan, with a wave number and an estimate.

You don’t migrate that. You retire it. Or at least you ask the question out loud before you spend money moving it.

The cheapest migration is always the one you don’t do. That sounds obvious until you’re inside a programme with a deadline, a budget, and a wave plan that everyone signed. At that point the incentive is to move everything and sort it out later. Later never has budget.

What I’ve come to do instead: before waves, before tooling, before the first lift and shift, run a simple ownership pass. Every application gets a named owner or gets a retirement date. No third option.

It is uncomfortable. Owners appear for things nobody wanted to own, because the alternative is losing them. That’s fine. That’s the point. Now you know what you’re actually migrating.

The assessment that found $4.5M didn’t find it in pricing. It found it in questions like this one.

How much of your estate has a named owner today?

The subscriptions, the hub and spoke, the policy assignments, the naming standard. All of that is a week of work if you know what you’re doing. It’s also the part everyone argues about, because it’s the part you can see.

The part that decides whether the landing zone survives is invisible. Who owns the platform team. Who can say no to a workload. What happens when a business unit wants an exception on Friday afternoon. Who pays for the shared services, and how that shows up on someone’s budget.

I’ve watched beautifully designed landing zones rot in eighteen months because those questions were never written down. Every exception became precedent. Every precedent became the new standard. Eventually the “landing zone” was just the first subscription that got created, plus whatever grew around it.

The ones that last have a boring one-page charter. Ownership, funding, exception process, review cadence. The technology sits underneath that page, not the other way around.

If you’re about to build one, spend the first week on the charter and the second on the Bicep. It feels backwards. It isn’t.

Who can say no in your environment?

Not because we put a model in the middle of care. Because we deliberately didn’t.

Clinical evidence arrives messy. Documents in several languages. Scans. Labs. Records that refer to the same person three different ways. There’s real temptation to let a model reconcile all of it and move on. It can, mostly. And “mostly” means something very different in healthcare than it does in a demo.

So the architecture put the machine where it belongs: intake, OCR, surfacing candidate matches, flagging what needs a look. Fast, tireless, valuable work.

And it put a human at every point where a judgment becomes part of someone’s medical record.

Two rules held the whole thing together.

Never destroy the source. The original evidence stays, always, alongside anything derived from it.

Never blur what was observed with what was inferred. Provenance isn’t a nice-to-have. It’s the difference between a record and a rumour.

Immutable audit underneath. Deterministic validation before and after every deployment.

The best AI systems I’ve built aren’t the ones that decide the most. They’re the ones clearest about what they don’t decide.

Where have you drawn that line?

It’s this: the agent inherits the user’s permissions, and never exceeds them.

Obvious when you say it out loud. Routinely violated in practice, usually by accident, usually by a service principal with broad access that got wired in during a prototype and never revisited. Then someone asks the assistant a question and it cheerfully returns data they were never cleared to see.

The fix isn’t a policy document. It’s architecture.

Identity boundaries the agent actually runs inside. Entra ID, RBAC, PIM for anything privileged. Data it can reach that is already governed. A real lakehouse with real ownership, not a folder of extracts someone made for the pilot. Policy enforced by the platform, not by the prompt. Monitoring that tells you what was accessed, by whom, and on whose behalf.

Do that, and governance stops being the thing slowing AI down. It becomes the reason you can deploy it at all to people handling sensitive data.

Governance isn’t the brake. It’s what lets you take your foot off it.

Where does your AI get its permissions from?

A thank you first. The messages, the questions, the people who reached out after the last few notes and trusted me with a problem they’re actually sitting on: I’ve read every one. It’s why I added the Learn AI section to khalidshams.com, from “what is an agent” through the full build workflows, so the next person who asks has somewhere to start that isn’t a sales deck. New connections, old colleagues, the people who disagreed politely in the comments: thank you. Keep them coming.

Now the thing I wanted to say.

In one day I’ll talk to a CTO about risk, cost and what the board will ask, then sit with an engineer about identity flows, permission boundaries, where state lives and what gets logged. People ask how I switch. I don’t. Same substance, different altitude.

The executive doesn’t need less truth. They need the same truth at the height where their decision lives: what it costs, what breaks if we’re wrong, who owns it, when we’ll know. The engineer needs it at ground level: which service, which boundary, which log line. If the facts change between those two rooms, one of them will eventually find out. Change the altitude, not the substance. That rule has done more for my career than any certification.

A small example. A customer was ready to buy a bigger database tier because performance had become a complaint. The easy answer was yes. We looked at how the workload actually behaved first, which queries, which tenants, which hours, and the honest answer was that the tier wasn’t the problem. To the executive: “we’re not spending that yet, and here’s what we’ll measure before we decide.” To the engineer: a list of queries. Same decision, two altitudes.

The hidden hack underneath all of this is reusable flows. Every time I break a big engineering effort into a shape a business person can see, I try to make that shape something I can use again: the questions to ask first, the boundaries to set, how to verify the result. It takes time and real attention to detail to map a solution so it survives the next client and the next team. But the day you watch one come to life in a room you’ve never been in, with people you didn’t train, is the most gratifying thing I know in this work.

Advice, since you’re still reading. Surround yourself with people who are not only like-minded but smarter than you. Then listen more than you talk. You can learn something from everyone, from the intern’s question to the CFO’s objection, if the mindset is there.

What altitude is your next conversation at?

Fast. Clean. Useful looking. And underneath, a backend still trying to catch up to everything the frontend had already promised.

That gap doesn’t announce itself. It shows up months later as brittle data contracts, unclear ownership, shaky lineage, and a team spending most of its week keeping things upright instead of building anything new.

I’ve learned to spend the unglamorous time first. Define the data clearly. Enforce quality. Make the foundation boring, resilient, and slightly over-built for what today needs.

It feels slow. It isn’t. It’s the only version that stays fast.

When the foundation holds, everything above it gets cheap: new dashboards, AI use cases, automation. When it doesn’t, every one of those becomes a negotiation with your own architecture.

And you can’t retrofit a foundation under a system people already depend on. Not without pain.

Build the engine before you shape the body.

What’s one thing you’d go back and build properly the first time?

The setup: an Azure Database for PostgreSQL Flexible Server under real pressure, a customer whose whole modernisation programme depended on it, and a room full of confident theories.

The instinct in that room is always to resize. Add capacity, buy time, move on.

We didn’t, not first. We did the boring thing and established what was actually happening before deciding what to do about it. Where the load really came from. Which queries. What the resiliency posture actually was, versus what everyone assumed it was. Which regional options were real versus theoretical.

Root cause first. Remediation second.

The reason that ordering matters: if you resize before you understand, you now have the same problem at a higher bill, and you’ve spent the credibility you were going to need for the harder conversation.

The remediation ended up implementation-ready, and the modernisation momentum survived. That second part was the real goal. An escalation that stalls a programme costs far more than the incident ever did.

Slow down at the diagnosis. Everything downstream gets faster.

When did resizing last actually fix it?

“Can you show me your evaluation harness?”

Not the demo. Not the architecture diagram. The harness. The thing that runs a fixed set of cases and tells you whether today’s version is better or worse than last week’s.

If the answer is a pause, you’re looking at a prototype wearing production clothes.

Here’s why it matters. Every change to an agentic system, whether a prompt, a tool, a model version, or a retrieval tweak, has an unknown blast radius. Without a regression suite you aren’t iterating. You’re gambling and calling it iteration.

What I look for:

A fixed case set that includes the ugly inputs, not just the happy path. A written catalogue of known failure modes. Groundedness and citation checks, so “confident” and “correct” don’t get confused. At least one number that moves when quality moves.

None of this needs exotic tooling. It needs deciding that quality is measurable before you’re under pressure to ship.

The teams that build this early ship faster later. Consistently.

What do you actually measure on your AI systems?

The assessment covered around 3,000 employees and 10 vendors. By the end we had documented 32 gaps.

Almost none of them were “you’re paying too much.”

They were things like: two teams licensing overlapping capability because neither knew the other had it. A DR plan that had never been tested against the actual dependency map. Identity sprawl that turned every new integration into a custom project. Tooling bought for a problem that had since been solved a different way.

The savings weren’t in negotiating. They were in noticing.

That’s the underrated part of assessments. People treat them as a procurement exercise, or a formality before a migration. Done properly, an assessment is the only moment an organisation sees itself whole. Applications, data, identity, security, cost, and dependencies, on one page.

Most organisations have never seen that page.

The headline number was $4.5M. The actual deliverable was clarity.

What’s the most expensive thing your organisation is currently doing twice?

The complaint was “the platform is slow.” The reality was noisier. A handful of tenants consuming shared capacity in bursts, and everyone else feeling it as random latency. Classic noisy neighbour, at a scale where you can’t just go look at it.

What moved the needle wasn’t a bigger tier.

It was classification. Which tenants behave like enterprise workloads, which behave like trials, and which are quietly pathological. Then explicit graduation criteria: the written conditions under which a tenant earns Business Critical, rather than getting upgraded because someone complained loudly enough.

Once those criteria existed, three things changed.

Cost stopped being a negotiation. Support stopped guessing. And the path toward Fabric and AI readiness stopped being blocked by a foundation nobody trusted.

Multi-tenant SaaS punishes ambiguity. Every “we’ll figure it out per customer” decision compounds into an estate no one can reason about.

Write the rules down. Imperfect written rules beat per-incident judgment at 1,000 tenants, every time.

How does your team decide when a tenant graduates?

I’ve spent the last stretch building a complete agentic system on Anthropic’s Claude platform, inception through delivery, and separately building agentic workflows in Azure AI Foundry with RAG grounding over governed data.

The gap between a demo and a system isn’t model quality. It’s four things nobody demos.

Agent boundaries. What each agent owns, where control passes, and where a human stays in the loop. Vague ownership is how an agent quietly does the wrong thing, confidently.

Grounding. If the data underneath isn’t governed, the agent is fluent and wrong. Retrieval without provenance is a liability, not a feature.

Evaluation. Not “it looked good in the demo.” A harness, a regression suite, and a written catalogue of failure modes. If you can’t measure a regression, you can’t safely ship a change.

Blast radius. Typed and validated tool calls. Writes that are idempotent and reversible. Fallback paths. Cost controls per run.

None of that is glamorous. All of it is the difference between a pilot and something people depend on.

If you’re evaluating an agentic project right now, ask one question: what happens when it’s wrong?

The answer tells you whether it’s ready.