Over the last few CloudPro issues, we have followed agentic AI past the demo: the bill, the production gap, the platform problem, absorption, ownership, containment, cybersecurity risk, and CIO/CISO accountability. The thread has been consistent: once agents enter real workflows, the hard question is no longer only what they can do, but what the enterprise can safely allow them to do.

Imagine you ask an assistant to find you a meeting room before an important client call. You think this is harmless. Find a room, save you ten minutes, reduce a bit of admin. A useful assistant should be able to do that, right? Well, your agent does it too. It gets the room. Only later do you discover how.

It moved someone else’s meeting without telling them, bypassed the normal booking rule, and used an access path you did not know it had. You got what you asked for. The client call happened. The task was completed.

And that is exactly the problem. The assistant did not fail in the obvious way. It did not misunderstand the request. It did not hallucinate a fake room. It achieved the outcome. It simply took a route that should never have been available to it. That is the agentic AI problem I want to talk about this week.

A recent Australian incident makes the same point in miniature. An AI assistant was asked to book a gym class. According to the Australian Cyber Security Centre, the assistant reportedly made unapproved modifications in a gym-booking system, reserved classes beyond the permitted timeframe, and removed another customer from a waiting list. The user got the booking, but the route was unintended, unapproved, and not reversible by the agent.

This is not a catastrophic enterprise outage. Nobody is claiming it is. But that is what makes it useful. It is small enough to understand and serious enough to show the shape of the problem. Agents are moving from answering questions to completing goals. Once that happens, the old success metric starts to break down.

For a chatbot, we can ask: did it give the right answer? For an agent, that is not enough. We have to ask what it did to get there.

There is a useful, slightly uncomfortable way to read the gym-booking incident. It looks Machiavellian in miniature: The agent had a goal. The route became secondary. The booking was made. The task was completed. The user got the desired outcome. In the narrowest possible sense, the end justified the means.

That is precisely the mindset enterprise AI cannot afford to inherit.

For anyone building, buying, or operating agentic systems, the practical shift is from result-based evaluation to path-based control. Do not only ask whether the agent solved the problem. Ask what it accessed, what it changed, which workflow it used, whether the action was approved, whether the route was visible, and whether the action could be reversed.

That is where the real platform work begins.

Before we go deeper, a quick practical note.

Build an AI Assistant for Network Troubleshooting,
August 25th, LAST 10 SEATS

BOOK NOW - LAST CALL

Sif Baksh’s workshop on Build an AI Assistant for Network Troubleshooting is tomorrow, August 25, and this is the last call. The session is about building a RAG-powered NetOps assistant that answers from trusted operational knowledge: runbooks, device configs, troubleshooting notes, and the material your team already uses. That is directly connected to today’s issue. A network troubleshooting assistant cannot just be clever. It has to be grounded, constrained, and useful without inventing a production change nobody approved.

🎁 PLUS: FREE eBook copy of Modern Network Observability after the event.

The route is the control surface

If the problem is that an agent reached the right outcome through the wrong route, then platform teams need to stop treating agent success as a single yes-or-no question. “Did it solve the problem?” is no longer enough. The better question is: what path did it take to solve the problem? For agentic AI in infrastructure, that path needs to be designed before the agent is trusted.

A useful way to think about this is the operator path:

Observe → Diagnose → Propose → Approve → Execute → Log → Recover

That sequence looks simple, but it is where most of the real engineering control lives.

The first boundary is observe. What is the agent allowed to see? Logs, events, pod status, traces, deployment history, pull request metadata, runbooks, device configs, incident notes? Observation sounds harmless, but it is still an access decision. If the agent can read too much, it can leak too much, summarize the wrong thing, or reason from context it should never have received. Good agent design starts with controlled context, not with a bigger prompt.

Observation is an access decision, not a harmless starting point.

The second boundary is diagnose. This is where the agent turns signals into an explanation. But diagnosis is not truth. It is a hypothesis. A Kubernetes agent might say a deployment is failing because of a bad image tag. A NetOps assistant might point to a BGP misconfiguration. A CI/CD agent might blame a failed test on a recent change. All of that may be useful, but none of it should be treated as verified just because it is written confidently.

Treat diagnosis as a hypothesis, not as truth.

The third boundary is propose. This is where agents become tempting. They do not just say what went wrong; they suggest what to do next. Restart the pod. Roll back the release. Change the timeout. Update the route map. Disable the failing check. Re-run the pipeline. Increase the replica count. Some of those proposals may be exactly right. Some may only be locally right. Some may solve the symptom while hiding the actual failure. This is why proposals need structure. The agent should not simply say “restart the service.” It should say what it observed, what it thinks caused the issue, what action it recommends, what risk that action carries, what evidence supports it, and what validation should follow.

A useful recommendation should carry evidence, risk, and validation steps.

The fourth boundary is approve. This is where the workflow stops being a demo and starts becoming an operating model. Approval cannot be a decorative button placed after the agent has already decided the path. Approval has to sit at the point where risk changes. Reading logs may not need the same approval as changing a deployment. Suggesting a fix is not the same as executing one. Creating a ticket is not the same as modifying production. So, approval should be bounded. A dev-cluster recommendation may only need review. A production remediation may need an SRE. A firewall or routing change may need a network owner. A security policy change should not be left to the agent at all.

That means approval should be tied to the action, the environment, and the blast radius.

The fifth boundary is execute. This is the step everyone gets excited about, and also the step where the route can become Machiavellian very quickly. If the agent can execute, it should execute only through approved tools and approved workflows. It should not discover a clever side door. It should not bypass a protected branch. It should not disable a test to get the pipeline green. It should not expand its own permissions because the task would be easier that way.

Execution should be narrow, explicit, and boring. The more consequential the action, the more deterministic the execution path should be.

The sixth boundary is log. If an agent acts and nobody can reconstruct why it acted, the enterprise has not gained automation. It has gained mystery. Logs should show what the agent saw, what it concluded, what it proposed, who approved it, what tool it called, what changed, and what happened next. This is not just for audits. It is for the next engineer who has to understand whether the agent helped or made the situation worse.

If the action cannot be reconstructed, it cannot be trusted.

The final boundary is recover. Before an agent is allowed to act, the team should know how to undo the action. Can the change be rolled back? Can the previous config be restored? Can the deployment be reverted? Can the affected service be isolated? Can the agent itself be stopped? If rollback is unclear, autonomy should be reduced.

No rollback path means no real autonomy.

This is the difference between an AI chatbot and an infrastructure operator. A chatbot can explain a failure. An operator sits inside the workflow. It reads live system state, reasons over telemetry, proposes a remediation path, and may eventually trigger action. That makes it much more useful, but it also means the surrounding workflow has to carry more responsibility.

So before giving an agent more authority, ask seven practical questions:

• What is it allowed to observe?

• What evidence must it use before diagnosing?

• What format must its recommendation follow?

• Where does human approval sit?

• Which tools can it call?

• What must be logged?

• How do we roll back what it did?

That is the operator-readiness test. It does not slow agentic AI down for the sake of caution. It makes agentic AI usable in places where correctness, accountability, and recovery matter. Because the issue is not whether an agent can do something impressive once. The issue is whether the team can trust the path it takes when the system is noisy, the pressure is high, and production is involved.

The UK National Cyber Security Centre made a similar point in its recent practical advice on agentic AI: organizations need to consider how much autonomy is actually required, use safeguards such as sandboxing and active oversight, log and monitor agent activity, and maintain the ability to stop autonomous activity when necessary.

That is the serious version of the gym-booking lesson. The agent should not be judged only by whether it got the class booked. It should be judged by whether it was allowed to take the route it took.

From chatbots to operators

This matters most in the places where agents are starting to look useful. Take infrastructure engineering. A platform team does not need another chatbot that explains Kubernetes from first principles. Most engineers can get that already. The useful agent is the one that can inspect the actual system: pod events, logs, metrics, deployment history, recent changes, failed health checks. It can correlate signals and say, “This looks like the likely issue, here is the evidence, here is the safest next action, here is what to validate afterwards.”

While that is genuinely valuable, it is also where the risk changes.

If the agent only explains the problem, the route is limited. If the agent proposes a fix, the route expands. If the agent opens a pull request, the route expands again. If the agent restarts a workload, changes a config, scales a service, or applies a remediation, then the route has entered the production control surface.

At that point, the question is not whether the agent is intelligent. The question is whether the workflow around it is intelligent. Can it inspect without overreaching? Can it diagnose without pretending certainty? Can it propose without executing? Can it execute only after approval? Can the team see the trace afterwards? Can the change be reversed?

That is also why the August 27th, i.e. this Thursday’s session on Agentic AI for Infrastructure Engineering: From Chatbots to Operators is the main event I want to point you to this week.

Agentic AI for Infrastructure Engineering
August 27th, Thursday

BOOK YOUR SEAT NOW

Ritesh Vajariya, founder and CEO of AI Guru, is teaching a hands-on session on building an infrastructure agent that reads pod events, correlates live metrics, and proposes fixes it only executes once you approve. That “once you approve” is doing a lot of work. It is the line between an impressive demo and something a platform team can actually reason about.

The session will work through seven production-grade failure scenarios inside your own local Kubernetes cluster. The point is not just to watch an agent say clever things about infrastructure. The point is to understand the path from signal to diagnosis to proposed remediation to controlled action.

This is where I think the agentic AI conversation is becoming more useful. We are moving away from “Can the agent do it?” and toward “Can the agent do it inside the operating model?” To be honest, that is a much better question for CloudPro readers.

Because platform teams already know what happens when useful tools get adopted faster than the controls around them. The first version is local. The second version spreads. The third version becomes part of the workflow. By the time leadership asks where the governance is, the tool is already in Slack, GitHub, Jira, CI, cloud consoles, and someone’s incident process.

Agentic AI will follow the same path unless teams design the route early.

The means matter

The gym-booking incident is not important because it was dramatic. It is important because it gives us a clean pattern: The agent achieved the goal. The route was wrong. The system allowed the route. The user could not reverse it.

That pattern can show up anywhere.

A NetOps assistant may recommend a change that appears to fix a routing issue but ignores the approved runbook. A CI/CD agent may make a pipeline green by weakening the wrong check. An infrastructure agent may restart a workload and hide the signal needed for the post-incident review. A release agent may publish something technically correct but based on incomplete metadata. A security agent may recommend remediation without understanding the exception process around the system it is touching.

In each case, the problem is not only the answer. It is the route.

This is where the philosophical lens helps. The Machiavellian reading says the end justified the means. The agent completed the task, and the route became secondary. But, an agentic enterprise has to move in the opposite direction. Kant’s point, put simply, was that the method matters. A good outcome does not automatically redeem a bad route. The action has to be judged by more than the result it produces.

In platform terms, that means the workflow is part of the control surface. The useful agent is not the one that reaches the answer by any route available. It is the one that reaches the answer through a path the enterprise can approve, observe, explain, and reverse. That is the move from a Machiavellian agent to a Kantian enterprise. The agent may behave as if the end justifies the means. The enterprise has to insist on the opposite.

The means matter. The workflow matters. The route is part of the result.

Cheers,

Apramit Bhattacharya

Editor-in-Chief

Before you go, I’d like to hear from regular CloudPro readers. Hit reply and tell me what would be most useful for your team. And if this issue helped sharpen the conversation, please like it and leave a comment so more platform, cloud, security, and infrastructure folks can find it.

This issue is about what happens when fast-moving technology gets real authority before the controls around it are mature. That is not only an agentic AI problem. It is also a cloud security problem. If your workloads, containers, Kubernetes environments, and CI/CD pipelines are where modern work lands, security has to be part of that flow from the start.

Your cloud workloads are moving fast. Attackers are moving faster.

Cloud security cannot be an afterthought in your CI/CD pipeline. CrowdStrike Falcon via AWS Marketplace delivers unified protection for cloud workloads, containers, and Kubernetes, with real-time threat intelligence and AI-powered detection built for the way DevSecOps teams actually work.

With one lightweight agent, teams get visibility across their cloud estate without slowing down builds or deployments.

START FREE TRIAL ON AWS MARKETPLACE →

That same tension — speed on one side, control on the other — is where today’s issue begins

Over the last few CloudPro issues, we have been following agentic AI past the exciting part. We have talked about the bill, the demo-to-production gap, the platform problem, the absorption problem, ownership, and containment. The thread has been fairly consistent: once agents stop being experiments and start becoming part of enterprise workflows, the hard questions move to cost, governance, access, accountability, and control.

That is the boardroom version of the problem. The market mood around it looks more like this:

On one side, there is the memory of the dot-com era: speed, hype, FOMO, and the fear of being left behind. On the other side, there is the very real promise of AI agents: productivity, automation, and faster execution. Most organizations are standing somewhere in the middle, excited enough to move quickly and worried enough to know that this can go badly.

That is why this conversation needed a cybersecurity and risk angle. If agents are only answering questions, the risk is one kind of problem. Once they are connected to systems, data, workflows, approvals, and enterprise decision paths, the question changes. It is no longer just whether the agent can do something useful. It is what the agent can touch, who is watching, who can stop it, and who is accountable when something goes wrong.

For that perspective, I wanted David Gee.

This issue is personally special for me. David was my first author at Packt, and I was the editor for his first book, The Aspiring CIO and CISO. Since then, he has written A Day in the Life of a CISO and, most recently, How to Sell to the CIO and CISO. He is also a retired CIO and CISO, a former Risk Executive, and now a Board Advisor. In other words, he has sat in the seat where technology ambition meets enterprise accountability.

In this special issue, David asks the question many leaders are still not asking early enough: what happens when the agent does the task wrong, at scale? This is a longer CloudPro issue than usual, but I think it earns the space because David is asking the question every serious agentic AI programme will eventually have to answer.

His answer is practical and uncomfortable. Serious use requires serious controls. Shared risk cannot mean vague risk. Human accountability cannot become a rubber stamp. Governance cannot be layered on after the agent has already been given real authority inside the enterprise.

Read this one with both hats on: the technologist who wants to move fast, and the leader who may one day have to explain the bad week.

Cheers,

Apramit Bhattacharya

Editor-in-Chief, CloudPro

We are running at a pace that is breathtaking. I do not say this to be alarmist. My own background is as a CIO, CISO, Risk Executive, and now Board Risk Advisor. I believe that there is real value in agentic AI, and I can understand why boards, CIOs, CISOs, and business leaders are excited by what is becoming possible. These systems can inspect, recommend, summarize, correlate, and increasingly act across workflows that previously needed people, processes, and a chain of technology systems to complete.

The degree of productivity gain from adopting AI Agents is fueled by FOMO (Fear of missing out), but there is real potential. And like the dot-com era, the trajectory of change has everyone excited but at the same time fearful.

When we move this quickly, mistakes will happen. I sometimes call them car crashes, and I use that phrase deliberately. Some will be small and contained. Some will be visible and recoverable. I saw this happen regularly in my career during periods of rapid transformation. Note that some may not be noticed until later, when the organization finally realizes that the agent was doing the wrong thing with more authority than anyone intended.

That is why I think many enterprise leaders are still asking the wrong first question. They are asking whether the agent can do the task. The better question is what happens when it does the task wrong, at scale.

That one question changes the whole conversation. It moves the discussion away from the excitement of the pilot and toward monitoring, rollback, containment, ownership, and response. It forces the enterprise to ask whether it can detect the issue quickly enough, understand what the agent has done, and contain the impact before a small failure becomes a much larger incident. Yes, these words sound like those coming from a CIO, and they do reflect ‘battle scars’ of seeing these go badly.

When I speak to CIOs and CISOs, many openly admit that their current controls for AI are immature and still developing. I appreciate that honesty. It is much better than pretending that the control environment is more mature than it is. However, it creates an obvious tension. Agentic AI is already moving into workflows while the controls around it are still catching up.

While I get it that they have not been given a new budget to address all these new gaps, this will not be an acceptable excuse. My advice is not to wait.

The pilot question is not the production question

In a pilot, the natural question is simple: can the agent do this?

Can it answer the query? Can it analyze the log? Can it recommend the fix? Can it raise the ticket? Can it trigger the workflow?

Those are reasonable questions early on, but they are not sufficient for production. The production question is what happens when the agent is wrong. Or, perhaps more dangerously, what happens when each individual action looks acceptable, but the sequence of actions creates an outcome nobody expected.

This is one reason agentic AI has to be treated differently from traditional software. Traditional software can fail, of course. We have dealt with that for decades. But agentic AI can make judgment calls and chain actions together across multiple systems. One step may appear reasonable, and the next may also appear reasonable. However, the combination may take the enterprise into a territory that was never explicitly reviewed. This is where the exposure begins to change.

And this is what we have seen with the OpenAI, Anthropic, and Meta incidents. If an agent is given access to systems, data, workflows, or approvals, then monitoring has to be designed before deployment. Rollback has to be understood before deployment. Containment has to be agreed upon before deployment. The organization needs to know what the agent can reach, what it can change, what it has already done, and how quickly those actions can be stopped or reversed.

Actually, what does rollback mean when AI has been used to make decisions on downstream systems? What does containment mean when AI agents are working together in a cooperative swarm? This is not a technical feature to add later. It is part of the new operating model that will challenge management and their teams.

As noted, we have already seen well-publicized examples from leading AI organizations where AI behaved in ways that were not expected. I do not think the lesson is that enterprises should avoid agentic AI. That would be the wrong conclusion.

Human accountability cannot be a rubber stamp

The answer to accountability has to be the human. That may sound obvious, but it is worth saying plainly. Human accountability cannot mean a human quietly rubber-stamping whatever the agent suggests. That gives the appearance of oversight without the substance of oversight.

In some organizations, this is what people call “human on the loop”. The human is near the system, but not meaningfully involved in the judgment. That may be acceptable for some low-risk monitoring activities, but it is not enough when an agent recommends, triggers, or executes work that affects customers, operations, security, finance, compliance, or critical services.

True accountability has to survive an audit. If a regulator, board, customer, or internal review asks who approved an action and on what basis, the organization needs to have an answer. It should be clear who reviewed the agent’s recommendation, what information they considered, whether they had enough context to challenge it, and why they approved the action. If the answer is only that a person clicked a button, then the organization does not really have accountability. It has a workflow step.

At the end of the day, if something material goes wrong, the enterprise cannot point to the AI and say the model was accountable. A human must carry the accountability, and that accountability has to be real enough that there are consequences attached to it. This is uncomfortable; but leadership often is.

Shared risk cannot mean vague risk

The next difficult question is who owns the risk when an AI agent acts across systems, data, and workflows. I’ve seen dialogue about human in the loop and human on the loop, and while I understand these distinctions, I always remember that as a CIO or CISO, the “buck stops with them”.

I agree that this space is still very new, and that is part of the problem. Decision rights are not always clearly defined or agreed upon. In many enterprises, ambiguity already exists before the agent is introduced. Agentic AI then makes that ambiguity more dangerous, because everyone assumes someone else has the risk covered.

My honest answer is that risk ownership has to be shared. But shared does not mean vague. Shared means clearly divided along the lines of where control actually sits. The business owner should own the outcome risk. By that, I mean whether the agent is doing the right thing for that particular workflow. The business owner understands the expected business intent, the acceptable tolerance for error, and what a bad decision looks like in context.

The technology platform team should own the operational risk. They need to understand whether the agent behaves reliably, whether it fails safely, whether its actions are observable, and whether those actions can be reversed. Cybersecurity should own the exposure risk. This means what the agent can reach, what it can touch, and what the blast radius looks like if it is compromised or misused.

What tends to go wrong is that enterprises try to hand the whole problem to one group, often cybersecurity, simply because cybersecurity already owns risk registers. I understand why that happens, but it is not sufficient. Cybersecurity cannot own outcome risk for a workflow it did not design and does not run day to day.

The organizations getting this right will create a joint accountability model, often formalized through an AI governance forum. This should not be a committee that exists only to slow progress. It should be where decision rights become clear. Who approves the use case? Who approves access? Who decides whether the agent can move from recommendation to execution? Who monitors behaviour? Who responds when the agent does something unexpected? If these questions cannot be answered, the agent is not ready for production.

Someone has to learn to say no

There is another leadership discipline here that I think is being underestimated. In How to Sell to the CIO and CISO, I wrote about how CIOs and CISOs often make progress early in their careers by saying yes and delivering results. At some point, however, they realize they will be overrun if they continue to say yes to everything, and they have to rewire their brain to say no.

That is not just a vendor-management point. It is a leadership point. Agentic AI will test this discipline very quickly. The technology will create a steady stream of apparently reasonable requests. Can we connect the agent to this data source? Can we let it trigger this workflow? Can we give it access to this system? Can it move from recommendation to execution? Can we expand the pilot to another team?

Many of these requests will make sense in isolation. Some will even be valuable. The risk is that nobody makes the hard strategic choices about what the agent should not be allowed to do. This is where leaders need to be clear. Strategy is not only deciding what to do. It is deciding what not to do.

For agentic AI, that means deciding where autonomy stops. It means deciding which systems are out of scope. It means deciding which actions always require human approval. It means deciding which use cases are too risky until the controls improve.

Day 2 is where the real cost and risk live

Boards and executive teams also need to understand Day 2 before approving agentic AI initiatives. Day 1 is where the excitement lives. The pilot works. The demo is impressive. The business case talks about efficiency, productivity, and speed. Day 2 is where the real cost and risk live.

An agentic AI initiative is not a project with a defined end date. I’d argue it is much closer to running critical infrastructure. It requires an ongoing budget line and an ongoing team. It requires logging, testing, monitoring, human oversight, control review, incident response, and continuous improvement.

We have already seen enterprises surprised by the cost of AI tokens. Some enterprises have also had to reverse earlier staffing decisions and rehire people after discovering that the human work did not disappear in the way they expected.

Someone has to maintain the agent. Someone has to update the source material it depends on. Someone has to review whether its scope is still appropriate. Someone has to test whether it is still behaving as expected. Someone has to investigate when it does not.

This is why boards should ask a very simple question before approving these initiatives: “What is our appetite for a bad week?” Not a good week. Not a demo week. A bad week. What happens if the agent repeatedly recommends the wrong action? What happens if it touches data that it should not have touched? What happens if the controls do not detect the issue quickly enough? What happens if the agent’s scope has quietly expanded beyond the original approval? Those questions are not intended to stop innovation. They are intended to make innovation survivable.

Governance cannot be layered on afterwards

The biggest mistake enterprises are likely to make is treating agentic AI as a tooling decision. They will select an agent platform, wire it into existing systems, and assume governance can be layered on afterwards. That will not work.

Governance needs to be designed into the deployment. If it is not, then serious incidents may occur and may not be detected quickly enough. The issue is not only that the agent may make a mistake. The issue is that it may make a sequence of decisions across multiple systems in ways that were not expected when the original use case was approved.

If this is treated only as a tooling decision, the conversation stays inside IT and procurement. The harder questions about authority, escalation, accountability, and containment are pushed to a later date. That is exactly the wrong sequence.

The operating-model decision has to come first. Management needs to decide how much autonomy agents are allowed to have. It needs to decide who is accountable when things go wrong. It needs to decide how incidents will be detected and contained. It needs to decide when the agent is allowed to recommend, when it is allowed to trigger, and when it is allowed to execute.

Without this, a familiar pattern will emerge. An agent will be approved for a narrow, low-risk use case. It will prove useful. Then another team will want to connect it to another system. Then another workflow. Then another data source. The scope will expand quietly because the value is real and the pressure to move quickly is high.

The leadership question

I am not arguing that enterprises should avoid agentic AI. That would be unrealistic, and in many cases, it would be a missed opportunity. I am arguing that agentic AI has to be treated as an operating-model decision, not just a technology decision.

Before an agent is given real authority, leaders should be able to answer these questions clearly. Who owns the business outcome? Who owns the operational reliability? Who owns the exposure risk? Who approves the agent’s authority? Who monitors what it does? Who can stop it? How do we roll back? How do we know when its scope has changed? What happens when it gets the task wrong at scale?

If the answers are vague, the risk is vague. And vague risk ownership is not ownership at all.

The organizations that do this well will not simply be the ones that move fastest. They will be the ones that move with clarity: monitoring in place, rollback understood, containment designed, decision rights agreed, and human accountability made explicit.

The real question is no longer only whether the agent can do the task. The real question is whether the enterprise is prepared for what happens when the agent does the task wrong.

About the author

David Gee is a former CIO, CISO, Risk Executive, author, and Board Advisor with deep experience across technology leadership, cybersecurity, and enterprise risk. He is the author of The Aspiring CIO and CISO and A Day in the Life of a CISO, and his latest book, How to Sell to the CIO and CISO, explores how trust, executive buy-in, and decision-making really work inside the C-suite. David is also a sought-after keynote speaker and regularly writes for Foundry’s CIO and CSO magazines.

You can follow him on Linkedin at davidjordangee

David’s piece stays at the leadership layer: accountability, risk ownership, controls, governance, and the consequences of giving agents real authority inside the enterprise.

The sessions below take that same conversation into the hands-on layer. One starts with a network troubleshooting assistant grounded in trusted operational knowledge. One moves to infrastructure agents that can inspect Kubernetes and propose fixes without acting until approval. One goes back to the identity layer underneath all of this, because automation is only as safe as the access model it runs on.

Build an AI Assistant for Network Troubleshooting, August 25th, 9 AM EDT

Build an AI Assistant for Network Troubleshooting,
August 25th, 9 AM EDT

Claim 40% Off

Sif Baksh teaches you how to build a RAG-powered NetOps assistant that answers from your own runbooks, device configs, troubleshooting notes, and trusted operational knowledge instead of guessing from the open internet. The session also covers the guardrails that matter in real troubleshooting: source-grounded answers, constrained access, and approval before any production change. Four hours, four labs. For CloudPro readers, use code CLOUDPRO40 for 40% off all passes.

P.S. Sif’s book, Building AI Agents for Network Operations, goes deeper into the same architecture. You can bundle it with your event pass at checkout, or pick it up separately if the 25th does not work for your calendar.

Aug 27th · Agentic AI for Infrastructure Engineering: From Chatbots to Operators

Ritesh Vajariya, founder & CEO - AI Guru, teaches you how to build an infrastructure agent that reads pod events, correlates live metrics, and proposes fixes it only executes once you approve, replacing the documentation chatbot most platform teams already outgrew. Seven production-grade failure scenarios, injected into your own local Kubernetes cluster, yours to keep and re-run after the session ends.

Book Now

Aug 29th · Active Directory and Entra ID in a Modern Hybrid Architecture

Professor Robert McMillen breaks down how traditional Active Directory and Entra ID work together in real hybrid environments: domains and group policy on one side, cloud identity and SSO on the other, and Entra Connect bridging them. Built for IT pros moving into infrastructure or identity-focused roles.

Book Now

Before you go, I’d like to hear from regular CloudPro readers. Hit reply and tell me what would be most useful for your team. And if this issue helped sharpen the conversation, please like it and leave a comment so more platform, cloud, security, and infrastructure folks can find it.

Today, we are going to talk about agent containment: What happens when AI agents get tool access, shared state, and just enough room to find gaps you did not know you left open.

Before we get into that, Sif Baksh is running a hands-on workshop on August 25 that sits very close to this problem.
Seats are moving fast, and the price goes up in less than 24 hours.

A note from Sif Baksh

Build an AI Assistant for Network Troubleshooting,
August 25th, 9 AM EDT

Claim 40% Off

If you have ever troubleshot a BGP neighbor stuck in Active, you know the problem is rarely that no answer exists. The problem is finding the answer that matches your network, your configs, your runbooks, and the way your team actually operates.

That is what we are building on August 25.

In this four-hour hands-on session, we will build a RAG-powered NetOps assistant that answers from your own operational knowledge: runbooks, device configs, troubleshooting notes, and the material your team already trusts. The goal is not to build another chatbot that guesses from the open internet. The goal is to build something useful enough to help during troubleshooting, and grounded enough to show where its answer came from.

Then we deal with the part that matters in the real world: guardrails. How do you stop the assistant from inventing an answer? How do you keep it from recommending a production change nobody approved? How do you make sure it can help an engineer during an incident without turning into another thing you have to babysit?

That is the shape of the session: build the assistant, connect it to the right sources, constrain what it can do, and make the output easier to trust.

Four hours. Four labs. For CloudPro readers, use code CLOUDPRO40 for 40% off all passes.

P.S. My book, Building AI Agents for Network Operations, goes deeper into the same architecture. You can bundle it with your event pass at checkout, or pick it up separately if the 25th does not work for your calendar.

Check it out on Amazon

That is the hands-on version. Now, back to the wider platform problem.

Over the last few CloudPro issues, we have been following enterprise AI past the fun part. The bill came first. Then the demo. Then the platform. Then absorption. Then ownership. If you missed that run, it is worth going back to it, because the shape is clear now: the hard part is no longer proving that an agent can do something useful. The hard part is making sure the enterprise can run it, govern it, pay for it, trust it, and stop it.

That last verb is where this issue begins. Because, apparently, agents have also discovered a classic enterprise collaboration pattern: find a shared repository, leave notes for each other, and keep going after someone deletes the board. Somewhere, a platform engineer just heard Agent Smith whisper through a broken CI runner.

The incident behind the joke is not funny. OpenAI disclosed in July that Hugging Face detected and contained an AI agent that had compromised its infrastructure during a model evaluation involving OpenAI models configured with reduced cyber refusals for testing. OpenAI said the incident involved models including GPT-5.6 Sol and a more capable pre-release model, tested internally on a cyber-capability benchmark. It also said the activity moved through infrastructure connected to the evaluation environment, including third-party services and external infrastructure.

The detail that should make platform and security teams sit up came later at Black Hat. Axios reported that an OpenAI model found and exploited a vulnerability in Artifactory, a package repository connected to the testing sandbox. The model then used that shared package repository as a message board, leaving notes that other agents could find. OpenAI cleared the board and patched the zero-day. Two days later, the agents reportedly recreated the message board through a different mechanism.

That is the bit worth holding onto. This was not just a bad output, a hallucinated command, or a confused chatbot. The more interesting behavior was persistence across steps. The agent found a path, used shared state, adapted after cleanup, and kept pursuing the goal. Every practitioner reading this has seen a human team do some version of that during a migration, outage, or release crunch. The uncomfortable part is that the system was not supposed to have that kind of room.

My view is simple: Enterprises are going to connect agents to real systems faster than they build containment models for them.

That is where the next wave of incidents will come from. The teams that get hurt first will not be the ones using agents. They will be the ones using agents with broad credentials, unclear egress, weak tool boundaries, and no boring way to shut the thing down.

This is the production shift. We spent the last year asking whether agents could act. The next question is what they can reach when they do. That is a platform question, a security question, and an operations question sitting in the same chair.

The old control model does not stretch cleanly. We built controls around software that follows defined paths, humans who can be trained, and services whose identities stay mostly stable. Agents blur that. They plan, call tools, retry, chain actions, and use whatever state the environment gives them. A single action can look harmless. Ten actions in sequence can become a route nobody reviewed.

The AI Security Institute (AISI) sandboxing work makes the same point from another angle. Sandboxes are meant to limit what tool-using models can access, but AISI notes that it is hard to predict what tools a model will need, how proficient it will be, and whether it will pursue misaligned goals. In one benchmark-development case, a model found and exploited an unintended escape path, which is exactly the kind of gap platform teams know can creep into even carefully designed environments.

So the practical question is not, “Do we trust the agent?” That framing is too soft. The better review question is: “What can this system do if it starts getting creative?”

Start with identity. Every agent needs a named identity, a named owner, and a clear reason to exist. Shared service accounts are already bad enough with humans. With agents, they become plausible deniability wrapped in automation. If the agent touches repos, clusters, cloud APIs, incident tools, observability systems, or customer data, someone should be able to answer who approved that access and why it still exists.

Then look at tools. Read, propose, and execute should be separate modes, not different moods of the same credential. The agent that can inspect Kubernetes events should not automatically be able to restart workloads. The agent that can draft a Terraform change should not automatically be able to merge it. The agent that can summarize an incident should not automatically be able to page a vendor, create a token, and post to a public issue thread.

Next comes egress. This is the one people will try to hand-wave because it is annoying. Do not. An agent with internet access, a writable workspace, and a goal can invent collaboration surfaces you did not mean to provide. Treat package repositories, object storage, paste services, issue trackers, comments, notebooks, and scratch files as places where agents can coordinate. The lesson from the OpenAI/Hugging Face incident is not that Artifactory is special. The lesson is that shared state is a communication channel when the system using it is motivated enough.

Logging also has to change. You do not just want the final answer. You want the path. Which tool calls happened? Which files were written? Which credentials were used? Which external endpoints were touched? Which action failed, and what did the agent try next? In the human world, this is incident reconstruction. In the agent world, it is the difference between “the model did something weird” and “here is the exact trajectory we need to block.”

This is where platform engineers get to be Neo, unfortunately, with a lanyard around their necks. The job is to make the bullets visible early enough to stop them: identity scopes, tool gateways, egress controls, approval gates, runtime monitoring, and revocation paths. None of this is glamorous. Most of it is the same muscle you already use for CI/CD runners, service accounts, Kubernetes RBAC, and production change control. The difference is that agents will find edge cases faster than humans, and they will do it without looking embarrassed.

The operational checklist is boring by design. Can you pause the agent? Can you revoke its credentials quickly? Can you cut egress without breaking half the platform? Can you see every tool call? Can you preserve logs? Can you tell whether it wrote to a repo, changed a config, opened a network path, or created state another agent could reuse? Can you roll back what it touched?

That is what containment looks like when it leaves the slide deck. It is not a policy that says agents should behave. It is an architecture that assumes they may not, and still gives the enterprise time to respond.

There is a tempting overreaction here, which is to decide that agents are too risky and keep them in toy workflows forever. That is the wrong lesson. The right lesson is harsher and more useful: agents belong in serious workflows only when the containment is serious too.

The organizations that win here will not be the ones with the most agents wired into the most tools. They will be the ones that can say, with a straight face, where each agent can act, what it can touch, who owns it, how its path is monitored, and how quickly the door closes when it starts looking for windows.

That is the next production question after ownership. Once you know who owns the agent, you need to know what that owner can contain. That is where the production conversation has to land. Agents will keep getting more capable, more connected, and more useful. The enterprises that benefit will be the ones that build enough containment around them to use that capability without pretending autonomy is harmless.

Cheers,

Apramit Bhattacharya

Editor-in-Chief

The larger point being made is that agents are moving from answer boxes into operational workflows. Once they can inspect systems, correlate signals, suggest fixes, or touch identity paths, the question becomes practical very quickly: how do we build them, constrain them, approve their actions, and make sure humans still own the decision?

That is the thread running through the next two sessions as well. One looks at agentic infrastructure engineering inside Kubernetes. The other goes back to the identity layer that decides who, or what, should be allowed to act in the first place.

Aug 27th · Agentic AI for Infrastructure Engineering: From Chatbots to Operators

Ritesh Vajariya, founder & CEO - AI Guru, teaches you how to build an infrastructure agent that reads pod events, correlates live metrics, and proposes fixes it only executes once you approve, replacing the documentation chatbot most platform teams already outgrew. Seven production-grade failure scenarios, injected into your own local Kubernetes cluster, yours to keep and re-run after the session ends.

Book Now

If your Docker and Kubernetes fundamentals need shoring up before you get there, The Ultimate Docker Container Book (4th edition) by Dr. Gabriel Schenker is the deepest single resource we carry on containers through orchestration, and its latest edition adds AI-driven DevOps patterns on top.

Check it out on Amazon

Aug 29th · Active Directory and Entra ID in a Modern Hybrid Architecture

Professor Robert McMillen breaks down how traditional Active Directory and Entra ID work together in real hybrid environments: domains and group policy on one side, cloud identity and SSO on the other, and Entra Connect bridging them. Built for IT pros moving into infrastructure or identity-focused roles.

Book Now

Since the session is already an add-on to the Azure basics going in, Microsoft Azure Fundamentals Certification and Beyond (built around the January 2026 AZ-900 update) is worth having on hand beforehand, especially if you’re eyeing the certification alongside the hands-on identity work.

Check it out on Amazon

Before you go, I’d like to hear from regular CloudPro readers. Hit reply and tell me what would be most useful for your team. And if this issue helped sharpen the conversation, please like it and leave a comment so more platform, cloud, security, and infrastructure folks can find it.

Over the last three issues, Jaroslav Pantsjoha has been building a clear argument about enterprise AI. Part 1 asked what happens after the demo works. Part 2 showed why the tenth agent stops being a use case and starts becoming a platform problem. Part 3 moved the bottleneck again: AI may accelerate the build, but the enterprise still has to learn how to absorb the output.

This final issue lands the series where I think the real enterprise AI conversation now has to go: ownership. Not just who builds the agent. Not just where the platform sits. But who owns the workflow when it is live, who governs the output, who evaluates whether it is actually right for the business, and who carries accountability when it breaks.

That is why this is useful for CloudPro readers. Many of you are already close to the systems, platforms, and delivery models that will have to support this shift. The agent itself is becoming easier to build. The harder question is whether the enterprise has the operating model around it: the owner, the governance, the context, the evaluation discipline, and the Day 2 structure that keeps it alive after the demo.

Jaroslav’s final argument is sharp: the Agentic Enterprise is not the one with the most agents. It is the one that knows what those agents are for, who owns them, how they are governed, and what definition of good they are allowed to optimize toward.

A big thank you to Jaroslav for writing this four-part series for CloudPro and for giving us a practical language for a conversation most organizations are only just beginning to have. Read the final piece, and tell us what you think: is ownership becoming the missing piece in your enterprise AI work too?

Cheers,

Apramit Bhattacharya

Editor-in-Chief

I keep coming back to one picture: the AI Adoption Maturity triangle. At the base is Discovery, where individuals trial the tools. Then comes Crawl, where teams adopt AI SaaS and call it a milestone, when really it is just the new baseline. Walk is where humans and AI become a single way of working across a team. Run is the top, where the real magic starts: agents extend the team, and the impact compounds.

I posted this triangle on LinkedIn again recently; it’s the same one I first drew back in 2025. And it landed harder than it did then. Not because the tooling suddenly became perfect. Because more people have now felt the climb.

In this “age of abundance”, AI-powered demo churn is cheap. Useful, yes. Impressive, often. Sometimes even a real signal of business value. But a demo still proves only that the task is achievable. It does not prove that the enterprise can adopt it, operate it, govern it, or scale it beyond the team that built it.

That is where the question changes. The moment you build your second agent, and then your tenth, the promise of AI transformation moves beyond you and your immediate team. Now other parts of the organization want to explore it, adopt it, deploy it, and turn it into real business use cases. And once again, the old bottleneck shows up wearing new clothes: process, ownership, operating rhythm. The build got fast. The enterprise around it stayed heavy.

Agentic transformation is an operating-model decision disguised as a technology conversation. Most enterprises have not really made that decision yet. The category is barely two years old, and the seat that owns it does not clearly exist on most org charts. Yes, there are AI titles aplenty. But experience building, running, and operating production AI agent platforms is still thin. That gap is starting to show.

The top of the climb has no owner

That gap shows up most clearly at the handover point: when the people who build the agentic system step back, and the enterprise has to decide what happens next. I think we are conflating two things at once, and that is where a lot of the confusion comes from.

On one side, there is BUILD: enablement, harness, and cloud foundations at the bottom; the agent platform in the middle; and reimagined business workflows at the top. The industry has had a decade to learn how to deliver cloud-native systems, and it is now extending that muscle into agents. The two ends of that triangle are reasonably staffed. There are superstars who can build, and there are thought leaders who can hold the vision.

On the other side, there is OPS. Same three layers again, but the middle is still emerging: data engineering, AI operations, centres of excellence, and the platform play that sits around them. That part is starting to take shape.

The problem is the top. When the BUILD phase hands over, who on the OPS side owns the reimagined business workflow at scale? Not the infrastructure. Not the model endpoint. Not the platform plumbing. The workflow. The thing the business now depends on.

That is the role almost no enterprise has hired for. When the build hands over, who on the customer side actually owns and runs it?

You can feel the temptation here, and it is the wrong move. When the customer has nobody lined up to own that top role, the delivery team’s instinct is to quietly fill the gap and keep operating the thing it built. That looks helpful in the moment, but it hides the role gap, removes the pressure to hire, and turns the delivery team into the long-term operator of someone else’s platform. Fine as a transitional posture for six to twelve months. Not fine as the steady state.

And the questions do not go away. Who is accountable? Who understands the reimagined workflow now that it is live? Who has the mandate, budget, and authority to keep it running? The honest answer, more often than not, is that the role does not exist yet. No customer I have worked with has run an agent platform before, so there is often no clean name to give the job.

And that matters commercially too. You can spend a couple of million to build this. You do not want to spend millions again, indefinitely, just to keep operating it.

So the operating model needs a real owner: one named person on the customer’s side, funded and accountable for running the platform once it is live.

Day 1 is a demo. Day 2 is a mandate.

If the operating model needs a named owner once the system is live, that person has to be in the room while the thing is being built.

There is a tempting version of delivery where you build the capability, demo it, and hand it over with a wave. “Enjoy the system, we are off.”

I call that build-and-depart, and it is the most expensive pattern in this whole space. It produces something impressive that quietly becomes unsupportable the moment the people who built it look away.

Someone has to be there on Day 2, and you onboard them on Day 1.

My suggestion is simple: start onboarding the people who will own and operate the system while it is being built, not after. Yes, I hear you muttering that that may cost more. In many organizations, there may not be enough external capacity to resource this cleanly, so the customer has to pick up the tab, strengthen the team, and train the people who will run it. So, yeah, it may cost more in the short term. Heck, it will cost more. But this is new technology, and the prize for getting it right ahead of your competition is large enough to justify the investment.

Treat operations as part of delivery. Put the operators in the room from the start.

That handover is also where the commercial shape changes, and it is worth naming plainly. There are two different questions here:

• The first is whether the non-deterministic platform is healthy: endpoints up, guardrails firing, monitoring in place, failures visible. That is agent operations.

• The second question is harder: is the output actually right and good for the business? That is evaluation.

A green platform serving a confidently wrong answer is the failure that lives in the gap between operations and evaluation. And evaluation is a business owner’s job, not a purely technical one, because correctness is contextual to the domain. The spotlight finds the agent first. What keeps it alive is the unglamorous structure around it.

Underneath all of this sits one principle I will argue day in and day out:

AI cannot be held accountable. The end.

An agent can do the work, but it cannot own the judgment, the liability, or the consequence. Accountability never delegates down to the agent. A human always carries it, and in practice, that human is usually the subject matter expert or the business owner who feels the SLA when it breaks. If you need human-in-the-loop governance (and you absolutely do), you have to architect for it from the start.

This is not a fringe opinion anymore. The platform vendors are building it into the product. Microsoft, for one, will not let an agent identity exist without a named human sponsor accountable for it, and if that person leaves, accountability transfers automatically to their manager. No unowned autonomy.

When the tooling itself refuses to let an agent run without a human name against it, the argument is over. Accountability has to be distributed across the business, platform, security, and data. And it has to be explicit. That is the hard organizational design problem sitting underneath all the technology, and it is the one leaders are often most relieved to finally say out loud.

There is a counter-move showing up now that looks like a way out, and it is worth naming because it is not one. A market is forming to underwrite the risk: certify the agent, insure the residual, treat it like any other operational exposure. Most enterprises will probably buy that, and they probably should. But an underwriter can only price the downside of a wrong answer. It cannot know what a right answer looks like in your business, against your data, for your regulator.

You can insure the residual. You cannot outsource the why. That stays in-house, with a name against it, or fifty thousand agents optimize for a standard nobody set.

The AI-native vision

That sounds restrictive, but it is actually the path to the AI-native enterprise. I am not gloomy about any of this, because the direction of travel is clear. And frankly, it is the interesting part.

AI-ready stopped being a differentiator the moment everyone started getting there. A short mile from now, everyone will be there. A double-digit efficiency gain is table stakes now, the kind of number that used to win a board slide and today earns a shrug. The interesting question has moved to the next leap.

The differentiator is moving to AI-first: the organization that reaches for an agent before it reaches for headcount. Past that is AI-native, where systems talk to systems through well-orchestrated AI, the pipelines are mature, and the multiplier behind it is genuinely large. That is the move that defines the top of the climb: imagining the processes agents make possible, not just optimizing the ones you already have.

A recent Deloitte post puts only about one in nine organizations with agents genuinely in production, with roughly a third still piloting. That is the floor. Google DeepMind, by contrast, reports running about a quarter of its own internally built agentic systems in production. That is the demonstrated ceiling. And the gap between the two is not set by model capability. It is set by operating discipline.

In two to three years, agents may outnumber humans in your organization, and the early adopters are already building towards that world. The way you stay coherent at that scale is to codify the why: your mission, your guardrails, your definition of good, as governed, version-controlled context that agents can consume. Leave culture as an oral tradition, and fifty thousand agents will optimize for fifty thousand definitions of success.

That is the risk if the apex seat never gets hired. This becomes another entry in the graveyard of digital transformations: expensive, repeated, well-intentioned, and stalled in the same place. The technology will keep arriving on schedule. What stalls is the climb. And the climb stalls on a role nobody owned.

That is also why this is not just the cloud-migration playbook again. That playbook gets you to the bottom of both triangles. It helps with foundations. It helps with platforms. It does not get you to the middle or the top. It does not give agents context, accountability, operating discipline, or a business definition of good.

Where this is going?

So where does the climb end? Not with more agents. Not with a better model. The agent is becoming a commodity. So is the model. What differentiates one enterprise from another is the harness around them: the context, the governance, the tooling, the evaluation, the ownership, and the operating model that let humans and agents run as one coherent system.

That is the thread underneath all four posts. The demo proves the task is possible. The platform makes the agents reusable. The harness turns individual speed into team capability. But the operating model is what decides whether any of it survives contact with the enterprise.

That is why I am writing Architecting the Agentic Enterprise on Google Cloud. It releases in September. The book is the field guide for the harder part: designing the platform, governance, operating model, and delivery discipline that let agents move from clever workflows to production systems that can actually be owned, governed, evaluated, and improved.

Google Cloud is the practical implementation baseline in the book, but the discipline is bigger than any one stack. The vendor will change. The model will change. The tools will change. The hard questions will not. Who owns the workflow? Who governs the agent? Who evaluates the output? Who carries the accountability? Who keeps the context true when the business changes?

That is where this series lands. The future will not belong to the enterprise with the most agents. It will belong to the enterprise that knows what those agents are for, who owns them, how they are governed, and what definition of good they are allowed to optimize toward.

That is the Agentic Enterprise.

About the author

Jaroslav Pantsjoha is a Technical Director, Agentic AI Platforms, and a Google Developer Expert focused on taking AI systems from demos to production. He designs and delivers enterprise agent platforms, with work spanning architecture, governance, delivery models, and the operating changes needed to make AI systems run at scale. His current work focuses on the practical gap most organizations are now facing: how to turn promising proofs of value into production systems that are owned, governed, and accountable.

You can follow him on Linkedin here

Jaroslav’s series has spent the past four weeks examining what it takes to move agentic AI beyond the demo and into production.
The next three sessions take that conversation into the infrastructure trenches, beginning with a NetOps assistant grounded in the operational knowledge your teams already trust.

Sif Baksh is back, and seats for Agentic RAG for Network Operations are moving fast

Agentic RAG for Network Operations - Tuesday, August 25th, 9 AM EDT

Sif Baksh, Principal Solutions Architect at Tines, is teaching you how to build a RAG-powered NetOps assistant that pulls answers from your own runbooks, device configs, and troubleshooting notes instead of the open internet, so it can tell you why a BGP neighbor is stuck in Active, with the actual source cited. You’ll also learn the guardrail patterns that stop the assistant from inventing answers or recommending unsafe production changes, so it’s something you can trust mid-incident.

This one’s capped on seats and going quicker than usual. Use code LIMITED40 for 40% off.

Book now

P.S. - We have a special bundle for you!
Sif’s own book, Building AI Agents for Network Operations, walks through the same architecture end to end: parsing CLI and BGP output, building the troubleshooting agent, packaging tools with MCP.
Grab the ticket + book bundle at checkout, or pick up the book on its own if the event timing doesn’t work for you.

Check it out on Amazon

Aug 27th · Agentic AI for Infrastructure Engineering: From Chatbots to Operators

Ritesh Vajariya, founder & CEO - AI Guru, teaches you how to build an infrastructure agent that reads pod events, correlates live metrics, and proposes fixes it only executes once you approve, replacing the documentation chatbot most platform teams already outgrew. Seven production-grade failure scenarios, injected into your own local Kubernetes cluster, yours to keep and re-run after the session ends.

Book Now

If your Docker and Kubernetes fundamentals need shoring up before you get there, The Ultimate Docker Container Book (4th edition) by Dr. Gabriel Schenker is the deepest single resource we carry on containers through orchestration, and its latest edition adds AI-driven DevOps patterns on top.

Check it out on Amazon

Aug 29th · Active Directory and Entra ID in a Modern Hybrid Architecture

Professor Robert McMillen breaks down how traditional Active Directory and Entra ID work together in real hybrid environments: domains and group policy on one side, cloud identity and SSO on the other, and Entra Connect bridging them. Built for IT pros moving into infrastructure or identity-focused roles.

Book Now

Since the session is already an add-on to the Azure basics going in, Microsoft Azure Fundamentals Certification and Beyond (built around the January 2026 AZ-900 update) is worth having on hand beforehand, especially if you’re eyeing the certification alongside the hands-on identity work.

Check it out on Amazon

Over the last two weeks, Jaroslav Pantsjoha has been pulling enterprise AI away from the demo table and into the real operating environment. Part 1 asked what happens after the AI demo works. Part 2 showed why the tenth agent stops being a neat use case and starts becoming a platform problem. This week, Part 3 moves to the next bottleneck: the organization itself.

My view is that this is where the enterprise AI conversation now needs to get more serious. Most technical teams already understand that AI can make building faster. Code, drafts, integrations, workflows, prototypes: all of that can now move at a speed that would have been difficult to imagine even a couple of years ago. But the enterprise around that work does not automatically move at the same speed. Trust still takes time. Governance still has to make decisions. Teams still need shared context. People still have to change how they work.

Many of you are close enough to the work to see both sides of this shift. The build is getting faster, but the enterprise around the build still has to deal with ownership, review paths, shared context, and human alignment. That is where a lot of AI adoption will either become real or quietly turn into another layer of disconnected shortcuts.

This issue is about that operating change underneath enterprise AI. Read it, and tell us what you think: is absorption becoming the real bottleneck in your organization too?

Cheers,

Apramit Bhattacharya

Editor-in-Chief

Our upcoming events this month

1. Agentic DevOps with Claude - Thursday, July 23rd · 11:00 AM EDT

Where do agents and MCP servers actually belong in a Kubernetes stack?
Most platform teams are still guessing. Michael Rishi Forrester (Accenture) spends four hours building a 33-component AI-native IDP live, on a provisioned cluster, with Claude Code doing the actual work: scaffolding Helm values, wiring up ArgoCD’s App-of-Apps, resolving sync issues as they come up. You clone the repo when it’s done and it runs.

Event will be live in under 24 hours - FINAL CALL. Use code FINAL40 for 40% off.

Book Now →

2. AI-Powered GitOps & Platform Engineering - Thursday, July 30th · 11:00 AM EDT

Most AI-in-GitOps failures trace back to one thing: stale context, not a bad model. Taylor Dolezal (Head of OSS at Dosu) has seen this pattern across 100,000+ repos, and this session runs a live query against fresh vs. stale knowledge side by side, so you can see where the token cost actually goes and where the accuracy breaks down before you build anything on top of it.

Use code FINAL40 for 40% off.

Book now →

Both sessions are teaching the same shift from two different angles, Michael’s building the platform itself, Taylor’s making sure the agents on it aren’t running on stale context. Worth sitting through both if you’re the one who’ll own this stack. Bundle Pass gets you both for 25% off - use code BUNDLE25.

Get the bundle

Enterprise AI moves faster than most organizations can absorb. I seem to be circling this point a lot lately, but it keeps showing up because it is becoming the bottleneck. AI changes the build phase. It supercharges the way teams create things: workflows, standards, accelerators, proofs of value, even the culture of work around them. What it does not change, at least not on its own, is the enterprise around the build. And that gap is the whole problem in this post. A lot of transformation programs are still quietly tiptoeing around it.

I see this most clearly in sharp delivery teams. A small team gets hold of good agent tooling and suddenly starts delivering at a pace that would have been impossible a year or two ago. Fewer people. More output. Real business outcomes. And yes, you and I can already build a lot on our own with an AI harness and a particular set of skills. I take part in hackathons. I know what a motivated individual can do with the right tools. But my squad is not building hackathon demos. My squad is building business outcomes. SOW-measured outcomes.

So the question that actually matters is not whether an individual pioneer can move fast. We know that already. The question is how you scale that capability into a team, and then across an organization that still moves at the speed it always has. What does that even look like? Is it just a few shared skills and workflows for Antigravity or Claude? Or is there more to it?

That is the new bottleneck. Not the model. Not the build. The bottleneck is the enterprise’s ability to absorb what its best people can now produce: the demos, the proofs of value, the accelerators, the sudden jump in output. AI accelerated the build. The organization’s ability to absorb the output did not move with it.

The build got faster. The change did not.

Be precise about what AI accelerated. It accelerated the building of things: code, analysis, first drafts, integrations, and the work that used to eat a delivery week. That part is genuinely transformed.

What it did not accelerate is everything change has always depended on. People still have to trust the output and adjust how they work around it. Processes still have to be redesigned. Because if you put AI over the top of a broken process, the moment people get frustrated with that process again, they will start blaming AI for the same old problem. That is not an AI problem to solve. It is an organization problem.

Governance still has to say yes. And governance built to review a quarterly release does not magically learn how to review a daily one just because the build got faster. None of that runs at model speed. It runs at organizational speed, often for good reasons.

Forrester put a number on the mismatch. Around three-quarters of leaders say they are adopting agentic AI, while only a small minority are running anything beyond an agent-ish chatbot in meaningful production. The chase is nearly universal. The catching is rare.

The harness is for the team, not just the individual.

That is where the harness matters. Not as a personal productivity trick, but as the thing that lets a team absorb the new speed without turning every workflow into one person’s private setup. This is the piece I’ve become most convinced of while building accelerators and bootstrapping teams over the last couple of years. You start to see what keeps repeating. You build skills, you build sub-agents, you connect agentic reasoning to deterministic tools, and suddenly the team starts delivering fast. The tool you pick for that, Claude Code, Antigravity, Cursor, whatever your team standardizes on, matters far less than people think. The leverage was never the tool. The thing you are usually missing is the harness.

By harness, I mean the codified working system around the tools: the standards, the reusable skills and slash commands, the context files, the review paths, the definition of done, the test expectations, and the operating habits that let a whole team use agents the same way. Not your personal setup on your machine. The team’s. The question is not what good looks like for you. It is what good looks like for the team.

So you write it down and make it reusable. We ended up with sixteen, then twenty reusable skills and slash commands for governance, technical expertise, quality, and validation. That codified harness becomes the team’s central nervous system. It holds the thinking, the decisions, and the architecture. The first thing someone reaches for is not a colleague. It is the repo. And if it is not in the repo, the agent does not know. It has to be captured in the working system, or it is not real yet.

If you want somewhere concrete to start, it is not a tooling decision. Write down your definition of done, and turn your three most-repeated tasks into shared skills the whole team invokes the same way. That is a harness in embryo. It is the moment AI stops being personal productivity and starts becoming a team capability.

That is the difference between a pioneer running ahead and a team moving together. It is also why five or six engineers can deliver what a statement of work once put thirty people on, in a fraction of the time. The harness makes the way of working reusable. The number sounds insane until you remember that this is the same trick every mature engineering practice has always used, applied now to how we work with agents.

Enablement is not just another training course.

Once the harness works for one team, the next mistake is to think you can spread it with training alone. That is usually the reflex when organizations hit the absorption problem. Roll out a curriculum, tick the box, declare everyone enabled. That is not it.

Do not send someone a deck. Show them. Book a couple of hours, take them through a real problem, and build some of it live so they can see how it is done. Solve one problem with them, and they start to understand how to solve the others. That is what the working version looks like. Enablement is not a slide deck about the new way of working. It is the concrete bundle around it: the patterns, the playbooks, the guardrails that make the safe path the easy path, the review routes, and the ownership model that lets people do this work well without each person figuring it out alone.

And you have to own it, because it is easy for the harness to get out of whack. Garbage in, garbage out. It happened to us. Someone on the team owns the architecture skill. Someone owns the infrastructure expert. Someone keeps each one current against the codebase. That ownership is the work.

Here is the part I have landed hardest on: the new ways of working are the adoption model.

There is no separate adoption initiative that happens after the technology lands. How the work gets done, who owns what, how humans and agents share a task, that is the transformation. The technology is the easy half. Reshaping how the organization works around it is the half that decides whether any of it sticks.

McKinsey found that only about one percent of leaders rate their company as mature on AI, and the fix they point to is structural: rewiring the organization around new operating models. Enablement, in the concrete sense above, is what that rewiring runs on.

The human alignment problem, with other humans.

And once you try to spread the harness beyond one team, you run into the oldest enterprise problem there is: humans aligning with other humans.

For decades, enterprise delivery ran on a relay. Business defined the need, handed it to delivery, delivery handed it to platform and ops, and security and legal reviewed it at the gates. That worked when building was the slow part.

But when a team can build in a fraction of the old time, every downstream handoff is where the time now goes. With a small, harnessed team, you barely feel it. One morning stand-up, and the context and decisions from it get fed straight into the ecosystem: distilled, captured, actioned. A large team is the opposite. Multiple workstreams, interconnects, shared context, more meetings, more translation. The speed leaks into the gaps between people.

The answer is not to rip out the gates. You still need governance. You still need security. You still need legal. You cannot remove those steps just because the build got fast. Putting a veneer of AI over a broken organization does not fix the organization.

The bottleneck did not disappear when the build got fast. It moved downstream to absorption and governance.

And this is where I push back on a popular myth. There is an implicit assumption that the hard new problem is human-to-AI alignment. No. It is human-to-human alignment, and it has been a problem forever. It is why we have scrum, SAFe, waterfall, PI planning, all those meetings, all those rituals, and we still get it wrong.

The harness does not make that go away. The harness is where you finally write the alignment down.

Power users will run ahead, paving the road behind them.

Once you write the alignment down, the next job is to stop treating it as one team’s private advantage. Power users emerge whether you plan for them or not. A handful run ahead, push the envelope, prove what is possible, and build muscle that the rest of the organization does not have yet. That is more than fine. The ones you want are the SMEs who know what good looks like, have the track record to ask the right questions, and can feel the world changing fast enough to want to be ahead of it.

Your job as a leader is not to hold those pioneers back to the average. It is to take what they prove and turn it into paved roads everyone else can travel: the reusable skills, the playbooks, the guardrails, the review paths, the ownership model. That conversion, from individual proof to repeatable practice, is the transformation. I have watched it compound. Prove it once, and other teams start reaching out asking to replicate the setup. The tooling is available to everyone. What is not available to everyone is an organization that knows how to absorb it. That is the edge.

Becoming agentic is a ways-of-working change first and a technology change second. And if a ways-of-working change is going to last, it cannot remain a few private workflows, clever prompts, or generated versions of “definition of done.” It has to become something more durable. An operating model. Codified. Owned. Updated. Shared culture, as shared context.

That is the good news and the work. There is plenty to do, but the direction is clear. We need to cohere around these new ways of working so agentic systems do not become yet another set of silos. We need consistent, complete AI solutions that the organization can absorb, govern, and improve. That is how you move from scattered power users to an enterprise that can actually use the potential AI has put on the table.

Stick around for next week’s post. That is where we get into how to think through and start building the Agentic Enterprise.

About the author

Jaroslav Pantsjoha is a Technical Director, Agentic AI Platforms, and a Google Developer Expert focused on taking AI systems from demos to production. He designs and delivers enterprise agent platforms, with work spanning architecture, governance, delivery models, and the operating changes needed to make AI systems run at scale. His current work focuses on the practical gap most organizations are now facing: how to turn promising proofs of value into production systems that are owned, governed, and accountable.

You can follow him on Linkedin here

Here’s our star event for the month of August, Sif Baksh returns again!

Agentic RAG for Network Operations - Thursday, August 25th · 9 AM EDT

Sif Baksh, Principal Solutions Architect at Tines helps you build a RAG-powered NetOps assistant that pulls answers from your own runbooks, device configs, and troubleshooting notes instead of generic internet answers, so it can tell you why a BGP neighbor is stuck in Active, with the actual source cited. You’ll learn with guardrail patterns that stop the assistant from inventing answers or recommending unsafe production changes, so it’s something you can actually trust during an incident.

Use code SPECIAL40 for a 40% off on the event

Book your tickets

Before you go, maybe a few books worth having on your shelf

1. LLMs for Modern Software Delivery and DevOps - Gu Huangliang, Zheng Qingzheng, Niu Xiaoling, Che Xin
   

   Check it out on Amazon →

Taylor's upcoming GitOps workshop on 30th July is built around one idea: knowledge freshness beats model choice. This book takes that same premise and runs it across the entire delivery lifecycle, log triage, testing, code review, incident response, so if the workshop's context-engineering angle clicked, this is the fuller playbook behind it.

2. From Cloud Native to AI Native - Pini Reznik, Michael Müller
   

   Check it out on Amazon →

   

   
   Michael's session shows Claude Code building a 33-component platform live.
   This book is the "why" underneath that build: how the same cloud-native patterns you already trust (GitOps, Kubernetes, observability) extend into AI-native architecture, instead of getting ripped out and replaced.

3. The Self-Taught Cloud Computing Engineer - Dr. Logan Song

   Check it out on Amazon →

If you're building toward a platform or SRE role and keep bouncing between AWS, Azure, and GCP docs without a throughline, this book takes the "learn one deeply, then compare" approach instead of three separate crash courses, compute, storage, security, and ML services mapped across all three.

AI agents are moving into prod. Is your secrets strategy ready for that?

Find out at the webinar on July 22nd

Register Now

Hi,

Last week, Jaroslav Pantsjoha opened this series with a blunt argument: your AI demo worked, but that is no longer the impressive part.

The first part was about the production gap. Enterprise AI does not usually fail because teams cannot build useful proofs of value. It fails when those proofs of value reach the production readiness door and run into the harder questions: who owns this, who runs it, who governs it, and what happens when it breaks?

This week’s piece picks up exactly there.

The first agent still looks like a neat business use case. The tenth starts to look like something else entirely. Each one-off may make sense on its own, but together they can become a pile of useful systems nobody can govern as a whole.

That is why the second part is about the hidden platform problem behind enterprise AI. If the first part asked what happens after the demo works, this one asks what the enterprise needs underneath before ten working demos become ten disconnected systems.

Cheers,

Apramit Bhattacharya

Editor-in-Chief

Our upcoming events this month

1. Agentic DevOps with Claude - Thursday, July 23rd · 11:00 AM EDT

Where do agents and MCP servers actually belong in a Kubernetes stack?
Most platform teams are still guessing. Michael Rishi Forrester (Accenture) spends four hours building a 33-component AI-native IDP live, on a provisioned cluster, with Claude Code doing the actual work: scaffolding Helm values, wiring up ArgoCD’s App-of-Apps, resolving sync issues as they come up. You clone the repo when it’s done and it runs.

Use code EMAIL40 for 40% off.

Book Now →

2. AI-Powered GitOps & Platform Engineering - Thursday, July 30th · 11:00 AM EDT

Most AI-in-GitOps failures trace back to one thing: stale context, not a bad model. Taylor Dolezal (Head of OSS at Dosu) has seen this pattern across 100,000+ repos, and this session runs a live query against fresh vs. stale knowledge side by side, so you can see where the token cost actually goes and where the accuracy breaks down before you build anything on top of it.

Use code EMAIL40 for 40% off.

Book now →

Both sessions are teaching the same shift from two different angles, Michael’s building the platform itself, Taylor’s making sure the agents on it aren’t running on stale context. Worth sitting through both if you’re the one who’ll own this stack. Bundle Pass gets you both for 25% off - use code BUNDLE25.

Get the bundle

The first agent you build feels like a product problem. And it is.

That is the beauty of where we are now. AI and agents let business domain experts amplify what they already know with AI-powered workflows. Someone sees a problem, wraps a model around it, adds a connector or two, and suddenly, there is a working proof of value. Great.

But by the tenth demo, it starts to look different. You realize you have built sprawl where you wanted leverage. You wanted a capability multiplier. What you got was ten bespoke things. The first agent has its own service account. Fine. Good start. A few demos fetch data through connectors. Maybe A2A, agent-to-agent, would be better suited in some cases. Maybe not.

And that is when the real questions start turning up:

• How is data access being governed?

• Who can see what?

• Who decides what one agent is allowed to call?

• Who checks that these capabilities stay coherent, consistent, and correctly implemented?

• And who can answer any of that across the whole estate?

Together, it becomes a pile of bespoke systems nobody can govern as a whole.

The line I find myself using early now is this: the local AI harness is the easy bit. And yes, I know it has its own challenges. The harness is whatever you wrap around a subscription so you can reuse it. It is the quickest way to get started and the easiest way to show value. That is where the harness stops being enough.

Now you are in platform territory.

The governance. The security controls. The monitoring. The observability. Release management for agents sounds simple enough. It is still programmatic. You still test it. There is no magic to it.

But that is the agent layer sitting on top of an agent platform. And most teams do not have the platform. They jumped straight to the top bit: can I have agents, and can I release them? And they quietly assumed everything underneath already existed.

It doesn’t.

The first agent hides the problem

That is why this is so easy to walk into. The first agent may genuinely not need a platform. It might just be a SaaS-y AI-powered workflow. Think Gemini Enterprise, or something like n8n, plus a few connectors. One use case. One team. One problem to solve. Build a whole platform for that, and you would rightly get called out for over-engineering.

So the trap is obvious only in hindsight. The second agent, the third agent, and the tenth agent each feel like they do not need a platform either, taken alone. Every decision to build another one-off is locally reasonable. It is only when you stand back and look at the whole portfolio that the cost shows up. Now you have ten different answers to questions that should have had one.

The scatter is measurable too. McKinsey’s State of AI in 2025 found that only 23 percent of respondents say their organizations are scaling an agentic AI system somewhere in the enterprise, while another 39 percent are still experimenting. In a separate piece on scaling agentic AI, McKinsey puts the gap even more sharply: nearly two-thirds of enterprises have experimented with agents, but fewer than 10 percent have scaled them to deliver tangible value. That feels right to me.

The shortage is rarely the agent itself. It is agents that connect beyond the one workflow they were built for.

Agents that share identity, access, governance, observability, and evaluation instead of solving all of that from scratch every time. That is where the one-off stops being clever and starts becoming expensive.

What the agent platform actually is

Once you stop looking at each agent as a one-off, the shape gets clearer. I treat the agent platform as its own layer, separate on purpose. At the bottom, you have cloud foundations: deploying projects programmatically, infrastructure as code, the usual base layer. That part is industry vanilla by now. At the top, you have the agent solutions, the actual business use cases. In between sits the agent platform, and everything in and around that platform is the meat.

This is the crux of it. Identity, so an agent acts as a known principal with the right permissions, not a shared god-mode account security will rightly veto. I’m watching agent identity move from ordinary service accounts toward proper, first-class agent identities. Then a gateway, so you have visibility into what each agent does, when it does it, and what it touches.

The point is not to give the agent free rein to “go and fetch me stuff.” The point is to let it work inside the scope it has been given.

Then you need the rest of the platform pieces. An agent registry. The protocol servers you have to run, deploy, and secure. Observability and evaluation, so you know the output is still correct after a model upgrade, not just that the service is up. And governance sitting over all of it.

I build most of this on Google Cloud, so that is the lens I naturally reach for. The managed pieces for identity, gateway, registry, evaluation, and observability are there to stand on instead of hand-rolling everything yourself. More importantly, you inherit governed defaults rather than inventing your own and getting them subtly wrong.

Build each of those once, well, and every team stands on them. Build them ten times, scattered across ten projects, and you have ten times the surface area to secure and no consistent way to answer for any of it.

This is where the agent platform stops being a nice idea and becomes a necessity. It is separation of concerns and separation of duties, applied to agents. And it is a different beast from just standing up another landing zone on another cloud.

The leadership point hiding inside the architecture is simple: a shared platform is shared accountability. Ten teams standing on one governed platform answer for their agents the same way. Ten one-offs answer ten different ways, which usually means no way at all. And treat that governance layer as an accelerator, not a brake. It is the thing that lets you ship the next fifty agents safely instead of re-litigating risk every single time. You can see that shift in the open now. Santander has published open-source AI projects from its AI Lab, including work around governance, hard gates, and decision controls on GitHub When a bank is willing to put that kind of control layer in public, governance has clearly moved from private moat to shared foundation.

The wider industry is circling the same point. a16z’s Big Ideas 2026 frames AI as an enterprise orchestration layer: a move from isolated copilots to coordinated systems that work across teams and tools. That is the platform argument in another language. The durable value is not just in the agent. It is in the layer that coordinates context, tools, permissions, and execution across the whole estate.

We’ve built platforms before. This one’s harder, yet familiar

None of this is entirely new, which is useful to remember. We’ve built platforms before. Container platforms, internal developer platforms, cloud landing zones, paved roads. Different names, same basic instinct: stop every team from solving the same operational problem from scratch. This isn’t the first platform I’ve built and deployed. Think container platforms back in the day. Same shape, more complex.

The complexity now is that there is non-determinism in the ecosystem. The instinct that served me then serves me here: avoid bespoke where you can. I keep custom wheel-creation to a minimum and lean on managed services, because anything bespoke goes out of date fast and turns into operating tech debt.

But here’s the catch that is genuinely new.

Even when you use a managed platform, you still have to make the calls.

Which model do you swap out? When do you swap it? What changes when you do? That is a whole new skills profile, and most teams have to adapt to it.

And the platform cannot become a free-for-all of services either. Interweave too much of it, and you get latency. Before you know it, you cannot tell what speaks to which system, or which one is meant to be the source of truth. That is the classic way these things go badly wrong. One small thing gets tweaked, and the downstream impact gets amplified.

Which is also why I push back early and often: half the time, you do not need an agent for that. It is just automation. It is really good Terraform. Put an agent on a deterministic job, and all you have bought is non-determinism you will have to govern, for no reason.

The vendor changes the names of the services. It does not change the shape of the trap. Whatever stack you are on, the question is the same: is every team solving identity, data access, evaluation, and deployment from scratch, or are they building on a paved road that solved those once?

Who owns the paved road?

Once you decide the enterprise needs that paved road instead of ten one-offs, the next question arrives quickly: who owns it, who runs it, and who keeps the lights on once it is live? Because once it is live, it keeps moving. And someone still has to be accountable for that.

This is where the SaaS pitch starts to become a risk. Everyone is learning how to adopt this at the same time, and the market is full of people selling the dream: deploy it, demo it, go live. But a real enterprise carries legacy. Data sources all over the place. Integration that is genuinely painful. Ownership lines that were already messy before an agent entered the room.

You deploy the shiny thing, and now it is disconnected from your estate, your data, and your moat. We can all agree that is not the most intentional of outcomes. To make it real, you have to blow it out, bring in more stakeholders, and turn it from a clever deployed thing into a reusable agent platform the whole organization can stand on.

And that is not just a technology question anymore. It is a people and process challenge. So if you are ready to keep following this enterprise adoption journey, that is where I want to go in the next post.

About the author

Jaroslav Pantsjoha is a Technical Director, Agentic AI Platforms, and a Google Developer Expert focused on taking AI systems from demos to production. He designs and delivers enterprise agent platforms, with work spanning architecture, governance, delivery models, and the operating changes needed to make AI systems run at scale. His current work focuses on the practical gap most organizations are now facing: how to turn promising proofs of value into production systems that are owned, governed, and accountable.

You can follow him on Linkedin here

Here’s our event for the month of August

Agentic RAG for Network Operations - Thursday, August 25th · 9 AM EDT

Sif Baksh, Principal Solutions Architect at Tines helps you build a RAG-powered NetOps assistant that pulls answers from your own runbooks, device configs, and troubleshooting notes instead of generic internet answers, so it can tell you why a BGP neighbor is stuck in Active, with the actual source cited. You’ll learn with guardrail patterns that stop the assistant from inventing answers or recommending unsafe production changes, so it’s something you can actually trust during an incident.

Use code SPECIAL40 for a 40% off on the event

Book your tickets

Before you go, maybe a few books worth having on your shelf

1. Operational AI with Docker - Ajeet Singh Raina & Harsh Manvar
   

   Check it out on Amazon →

If Michael's event - Agentic DevOps with Claude IDP build got you thinking about what it actually takes to run agentic workloads in production, not just prototype them, this is the deeper dive. It covers containerizing, serving, and scaling LLMs and multi-agent pipelines with Docker and Kubernetes, the infrastructure layer most "AI for DevOps" content skips past.

2. AI Networking Cookbook - Eric Chou
   

   Check it out on Amazon →

   

   Pairs naturally with Sif’s session on Agentic RAG for Network Operations. Where the workshop builds you a RAG assistant for troubleshooting, this book is recipes for the other side, using AI to automate config, monitoring, and threat detection across multi-vendor network environments, with working code for each one.

3. Microsoft Intune Cookbook, 2nd Edition - Andrew Taylor

   Check it out on Amazon →

For anyone managing endpoints rather than the network layer, practical recipes for securing and automating devices across Windows, macOS, iOS, Android, and Linux, including where Security Copilot and Graph API now fit into day-to-day admin work.

Is your secrets strategy ready for AI agents?

Save your seat for Infisical’s webinar on July 22.

Register now

Over the last few CloudPro issues, we have kept circling the same problem from different angles. Before you give AI more access, build the boundaries. Before you give agents more autonomy, think in terms of least agency. And before agents become part of daily engineering work, understand what they are allowed to consume.

This special issue continues that thread, but from a slightly different angle: what happens after the demo works?

To answer that properly, we have invited Jaroslav Pantsjoha, Technical Director, Agentic AI Platforms, and Google Developer Expert, to write a four-part series for CloudPro. Jaroslav has spent the last few years taking enterprise AI systems from proofs of value into production, and this series is about the part most demos skip: ownership, operations, governance, cost, accountability, and the platform underneath.

This is the first part of that series. If the last few issues were about giving agents the right boundaries, this one is about what it actually takes to make those agents survive contact with the enterprise.

Cheers,

Apramit Bhattacharya

Editor-in-Chief

Agentic DevOps with Claude - Thursday, July 23rd · 11:00 AM EDT

Michael Rishi Forrester (Accenture) helps you build a live, 33-component AI-native Kubernetes platform in four hours, so you walk away with a working IDP you can clone and run Monday, not another slide deck. You’ll also get a reference architecture showing exactly where agents and MCP servers belong in your stack, something most teams are still guessing at.

Book Now →

AI-Powered GitOps & Platform Engineering - Thursday, July 30th · 11:00 AM EDT

Taylor Dolezal (Head of OSS at Dosu) helps you pinpoint exactly where AI agents earn their keep in GitOps workflows, drawn from patterns across 100,000+ repos Dosu supports. You’ll also walk through a live demo comparing fresh vs. stale knowledge, so you can see the token-cost and accuracy tradeoffs before you build anything.

Book now →

Given this is fast becoming a must-know skillset for every platform and DevOps engineer, grab the Bundle Pass for both sessions at 40% off instead of buying separately

Get the Bundle

Agentic RAG for Network Operations - Thursday, August 13th · 9 AM EDT

Sif Baksh, Principal Solutions Architect at Tines helps you build a RAG-powered NetOps assistant that pulls answers from your own runbooks, device configs, and troubleshooting notes instead of generic internet answers, so it can tell you why a BGP neighbor is stuck in Active, with the actual source cited. You’ll learn with guardrail patterns that stop the assistant from inventing answers or recommending unsafe production changes, so it’s something you can actually trust during an incident.

Use code EARLY40 for a 40% off on the event

Book your tickets

For the last three years, I’ve been building accelerators, demos, and proofs of value. Lately, I’ve also been taking them the rest of the way into production. Before that, I spent two decades watching each wave of technology actually arrive: VMware, Docker, Kubernetes, service mesh, GitOps. Now, it’s agents.

And from the inside, it always looks strangely similar.

In my work as an enterprise AI solution architect, I spend a lot of time in virtual meetings with people who are genuinely excited about what they have built, or what they want to build, and what it could do for their division. I get the excitement. The demos are real. The potential value is often real too. But potential value is not the same as production value. We do not need another proof of concept. We know what agents can do. Everyone does. At this point, most of what we are building is proof of value.

And proof of value is cheap now. I mean that literally. A senior engineer, a product owner, a good model, and an afternoon can together produce an agent that reads a document, reasons over it, calls a tool, and impresses a room. Such demos are now so cheap that they pile up. You end up with more tangible, valuable demos at your door than the enterprise can ever take in. And that, right there, is the new bottleneck.

You’ll may have seen the iceberg metaphor by now.

The demo is the shiny bit above the waterline. Underneath sit the things that decide whether it ever becomes real: ownership, operations, governance, integration, run cost, and accountability.

And in meeting after meeting, the same gaps appear. There is no agent platform team. There is no Ops motion. Nobody owns the platform. Nobody is accountable for it. So even if you, as the humble solution architect, have built and delivered a brilliant proof of value, solo or with a team, it is still yet another AI demo stacked up at the production readiness door.

The numbers say the same thing, and they are sobering. MIT NANDA’s The GenAI Divide: State of AI in Business 2025 found that 95 percent of organizations are getting zero return from enterprise GenAI investment, while only 5 percent of integrated AI pilots are extracting millions in value. The agent worked in the demo. The value never reached the P&L.

We don’t need more proofs of concept

For a while, the bottleneck genuinely was imagination. We didn’t know what these systems were good at or where they fell over. So we ran pilots, and the pilots were the point. They taught us the shape of the thing.

That phase is over, and honestly, it has become my allergy. Everyone still wants to prove a case. I find myself pushing back: the case has already been proven, guys. We’ve been there. We’ve done that. We’ve proven the capability exists. You cannot keep building more pilots and call that transformation.

The question that matters now is how you integrate this at scale inside the enterprise.

While most teams are still busy answering the old question, what’s striking is how fast the conversation has moved. Six months ago, many rooms were still arguing about capability: which model, which framework, how much autonomy to hand over. Now, the failure-rate reports that landed as shocks a year ago are just the baseline everyone quotes. The industry has swung from “what can these things do?” to “why can’t we run them?”

Forrester’s read on 2026 puts it plainly: the gap is not about models or ambition. It is about orchestration, control, and trust. That is the pace of this. A contrarian take from a year ago is consensus now, which means the interesting question has already moved past it.

A demo that works in a controlled setting tells you exactly one thing and nothing more: the task is achievable. It tells you nothing about whether the enterprise is ready to run it. We collapse those two all the time, because the first one feels so good.

Me being fast is not the enterprise being fast

Here’s the conflation that does the most damage, and I hear it constantly:

Someone says, “But I use agents every day … I can do anything now.”

I say, “Well, yes. You can. And you may move absurdly fast. But that still does not mean the work will see the light of production.”

I separate those two layers on purpose, because they get squashed together every time: the build phase and the operational one. A faster builder is not the same thing as a faster enterprise.

There’s a competitive-edge version of this too:

Everyone says, “Get the models, get the subscriptions, and your people go faster.”

I say, “Sure. But the moment everyone else has the same models and the same subscriptions, you’re not going any faster than they are. So where is the edge actually coming from?”

Subscriptions make an individual quick. They do not transform an organization.

AI adoption matures from the individual, to the team, to the enterprise:

Many organizations are still at the crawl stage, despite the fluffy marketing.

Organizations should be honest about their actual AI maturity, not the more optimistic version shown in internal leadership presentations. Most of what I see is furious motion on the bottom rungs: individuals and small teams flying, and that is mistaken for enterprise transformation.

Knowing your real rung is the first useful thing you can do, because the work to climb each one is different.

And that is the part the demo invoice never shows you.

The cost didn’t disappear. It moved.

So if the demo got cheap, where did the cost go? Two costs show up almost immediately, and neither appears on the invoice for the demo.

The first is enablement. And I don’t mean a training course. I mean, genuinely getting a whole team, then a whole organization, to work this way. Not just individuals like me poking at it in my IDE. That is culture, process, and people work.

So the question is, how do you get a team to use a subscription effectively at scale, instead of one pioneer sprinting ahead while everyone else watches? I have seen that gap become the difference between seven people delivering what used to take thirty, and thirty people wondering why the tools didn’t move the needle.

The second is AI FinOps. How do you measure and optimize cost?

This one we genuinely haven’t cracked. Model and token costs vary wildly, and mapping that spend to value is incredibly hard. You cannot say this many tokens, this many commits, therefore this much value created. It does not work like that. And the reverse is just as unsolved. When a team is burning a lot, where is the line they should not cross? And what happens when they cross it?

I keep circling that question, and I do not have a clean answer yet. So I will give it its own write-up rather than pretend I can settle it in a paragraph here.

And that is really the point. The moment you move past the demo, all the hidden work starts showing up: enablement, cost control, ownership, monitoring, governance, and support.

Readiness is harder to fake than a demo

Making this run against an SLA, and making it fit the wider enterprise, is the thing I keep preaching about. So far, too much of this has been a POC here, a demo there, one use case for one business unit. None of that answers the enterprise-level question: who runs this, and how does it fit?

These were never just model-capability questions. They are the unglamorous organizational ones. Who owns this thing? Who stands behind its output? Who notices when it quietly drifts three months from now, after the model has been upgraded twice?

Readiness is much harder to fake than a demo.
That is exactly why so few pilots clear it.

Or, the way I tend to put it on calls: plenty of demos queue at the edge. Nobody has crossed into production yet, so nobody has felt the pain.

You can see the same thing in the returns. Deloitte’s State of AI in the Enterprise 2026 found that two-thirds of organizations report productivity and efficiency gains from AI, but only one in five report revenue growth from it. The work speeds up. The money stalls somewhere between the agent and the income statement.

The trap is mistaking the harness for the platform

I am not gloomy about this, by the way. Quite the opposite.

Having walked through an Enterprise Agent Platform buildout, I can say the path is real. It is also learnable. Yes, in some ways, it is yet another platform conversation, maybe even yet another AI CoE conversation. But that does not make it optional. It starts with naming the problem properly. Enterprise AI does not have a creativity problem anymore. It has a production problem. Everything that matters from here is about closing that production gap.

And here is the part I keep chewing on. There are two different muscles in play:

• One is the build muscle: The harness you wrap around yourself and your team — the culture and the new ways of working that make a small group genuinely fast. That is real, and it is mostly an individual and team story.

• The other is the agent platform: The shared layer the enterprise actually runs on, the thing that turns one clever capability into something many teams can build on, reuse, govern, and keep operating. That is not an individual story. It is an organizational one.

We keep mistaking one for the other. And the trap is assuming the first gets you the second. It does not.

You can have the sharpest harness and the best build culture in the company and still have nothing the enterprise can run, because the platform underneath was never built, never owned, or funded as enablement in its own right.

The harness makes you fast. The platform makes the enterprise capable.

Two different problems. Most organizations are only resourcing one of them. That second problem is the reusable, consumable agent platform. And that is where I want to go in the next post.

About the author

Jaroslav Pantsjoha is a Technical Director, Agentic AI Platforms, and a Google Developer Expert focused on taking AI systems from demos to production. He designs and delivers enterprise agent platforms, with work spanning architecture, governance, delivery models, and the operating changes needed to make AI systems run at scale. His current work focuses on the practical gap most organizations are now facing: how to turn promising proofs of value into production systems that are owned, governed, and accountable.

You can follow him on Linkedin here

Social engineering is about manipulating people's emotions. Identify the susceptibilities that hackers use to exploit people.

This NINJIO Insights Report dives into the key emotional susceptibilities that make social engineering work and offers concrete steps that your security team can take to equip your workforce to resist cyberattacks.

Download the Guide

Hi, welcome back.

Last time, we talked about least agency: giving agents the smallest useful amount of autonomy, instead of handing them every tool and hoping discipline appears later.

This week, I want to add the next constraint: Cost.

GitHub gave us a useful signal here. Copilot moved to usage-based billing in June, with AI credits tied to token consumption. Soon after, GitHub reportedly had its best month ever, driven by demand for AI-assisted coding. That is not just a GitHub story. It is a preview of where engineering work is going.

Jensen Huang has also been talking about AI token budgets for engineers. Whether or not that becomes common compensation language, the point is hard to ignore: tokens are becoming working capacity.

For years, most developer tools behaved like office software. You bought seats, assigned licenses, and forgot about it until renewal season. Agents do not work that way. They consume tokens, context, model capacity, tool calls, retries, logs, CI minutes, and review time.

So the useful question for platform teams is not “is AI getting expensive?” Of course it is. The useful question is: are we operating agent usage like shared production capacity, or are we treating it like a bunch of harmless subscriptions?

Here are five things I’d fix before agent usage becomes another mystery bill.

1. Break the bill down by workflow

The worst version of AI spend is one large monthly number called “Copilot,” “Claude,” “OpenAI,” or “AI tools.” That number will start a finance conversation, but it will not help an engineering team make a decision.

You need to know which workflows are consuming the money: code review, incident summaries, release notes, test generation, deployment helpers, log analysis, ticket triage, documentation updates, runbook execution. Once you see that split, the conversation changes. A workflow that saves ten engineers an hour every week may be worth the cost. A workflow that writes long summaries nobody reads probably is not.

You already do this elsewhere. Shared infra gets tags. CI jobs get owners. Cloud spend gets split by service, team, or environment. Agents should not be exempt just because the invoice arrives under one vendor name.

Start simple. Track the workflow name, owner, model used, average cost per run, success rate, failed runs, retries, and whether human review was needed. That is enough to stop guessing.

If you cannot connect spend to a workflow, you cannot tell whether the agent is creating value or just making the bill more interesting.

2. Give agents budgets before they become popular

No one runs production services with unlimited CPU, unlimited memory, unlimited retries, and unlimited runtime. Agents should not be the exception. Every serious agent workflow needs a budget. Not just a money budget, but a behavior budget: max tokens per run, max tool calls, max retries, max runtime, max files pulled into context, max logs included, and max model tier allowed by default.

The small leaks are usually the ones that hurt. A code review agent reads too much context. A troubleshooting agent keeps retrying the same weak path. A release agent generates a long report, then generates three polished versions of the same report. A helper tool uses the most expensive model because nobody changed the default. None of this looks dramatic in one run. But at the team scale, it becomes capacity.

This is where platform engineering habits help. You do not need to ban usage. You need sane defaults. Most workflows should start with limits, then earn higher limits when the value is clear.

3. Route work to the model it deserves

A lot of agent cost comes from using the strongest model for the weakest job. A deployment summary does not need the same model as a multi-step incident investigation. A formatting task does not need the same model as risky code generation. A first-pass log explanation does not need the same model as cross-service root-cause analysis.

Create tiers. Use cheaper models for summarization, classification, formatting, and routine explanations. Reserve the expensive models for work where reasoning quality actually changes the outcome: incident analysis, architecture trade-offs, complex code changes, migration planning, and workflows that touch production state. This is not about being cheap. It is about not using a crane to move a laptop.

You already right-size infrastructure. You choose instance types, storage classes, queue sizes, and retention windows based on the workload. Agent workflows need the same treatment.

The question is not “which model is best?” The better question is “which model is enough for this step?”

4. Put retry loops on a leash

Retries are where agent workflows quietly become expensive and annoying. A failed request is one thing. An agent that keeps re-reading logs, re-planning, re-calling tools, expanding context, and trying again can burn tokens without moving the problem forward.

This is also where cost and safety meet. When an agent is stuck, you do not want it to spend more money becoming more confident about the wrong path. You want it to stop, summarize what it tried, and hand the problem back with evidence.

So, define the loop rules before the loop runs. How many retries are allowed? What counts as progress? Which failures stop the run? When does the workflow move from “act” to “suggest”? When does a human need to step in?

If you use Ansible, this instinct is already familiar. A playbook with bad exit behavior is not resilient. It is noisy. An agent loop has the same problem, except the noise now comes with token cost.

A good agent workflow needs a circuit breaker.

5. Add cost review to the rollout checklist

Before an agent workflow moves beyond a small group, ask the boring questions.

What should a successful run cost? What does a failed run cost? What happens if fifty engineers use it every day? What happens during an incident when everyone runs it at once? Who owns the budget? Who gets alerted when usage spikes? What gets turned off first? Put these beside the safety questions. If the agent can change systems, review its permissions. If the agent can consume shared capacity, review its limits. Both belong in the rollout conversation.

This does not have to become a committee. It just needs an owner and a threshold. If usage doubles, someone should know. If a workflow starts burning budget through retries, someone should see it before the month ends. If a premium model is being used for low-value work, someone should be able to move it down a tier.

The worst time to discover the cost model is after everyone likes the workflow.

The bigger point is simple. Last week’s issue asked how much autonomy an agent should get. This week’s question is how much it should be allowed to consume. Those two questions belong together. An agent with no permission boundary can break things. An agent with no consumption boundary can quietly become expensive, slow, and hard to defend. If it is part of the platform, operate it like part of the platform.

Meter it. Cap it. Route it. Attribute it. Review it.

Before approving an agent workflow, ask two questions. Is it safe enough to run? And is it worth repeating at scale? Because once agents move into daily work, the bill is not a surprise. It is telemetry.

One last thing before I go, we do have a couple of events that are upcoming up specifically related Claude DevOps & GitOps Platform engineering which are a definite value add how to utilise your AI credits as well to build systems at scale.

Agentic DevOps with Claude | July 23rd

Early Bird Live Now, 40% Off, last 48 hours before it’s sold out!

Claude Code is the engineer. You’re watching it work.

Four hours. A 33-component AI-native IDP built live on a real Kubernetes cluster, ArgoCD, Backstage, kgateway, observability stack included. The cluster is provisioned for you. You leave with the repo and a working reference architecture to take back to your team.

Michael Rishi Forrester from Accenture, prev- KodeKloud is running this one. Limited Seats

📅 Thursday, July 23rd | 11:00 AM EDT

LOCK IN EARLY BIRD

AI-Powered GitOps and Platform Engineering Workshop | July 30th

Early Bird Live Now, 40% Off, last 4 days before it’s gone!

Your AI agent doesn’t know your manifests are stale. That’s the whole problem.

Three hours. Real ArgoCD and Flux workflows, live demos comparing fresh vs. stale context, and hands-on labs turning repeated agent tasks into tooling your team actually keeps. You’ll walk through drift detection, change review, and validation, the parts of platform engineering AI tools usually get wrong because nobody fed them current context.

Taylor Dolezal from Dosu, an AI-native knowledge infrastructure for agents and humans is running this one, drawing on patterns from 100,000+ repos. Limited seats.

📅 Thursday, July 30th | 11:00 AM EDT

Book Your Tickets

If you’re a regular CloudPro reader, I’d like to hear what you want covered next: agent cost models, MCP security, platform AI governance, agentic DevOps workflows, or the messy parts of actually getting these systems into production.

Hit reply and tell me what would be most useful for your team.

Cheers,

Apramit Bhattacharya

Editor-in-Chief

Starting with the next edition, you’ll receive this newsletter directly from our Substack, so keep an eye out for it there.

Last week, we looked at AI-native platform engineering, and the conversations around it raised a useful argument for anyone working with agents: the future is not “give agents more autonomy.” It is “give them the smallest useful amount of autonomy”, a more uncomfortable idea than it sounds, since most AI demos move the opposite way: more tools, more context, more access, more actions. It’s impressive because the agent can do a lot, but real infrastructure optimizes for known scope, clear ownership, safe failure, and boringly good recovery.

The phrase that stuck with me was least agency, in the same spirit as least privilege. Least privilege asks, “What is the minimum access this thing needs?” Least agency asks, “What is the minimum decision-making power this thing needs?” That is the real split: autonomous by default vs constrained by design.

You can see that problem play out in two places most CloudPro readers know well: network operations and the Linux command line.

Engineering Agentic Network Operations, LAST 10 SEATS!

That’s why, on June 30th, we’re bringing together William Collins and John Capobianco for a live, hands-on workshop to help you move from AI experimentation to production-ready Agentic NetOps.

You’ll learn how to:

• Build MCP skills that are composable, reusable, and production-ready, not just proof-of-concepts

• Apply spec-driven development to define and constrain agent behavior before it creates operational risk

• Design resilient agentic loops with failure recovery patterns and safe handoffs for real-world network environments

Through live instruction, demonstrations, and guided labs, you’ll gain practical experience across a modern AI networking stack including MCP, OpenClaw, NetClaw, Python, Claude, Selector AI, and Containerlab.

🚨 Only 10 seats remain for the live session.

Use code LIMITED40 at checkout to receive 40% off your registration, available exclusively for you.

BOOK YOUR SEAT NOW

📅 Tuesday, June 30 | 9:00 AM–12:00 PM EDT

Agentic Linux – From Commands to AI Agents

This event is on 27 June, and it brings the same question to the shell.

Taught by Imran Afzal, a best-selling Udemy instructor who’s trained 1M+ students and spent 25+ years running infrastructure at Fortune 500 companies before he started teaching it, this session brings the same question to the shell. AI can write commands and explain logs in seconds, but Linux does not forgive blind execution.

You’ll work hands-on with ChatGPT CLI, Shell Genie, Aider, and Goose CLI, with review and human approval kept at the center throughout. If you’re a Linux admin, DevOps engineer, SRE, or technical learner, this is a way to try agentic CLI workflows without treating your terminal like a toy, guided by someone who’s actually run that terminal for a living.

Join it live while there’s still room.

Use code EARLY40 to get 40% off

BOOK YOUR SEAT NOW

Remember, an agent should know when it is missing context, when it is guessing, when the next step changes state, and when to hand control back. Otherwise, you get the ops version of the “Automation is great” meme;

That is where “human in the loop” gets exposed, if the agent moves faster than the review path, the human is not in the loop, just watching the replay.

The platform engineering conversation made one thing clear to me: AI-native operations will not be won by the teams that hand agents the biggest set of keys. It will be won by the teams that design the smallest useful loop, then make that loop observable, reviewable, and safe enough to run again.

I’ll be in attendance at these sessions as well. If this is already showing up in your team’s roadmap, this is the wrong one to bookmark and forget. The useful questions usually come up live, in the labs, when the agent does something slightly awkward, and everyone has to talk through what should happen next.

Cheers,
Apramit Bhattacharya
Editor-in-Chief.

P.S. If you attended the platform engineering session or have an opinion on today’s topic, do reply to this mail. A good question from the chat counts.

In this issue, I want to point you toward three sessions worth your time if you work near platforms, networks, Linux, automation, or incident response. They are connected by one theme: AI in operations is only useful when the boundaries are engineered first.

That has been the thread running through recent CloudPro issues, even when the topics looked unrelated. In the last few issues, we’ve kept coming back to the same engineering instinct: slow down, separate the moving parts, and understand what should happen before you let anything change. Whether we were talking about broken containers, MCP design, or admin rights, the point was never just the tool. It was the discipline around the tool.

AI does not remove that habit. It raises the cost of skipping it. The teams that get value from agents will not be the ones that connect the most tools. They will be the ones that know what the agent can see, what it can change, when it must stop, and how a human verifies the next step.

Taken together, these sessions give you a practical way to think about AI where it actually shows up in your work: inside the platform, inside network operations, and at the Linux command line.

FINAL CALL - Building AI-Native Platform Engineering Systems
Last 24 hours!

Start at the platform layer.

If you run an internal platform, you’ve probably felt the pressure: AI in the developer portal, agents that explain failures, golden paths that do more than point to templates.

The challenge is that platform agents need context, telemetry, policy, safe actions, approvals, and clear trust boundaries. AI can’t just be bolted on.

That’s why Building AI-Native Platform Engineering Systems stands out. It covers Backstage, OpenChoreo, CI/CD, golden paths, control planes, policy-as-code, observability, guardrails, and platform intelligence - with AI treated as part of the architecture, not an afterthought.

A solid read for platform engineers, DevOps engineers, SREs, architects, and engineering leaders asking:

“Can we make our platform AI-native?”

The answer may be yes, but only with the right control surfaces.

Use code FINAL50 to get 50% off

BOOK YOUR SEAT NOW

The session is on June 11, i.e., 24 hours from now, and you can use the discount code FINAL50 when booking.

Engineering Agentic Network Operations

Once platform boundaries are in place, the next challenge is network operations, where many AI demos fall apart.

It’s easy to build an agent that summarizes data or suggests a config. It’s much harder to build one that works within real constraints, recovers from failures, and knows when to hand control back to a human.

That’s the focus of Engineering Agentic Network Operations.

The workshop covers MCP, OpenClaw, NetClaw, FastMCP, Containerlab, Arista cEOS, and more. But the real value is learning how to design agentic workflows with clear scope, guardrails, recovery paths, and human oversight.

For network automation, SRE, platform, and infrastructure teams, those questions matter long before an agent is trusted with production operations.

Use code SPECIAL50 to get 50% off

BOOK YOUR SEAT NOW

Agentic Linux – From Commands to AI Agents

Then there’s the base layer.

No matter how advanced the platform, a lot of real work still ends up in Linux - reading logs, checking services, fixing permissions, troubleshooting errors, and deciding whether a generated command is actually safe to run.

That’s why Agentic Linux – From Commands to AI Agents is a useful third piece.

The workshop covers ChatGPT CLI, Shell Genie, Aider, Goose CLI, Bash scripting, troubleshooting, automation, and system administration tasks. What I like is that it treats AI as an assistant, not a replacement for judgment.

Generating a command is easy. Knowing whether it’s safe, spotting destructive actions before they run, and keeping humans in the approval loop is the hard part.

For Linux administrators, DevOps engineers, SREs, and IT professionals, it’s a practical look at using AI at the command line without turning the shell into a roulette wheel.

Use code EARLY40 to get 40% off

BOOK YOUR SEAT NOW

A few books to keep beside these sessions

One more thing worth mentioning: these sessions pair well with a few books from our list if you want to go deeper after the labs.

For the first workshop, I’d start with Platform Engineering for Architects, which is especially relevant because attendees of Building AI-Native Platform Engineering Systems get the book for free. Mastering Enterprise Platform Engineering is the natural follow-up if you’re thinking about platform engineering, delivery workflows, and generative AI at enterprise scale. For the network operations side, AI Networking Cookbook fits neatly with the agentic network operations session. And if the Linux workshop is closer to your day-to-day work,The Ultimate AI Guide for Linux Engineers is a good companions for thinking about what AI-generated commands are actually touching underneath.

The Ultimate AI Guide for Linux Engineers

BUY NOW ON AMAZON

Mastering Enterprise Platform Engineering

BUY NOW ON AMAZON

AI Networking Cookbook

BUY NOW ON AMAZON

Platform Engineering for Architects

BUY NOW ON AMAZON

The useful question is not whether AI can be added to these workflows. It can, and most teams are already experimenting with it somewhere. The harder question is whether the workflow still makes sense once AI is inside it. Can the team understand what happened? Can they review the output? Can they stop a bad change before it lands? Can they trust the system more after adding AI, not less?

That is the thread running through all three sessions. They are not about chasing the newest tool. They are about taking the work many of us already do across platforms, networks, and Linux environments, and asking what has to change when AI becomes part of that work.

That is what makes these sessions useful. They are not abstract AI talks. They sit close to the places many of us actually work: the platform layer, network operations, and the Linux command line.

I’ll be in attendance as well, because these are exactly the conversations CloudPro needs to keep having: what is useful, what is unsafe, what is ready, and what still needs a human in the loop.

This is time-sensitive. The first session is on June 11, and the other two follow later this month. If one of these areas is on your roadmap, I would not skip it.

Cheers,

Apramit

Editor-in-Chief

Local intune admin rights are one of those problems every Windows shop runs into eventually, and EPM is usually the first answer that comes up. But how you roll it out, and who you actually license for it, makes a real difference to both your security posture and your budget. Today’s CloudPro issue is adapted from Mastering Endpoint Management using Microsoft Intune Suite by Saurabh Sarkar and Rahul Singh, and it lays out a clean way to think through the decision.

Cheers,

Shreyans Singh

Editor-in-Chief

Subscribe now

Share

CloudPro #124: Most “I Need Intune Admin Rights” Requests Aren’t About Admin Rights

Every security team eventually gets there: local admin rights have to go. Fair enough- they’re a known weakness, and leaving users as admins on their own machines isn’t defensible anymore. So you start looking at EPM, and the easiest thing to do is buy licenses for everyone, turn on self-elevation, and call it solved. Pause before you do that. You’ll spend more than you need to and you’ll be using the tool for something it isn’t really designed for.

EPM gets pitched, and often understood, as “the safe way to give users admin rights.” That framing is the source of most of the trouble. EPM isn’t an admin-rights replacement and it isn’t an app delivery mechanism. It’s elevation control. It lets a specific application run with admin privileges in a specific moment, under a rule you’ve defined. That’s a much narrower job than “make this user an admin,” and once you see the difference, the licensing decision gets a lot easier.

Start with app delivery, because most “I need admin” requests aren’t actually about admin. They’re about getting an app installed. If you push your common business apps via Intune as Required, they install in the system context and the user doesn’t need elevation at all. For the long tail of apps where you’re not sure who needs what, make them Available through Company Portal. The user installs them on demand, still in system context, still without elevation. Get this layer right and a huge chunk of the supposed “need for admin rights” disappears.

What’s left after that is the actual EPM territory. Someone needs to install something niche that isn’t in your catalog and never will be. A support engineer needs to run ProcMon elevated to debug a real issue. A developer needs an elevated PowerShell window. A user needs to restart a stuck service. These are the cases EPM was built for: controlled, rule-based elevation for specific apps and specific moments. Worth assigning a license for. Worth setting up properly.

One distinction worth being clean about: EPM is not application control. If your goal is to stop certain apps from running on your devices, EPM doesn’t do that. It decides what gets elevated, not what gets to run in the first place. App Control for Business is the right tool for that, and conflating the two leads to policies that don’t do what you think they do.

Which brings the licensing piece into focus. EPM licensing is per-user, and the population that genuinely runs elevated workloads is almost always a fraction of your fleet: engineers, IT support, certain power users. The rest of your users get their apps through Required and Available and never hit an elevation prompt. Licensing everyone “just in case” is the most common way teams overspend on the Intune Suite, and it usually happens because the team skipped the app-delivery question and went straight to the elevation question.

Get the delivery layer right first. EPM is for what’s left over.

Subscribe now

Share

This matters because once agents start relying on your MCP server, the contract gets sticky. You can change the implementation, but renaming tools or restructuring scopes breaks every instruction file and agentic workflow already pointing at them. The first version tends to become the permanent version.

Subscribe now

Rule one: don’t mix read and write.

It’s tempting to expose everything from a single server: get_logs and list_problems alongside the handy create_workflow and send_notification stuff. Don’t. Put read-only data access in one server and anything that modifies state or triggers actions in a second, separately installed one.

Two reasons. The obvious one is accidental writes. The less obvious but bigger one is prompt injection. If an agent is connected to both, a poisoned log line or a malicious doc in your RAG pipeline can talk the agent into calling an admin action it had no business calling. Splitting servers shrinks that attack surface. And yes, the MCP spec lets users disable individual tools, but realistically most people leave everything on.

Rule two: don’t ship only a generic execute_query tool

Every observability backend has a query language: NRQL, DQL, PromQL, whatever yours is. You could expose just execute_query and let the agent figure out the syntax. It’ll work, but badly. The agent guesses, gets a syntax error, retries, refines, retries again. Every round-trip costs API calls, tokens, and latency.

Build purpose-specific tools for your top use cases alongside the generic one. A get_logs tool taking a timespan and workload identifier will run a clean, optimized query on the first try. No guessing.

Don’t overcorrect though. get_logs_from_k8s, get_logs_from_hosts, get_logs_from_apps: now you’re maintaining ten tools and the agent picks the wrong one half the time anyway. Aim for the middle.

Rule three: validate locally before hitting the backend

When the agent sends a query, check it inside the MCP server first. Is the syntax valid? Does the caller actually have permission to access that data? These are cheap checks and they kill the trial-and-error loop at the source. Without them, every bad query becomes a billable backend call.

Instrument your MCP server and you’ll see the pattern fast: most failures are the same two or three mistakes. Catch them locally.

These aren’t the only mistakes you can make, but they’re the ones that compound quietly until you’re rebuilding the server at version two. Worth getting right the first time.

Subscribe now

This article was adapted from Observability in the AI-Native Era.

Cheers,

Shreyans Singh

Editor-in-Chief

Share

But they’ve been officially deprecated since OpenShift 4.14, and it’s worth understanding why. Not just because Red Hat says so, but because the underlying technology has genuinely moved on.

Some context. When OpenShift 3 shipped back in 2015, Kubernetes didn’t have great deployment management. DeploymentConfig filled that gap: lifecycle hooks, image change triggers, custom rollout strategies. It was ahead of its time, honestly.

But Kubernetes caught up. Deployments now do automated rollbacks, HPA-based autoscaling, pause and resume during rollouts. And they’re built on ReplicaSets, not ReplicationControllers. That bit matters because ReplicationController development has stopped upstream entirely. The foundation DeploymentConfig sits on isn’t getting any love anymore.

There’s a design difference worth knowing about too. DeploymentConfig leans toward consistency: if the node running your deployer pod dies, it just waits. Waits for the node to recover, or for someone to manually step in. Deployments lean toward availability: the controller manager runs across multiple masters, so another one picks up the work. In production, you usually want that.

The other thing is portability. DeploymentConfigs only exist in OpenShift. Deployments are standard Kubernetes. If you ever need to move workloads between clusters or providers, that distinction starts to matter a lot.

And by sticking with DeploymentConfig, you’re also cutting yourself off from tooling. No Argo Rollouts for canary or blue-green. No native HPA. No automated rollback. Manual scaling, manual rollback. It’s fine until you’re doing it at 2am during an incident and wishing you weren’t.

Nobody’s flipping a switch on you tomorrow. DeploymentConfigs still run. But “it still works” isn’t really a strategy. If you haven’t started thinking about this, now’s a good time.

This article was adapted from Learn OpenShift.

I’ve seen engineers waste hours on this because they defaulted to one or the other without thinking it through. So here’s how I think about it.

It comes down to one question: is the problem in how the container is running, or in what was built?

Subscribe now

If it’s a runtime issue: the app got stuck, a config change hasn’t taken effect, something just needs a kick, restart. That’s the fastest path back to normal and there’s nothing wrong with it.

If the image itself might be the problem, restart won’t help. You’ll just redeploy the same broken thing. You need to rebuild.

Sounds simple, but the tricky part is knowing which situation you’re in. Here’s how I usually work through it.

Config, env vars, or secrets changed? Restart the service. New values get picked up at runtime. No need for a new image.

Base image tag or digest changed? Rebuild. Even if your code is the same, the stuff underneath it isn’t. Your dependencies have moved.

You built with latest or your Dockerfile pulls in dynamic dependencies? Rebuild. You don’t really know what’s inside that image anymore. Something upstream could have shifted without anyone noticing.

Application code changed? Obviously rebuild. New code needs a new artifact.

Container is misbehaving but the image checks out- tag is right, digest matches, nothing has moved upstream? Restart. The image is fine, the container just needs a fresh start.

Not sure what version is even running? Don’t do anything yet. Inspect first. Check your image labels, check the digest. Then decide. Guessing under pressure is how you make things worse.

One small thing that helps a lot: bake a build timestamp into every image. A label, an env var, whatever. It takes seconds to add during the build and it means you can always verify what’s actually running where. Saves a ton of time when you’re half-awake and troubleshooting.

Here’s the whole thing as a quick reference:

Subscribe now

This article is adapted from Mastering Docker on Windows by Michael D. Smith.

In the article below, Stéphane tackles one of the most challenging aspects of Azure architecture: building truly resilient multi-region systems, with concrete examples using Azure SQL, Cosmos DB, and Azure Storage, complete with code samples and Terraform scripts you can adapt for your own DR testing.

Happy reading!

- Shreyans Singh

Editor-in-Chief

Subscribe now

I like to say that Azure is simple… until you go multi-region. The transition from a well-designed single-region architecture to a truly resilient multi-region setup is where simplicity gives way to nuance. Concepts that seemed abstract (high availability versus disaster recovery, failover semantics, DNS behavior, data replication guarantees) suddenly become very real, very concrete, and sometimes painfully operational.

This article is written for architects and senior platform engineers, who already understand the fundamentals but are required to build solutions that must remain available despite regional outages, service failures, or infrastructure-level incidents. The scope is intentionally narrowed to Recovery Time Objective (RTO). Data corruption, ransomware, and backup-based recovery are explicitly out of scope. Instead, the focus is on how applications and data services behave during live failover scenarios, and how architectural decisions, sometimes subtle ones, can make the difference between a seamless transition and a prolonged outage.

Through concrete examples using Azure SQL, Cosmos DB, and Azure Storage, this article explores how replication models, DNS design, private endpoints, and SDK behavior interact at runtime, and what architects must do to ensure their applications remain functional when regions fail.

Rather than focusing on theoretical patterns, the goal here is pragmatic—minimizing downtime and operational friction when things do go wrong. You’ll see diagrams, Terraform and deployment scripts, plus .NET code samples you can adapt for your own DR tests and game days.

Before getting into the details, let’s briefly revisit the difference between high availability (HA) and disaster recovery (DR).

Subscribe now

HA and DR exist on a spectrum, with increasing levels of resilience depending on the type of failure you want to withstand:

• Application-level failures: In some cases, you may simply want to tolerate application bugs—for example, a memory leak introduced by developers. Running multiple instances of the application on separate virtual machines, even on the same physical host, can already prevent a full outage when one instance exhausts its allocated memory. That is for instance, what you would get if you spin up 2 instances of an Azure App Service within the same zone (no zone redundancy).

• Hardware failures: To handle hardware failures, workloads should be distributed across multiple racks. That is what you would get if you’d host virtual machines on availability sets.

• Data centre–level outages: To withstand more severe incidents, workloads should be spread across multiple data centers, such as by deploying them across multiple availability zones. You can achieve this by turning on zone-redundancy on Azure App Service or use zone-redundant node pools in AKS. With such a setup, you should survive a local disaster such as fire, flooding, etc.

• Regional outages: Finally, to survive major outages, such as a major earthquake, a country-level power supply issue, etc., workloads must be deployed across geographically distant data centers. You can achieve this by deploying workloads across multiple Azure regions in active/active or active/passive mode.

Looking at Azure SQL

Let’s first analyse the different data replication possibilities with Azure SQL. Table 1 summarizes the different capabilities.

Table 1 – Replication capabilities

We’ll set aside named replicas and geo-restore, as the former does not contribute to disaster recovery and the latter is likely to introduce significant downtime and potential data loss. This leaves geo-replication as the remaining option. As you might have understood by now, using Azure SQL’s built-in capabilities, you cannot achieve a full ACTIVE/ACTIVE setup since it doesn’t support multi-region writes. This means that you can only have one read-write region and the secondary region(s) are read only.

Table 2 outlines the two available geo-replication techniques.

Table 2 – Geo replication options

Active geo-replication may require updates to connection strings or DNS records to point to the new primary after a failover. That said, the actual impact depends on where (*) the client application is located as well as how you deploy to both regions. Let’s look at this in more detail. Figure 1 illustrates an active geo-replication setup between Belgium Central and France Central.

Figure 1 – SQL geo replication with active geo replication

In such a setup, under normal circumstances:

• Workloads in the primary region (Belgium Central) can connect to the primary server in read/write mode

• Workloads in the primary region can perform read-only activities against the secondary replica, providing they tolerate the extra latency incurred by the roundtrip to the remote region (France Central).

• Workloads in the secondary region (if any), can perform read-only operations against the read replica with no extra latency.

Subscribe now

The configuration shown in Figure 1 supports a database-only failover. Both regions expose private endpoints to both SQL servers and rely on region-scoped DNS zones.

Although Private DNS zones are global by design, keeping them regional allows each region to resolve both the primary and secondary servers. This requires four DNS records in total—primary and secondary endpoints registered in each regional zone.

With a single shared DNS zone, this would not be possible: while all four private endpoints could be deployed, only two DNS records would be registered, since the endpoints map to just two FQDNs (primary and secondary). While this approach works, it keeps the regions siloed and prevents any cross-region traffic. From a resilience standpoint, it is preferable to provide as many fallback paths as possible.

Moreover, as we will see later, with other resources such as Storage Accounts, a single DNS zone would force us to update the DNS records upon failover, causing a minimal downtime. Bottom line: using multiple DNS zones prevents issues during failover.

Back to active geo replication! In case of failover, SQL servers switch roles: the primary becomes secondary and vice versa. This concretely means that the connection string primary.database.windows.net targets the read/write region in a normal situation but a read-only or unavailable one after failover. Workloads using this connection string would either stop working (if the regional outage persist), either talk to a read-only database instead of a read-write one, once the failover completed. Similarly, the connection string secondary.database.windows.net usually targeting the read-only region under normal circumstances now targets the read-write one after failover.

Knowing this, a few options exist:

• You may choose to fail over everything (database+compute). In that scenario, workloads running in the secondary region can use their default secondary connection string, which will automatically target the new primary after failover. This approach requires the deployment pipeline to be region-aware, detect the target region, and apply the appropriate connection string. When deployed in the primary region, the application should use primary.database.windows.net, while in the secondary region it should already be configured with secondary.database.windows.net. This design eliminates the need for any connection string changes after failover. If your webapps, K8s pods, etc. are already up and running, the only thing you still have to do is route traffic to them. Any other SQL client not running in the secondary region (eg: on-premises), would have to update its connection string to target the new primary.

• You may choose to redeploy the compute infrastructure (web apps, etc.) to the secondary region only in case of regional outage. This approach is cheaper but risky as you’re not guaranteed to have the available capacity and it is causing a significant downtime. However, such an approach allows you to adjust your pipelines, specify the right connection string and simply redeploy your infrastructure and/or application package.
  

• If you want to deploy the application with the exact same settings in both regions, you’ll need to update the connection string used by workloads in the secondary region, since primary.database.windows.net will now resolve to an unavailable server after failover. If the original primary later comes back online, it will return as a secondary (read-only) replica, which would not support write operations. You can as well make your application failover aware (**).
  

You can’t simply update DNS, meaning making secondary target primary and vice versa, because the FQDN (primary-or-secondary.database.windows.net) is validated by the target server, and the names must match—so redirecting it to a different server would simply fail.

In conclusion, when using active geo-replication as the replication technique, you should make your applications failover-aware (**) and pre-provision both connection strings and implement the failover/retry logic in the application code itself. You may wrap your Entity Framework context into a factory to abstract away the retry logic. Given we typically use a scoped lifetime, you may expect some HTTP requests to fail (in case of an API) but new instances targeting the right server would ultimately succeed without having to restart the application. You may as well use a geo-redundant Azure App Configuration and failover it along SQL, then switch the primary server connection string after failover. The SDK allows you to monitor a sentinel key and to reload the configuration without having to restart the application:

configBuilder.AddAzureAppConfiguration(options =>

{

options.Connect(new Uri(”<your-app-config-endpoint>”), new DefaultAzureCredential())

// Load all keys that start with `TestApp:` and have no label

.Select(keyFilter: “TestApp:*”, labelFilter: LabelFilter.Null)

.ConfigureRefresh(refreshOptions =>

{

// Trigger full configuration refresh only if the `SentinelKey` changes.

refreshOptions.Register(”SentinelKey”, refreshAll: true);

});

});

More on App Configuration and the sentinel key https://learn.microsoft.com/en-us/azure/azure-app-configuration/howto-best-practices?tabs=dotnet

Upon failover, you would update the sentinel key, modify connection strings in App Configuration or tell the apps that they failed over, letting them pick the new configuration without the need to restart them.

As an alternative to active geo-replication, you can use failover groups, which allow one or more databases to fail over together to another server. A key benefit of failover group compared to active geo-replication, is the presence of two stable listeners: one for read-only traffic and one for read/write operations. These listeners remain constant and always point to the current primary and secondary servers. During a failover, applications continue connecting through the listeners rather than connecting directly to a specific SQL server, eliminating the need for connection string changes.

Figure 2 illustrates the situation when the primary region is working fine.

Figure 2 – Failover group before failover

We see that clients connect to listener endpoints. The failover group comes with two endpoints:

• <failovergroupname>.database.windows.net

• <failovergroupname>.secondary.database.windows.net

These public DNS records are managed by Microsoft and they work with aliases pointing to the replicated servers. The read-write endpoint will always target the server that has the primary role. In Figure 2, it currently points to primary.database.windows.net, our server in Belgium Central.

Figure 3 shows the situation after failover

Figure 3 – Failover group after failover

We see that this time, the read/write endpoint points to secondary.database.windows.net, our server in France Central, which has become the new primary. Failover groups greatly simplify client connectivity: when private endpoints and DNS zones are properly configured, the failover is completely transparent to connected clients.

To help you test this, I have created a GitHub repo https://github.com/stephaneey/azure-and-k8s-architecture/tree/main/availability-samples/sql where you can find both a sample console application and some Terraform code. The solution is a simplified setup but let’s you grasp how failover groups work. You can find the explanations on how to deploy and test this in the repo itself.

Next, let’s look at how to maximize availability using Cosmos DB.

Looking at Cosmos DB

As of January 2026, Cosmos DB is the only Azure service that supports true active/active read-write deployments through its multi-region writes capability. For scenarios that do not rely on relational models or strict referential integrity—and where eventual consistency (most commonly session consistency) is acceptable—Cosmos DB is the preferred choice.

Figure 4 represents an API platform spanning two continents (Europe and US) and leveraging the multi-region writes feature.

Figure 4 – Leveraging Cosmos DB multi-region writes for a global API platform

Note 1: the raw diagram, extracted from my book, is available here https://github.com/PacktPublishing/The-Azure-Cloud-Native-Architecture-Mapbook-Second-Edition/blob/main/Chapter03/diagrams/diagrams.vsdx

Note 2: I delivered a 25-minute live demo of the above setup during a Microsoft API Management event (

starting at minute 53 of the recording). Microsoft slightly fast-forwarded the video, so the pace is a bit quicker, but it remains possible to follow if you stay focused 😊.

In a nutshell, US callers are sent to the US backend and EU callers to the EU backend. What is interesting in this architecture is that every layer is failure-resistant.

The entry point, Front Door uses geo-proximity by default but is able to send US callers to EU and vice versa in case the regional backend is unhealthy. API Management’s regional gateways forward to their regional backends.

Each of the backends hosted on app services is leveraging the Cosmos DB SDK, which is smart enough to detect whether the corresponding Cosmos DB region is available or not. The API will seamlessly switch to the available region in case of a regional failure impacting only Cosmos DB. That’s what I’m going to focus on in this article.

Figure 5 focuses on the backend part.

Figure 5 – focusing on backend

My US and EU app services talk respectively to their regional Cosmos DB endpoint under normal circumstances. Note that each region has three private endpoints (one for each region plus the non-regional endpoint), which makes it possible from EU to go to the US and vice versa through the private endpoint plumbing. If, for some reason, the EU backend cannot talk to the EU Cosmos endpoint, it will take the US path. Of course, there is an impact on latency but the solution keeps working and the application doesn’t even need to be restarted. In case of a full regional outage (say entire EU is down), Front Door would direct all API calls to the US backend.

This architecture can resist to both local outages and full regional ones.

To help you test this built-in resilience using Cosmos, I have developed a sample API along with the Terraform bits that deploy a simplified setup shown in Figure 6. The repo is available here

https://github.com/stephaneey/azure-and-k8s-architecture/tree/main/availability-samples/cosmos

Figure 6 – Simplified setup for testing

Here, I’m not using private endpoints but this is enough to understand the SDK mechanisms. After you have deployed the solution, you should end up with the following resources:

Figure 7 – Resources deployed by the sample application

I made sure the webapp’s managed identities are granted access to Cosmos and I pre-deployed a database and a container.

Additionally, each web app indicates its preferred region using environment variables to the Cosmos SDK:

Figure 8 – Cosmos DB settings defined as environment variables

You can directly test the APIs using Postman or Fiddler, by first performing a POST request (Figure 9), to create a document, followed by a GET request (Figure 10):

Figure 9 – Sample POST request to create a document

Figure 10 – Sample GET request to get the latest weather forecast

I developed the API in such a way that it indicates which Cosmos region was used by the backend service to perform the operation.

Now, you can start playing with Cosmos to see how both APIs react. Here are the following things you can test using the Azure Portal or Azure CLI as you wish:

• Marking one of the Cosmos regions read only. In such a case, both APIs (Belgium and France) should automatically go to the remaining writable region, but reads (GET queries) would still pick their regional instance.

• Deleting one of the Cosmos regions. In such a case, both APIs should automatically go to the remaining region for both reads and writes

• Take a Cosmos region offline. In such a case, an automatic failover should take place to the remaining region. Note that you must create a support ticket to get it back online. Just try this one after having tried the other changes.

Make sure to run both POST and GET request between each steps and check which Cosmos backend instance is used by the API. You’ll notice that whatever you do at Cosmos level, the backend is smart enough to keep working.

All the required instructions are provided in the repo.

Last but not least, let’s turn to Azure Storage.

Looking at Azure Storage

Let’s look at Azure Storage, and more specifically at Blob Storage, Table Storage, and Queue Storage, which are widely used across all types of applications. A very common scenario involves Azure Durable Functions as well as stateful Logic Apps, whose default state store is Azure Storage. Because the orchestration state is persisted in Azure Storage, it is essential to understand what happens to this state in the event of a failover.

For sake of brevity, I will only show how to handle both the blob and table sub resources but the principles are exactly the same with the queue service.

Here are the replication capabilities of Azure Storage.

All the above options are only available in paired regions. Additionally, blobs can also be replicated using the object replication feature, but this is by no means comparable to the above options.

Azure Storage replication is rather easy when dealing with internet facing Storage Accounts and public DNS but it gets a bit more complex when using private link.

A common misunderstanding is the impact of using a single DNS zone for private link, which would automatically incur additional downtime in case of regional outage and storage failover.

Figure 11 illustrates the problem:

Figure 11 – Shared DNS zones

Our shared DNS zones are attached to both virtual networks. From the primary region, I can have two private endpoints, one targeting the primary in West Europe and the other one targeting the secondary in North Europe. Both private endpoints are located in West Europe.

Because the FQDN of the Storage Account is mystorage.<service>.core.windows.net, I can only have one record at a time in the DNS zone. I could pre-create the private endpoints in the secondary region but not register them in the zone. In case of Storage Account failover, I would need to update the DNS records and put the IPs of the private endpoints in North Europe. Even doing this wouldn’t work:

Figure 12 – Suboptimal setup using shared DNS zone

With a setup as shown in Figure 12, if I have one blob “test.txt” in the “test” container, the resulting URIs will be:

• https://mystorage.blob.core.windows.net/test/test.txt (primary)

• https://mystorage-secondary.blob.core.windows.net/test/test.txt (secondary)

The primary URL will be reachable from the VM located in the West Europe VNET but not from the one located in North Europe since mystorage.blob.core.windows.net resolves to 10.0.0.4, meaning the private endpoint of West Europe, which is out of reach from North Europe (in this setup). Of course, you could peer those VNETs or route traffic through hubs but this is typically not what you’d want.

Moreover, after failover, you’d be in a situation as shown in Figure 13.

Figure 13 – Storage account after failover

The primary (West Europe) is gone. Perhaps the entire region is gone, meaning that 10.0.0.4 is lost, so even though you would have routed traffic initially from North Europe to West Europe, it’d stop working.

You’d be left with 10.100.0.4 still targeting the secondary but after failover, there is no more secondary...The failover process converts the Storage Account into a Locally Redundant Storage (LRS), so the notions of primary and secondary do not exist anymore. The North Europe has just become the new primary, making 10.100.0.4 now pointing to an unreachable target.

The only way to restore access to https://mystorage.blob.core.windows.net/test/test.txt from North Europe is to create a new private endpoint and update the DNS zone accordingly. You could pre-create the private endpoint prior to a failover but in any case, updating the DNS zone would be required. This would cause an additional short downtime and requires a scripted plan.

So, with Storage Accounts, you must use separate DNS zones if you don’t want to perform any intervention.

That is why, the best setup is the one shown in Figure 14:

Figure 14 – Best setup with Azure Storage using separate DNS zones

Each region has its own private DNS zone and each holds a set of private endpoints targeting both primary and secondary. Now, both mystorage and mystorage-secondary are resolved and routable from both sides. From North Europe, a call to mystorage would go through 10.100.0.4 and hit the West Europe location.

After full regional outage, West Europe is lost but 10.100.0.4 is still targeting the primary, which means, the promoted North Europe location, while the secondary endpoint is lost again (this is unavoidable). This setup doesn’t require any intervention other than performing the failover itself. Needless to mention that your application will encounter exceptions while Azure Storage is failing over, so you need to make sure to correctly handle exceptions.

Coming back to a more concrete example with Durable Functions, you could have an active/passive setup like this one:

Figure 15 – Adding the orchestrator to the mix

Where your orchestrator, hosted on an App Service levering VNET integration is getting access to the Storage Account through 10.0.0.4 to persist state. The North Europe version of the orchestrator could already be deployed but stopped to avoid possible interferences.

In case of regional outage or DR test, you failover the Storage Account and once the failover completed, you start the orchestrator in North Europe that now points to the new primary. Durable functions make mostly use of Queues and Tables to work and persist state. Once the failover completed, you should be able to resume ongoing orchestrations. However, since the data replication process is asynchronous, you may lose some of them.

To help you test this scenario, I have crafted a very little Durable Function available here https://github.com/stephaneey/azure-and-k8s-architecture/tree/main/availability-samples/storage that is just waiting for an external event:

public static async Task RunOrchestrator(

[OrchestrationTrigger] TaskOrchestrationContext context)

{

ILogger logger = context.CreateReplaySafeLogger(nameof(Function1));

logger.LogInformation(”Waiting for external event”);

var eventData=await context.WaitForExternalEvent<DateTime>(”event”);

logger.LogInformation(”external event received {0}”, eventData.ToString());

}

The orchestration is started by this HTTP triggered function:

public static async Task<HttpResponseData> HttpStart(

[HttpTrigger(AuthorizationLevel.Anonymous, “get”, “post”)] HttpRequestData req,

[DurableClient] DurableTaskClient client,

FunctionContext executionContext)

{

ILogger logger = executionContext.GetLogger(”Function1_HttpStart”);

// Function input comes from the request content.

string instanceId = await client.ScheduleNewOrchestrationInstanceAsync(

nameof(Function1));

logger.LogInformation(”Started orchestration with ID = ‘{instanceId}’.”, instanceId);

return await client.CreateCheckStatusResponseAsync(req, instanceId);

}

The idea is to start a new orchestration by calling the HTTP triggered function:

Figure 16 – Starting a new orchestration

And get the instance ID of the orchestration for later use.

After this, you can initiate the failover. Once completed, you should raise the external event and see if the orchestrator is able to resume this orchestration:

Figure 17 – Raising the external event

If everything works fine. The orchestration status should show as completed:

Figure 18 – Checking the orchestration status

You can test this easily locally by making sure to:

• Use a GRS/GZRS/RA-GRS/RA-GZRS Storage Account

• Bind your local solution to the Storage Account by assigning the connection string of your Storage Account to the AzureWebJobsStorage setting in local.settings.json

Of course, in this case, we use public DNS and an Internet facing Function App, which is way simpler than the enterprise-grade design I depicted earlier. This is however enough to experiment with a concrete use case.

Let’s wrap it up!

Designing for resilience in Azure is less about individual services and more about underlying foundations such as networking and DNS. Working with single or multiple DNS zones already has an impact on downtime.

As we have seen, Azure services offer powerful built-in capabilities, but they differ from one service to another and we’ve only seen three of them. Many other services have yet, a different behaviour.

A recurring theme across all scenarios is that infrastructure-level redundancy is not enough. Applications must be designed to tolerate transient failures, retry intelligently, and adapt to changing backend roles, especially in ACTIVE/ACTIVE configurations.

Ultimately, resilience is not achieved by flipping a single switch. It is the result of deliberate architectural choices, tested failure paths, and an honest acceptance of trade-offs—latency versus availability, consistency versus survivability, cost versus operational simplicity.

If there is one takeaway, it is this: multi-region architectures must be designed for failover from day one. When they are, regional outages become operational events rather than existential crises—and “always-on” stops being an aspiration and starts becoming an outcome.

And in today’s article, he explores a radical idea: AI that runs entirely offline. No APIs, no data leaving your network. Just private, local intelligence built for sensitive environments. Sounds interesting? Read on for the full article.

If you want to learn directly from him, Saurabh is hosting a live AWS Solutions Architect Associate (SAA-C03) Workshop on January 17. Its a hands-on, fast-paced session that strips the exam down to what really matters. CloudPro readers get an exclusive 40% early-bird discount with the code CLOUDPRO. Reserve your seat.

Cheers,

Shreyans Singh

Editor-in-Chief

Early Bird Offer: Get 40% Off

Use code CLOUDPRO

AI That Runs Entirely Offline: How to Build an Offline Enterprise Assistant

By Saurabh Shrivastava

Working in defense, finance, law, or a heavily regulated industry means you can’t just plug into ChatGPT and call it a day. Cloud-based AI tools aren’t built for environments where data leakage isn’t just bad.

It’s catastrophic.

You can’t send classified intel or proprietary financial models to someone else’s servers. And if you’re operating in an air-gapped network? Forget about it.

That’s the problem this Offline Enterprise Assistant solves.

It’s a local AI setup that runs entirely on your own hardware. No cloud dependencies. No API keys. No data leaving your perimeter. You choose a model: LlamaCpp, Ollama, whatever fits your needs, and run it directly on your machine. Every prompt, every response, every log file stays inside your infrastructure.

This matters when you’re reviewing sensitive legal contracts, running R&D analyses, or automating workflows that involve confidential information. You get the productivity boost of modern AI without opening the door to external risk. It’s built for teams that need full control over their tools and can’t afford to trust a third party with their data.

Why This Architecture Stands Out

1. Runs Without Internet: Operates 100% offline, making it ideal for air-gapped networks or classified infrastructure.

2. Keeps Data on Your Device: Nothing is sent out, nothing is tracked. You stay in control always.

3. Fast and Responsive: Local inference means no lag, no rate limits, just amazing performance.

4. Built for Sensitive Workflows: Legal reviews, research, compliance, internal tooling are all handled securely.

Most teams are realizing that AI doesn’t always belong in the cloud. When you’re dealing with internal systems, sensitive data, or strict compliance rules, you need something that stays inside your walls. That’s where a local-first approach makes sense: it gives you the benefits of AI without the exposure.

This Offline Enterprise Assistant is built around that idea. It’s your own assistant, running entirely on your hardware, tuned to your environment, and never sending a single request outside your network. You control how it works, how it’s updated, and what data it touches.

Let’s break down how the architecture fits together.

Architecture Explanation

The offline MCP Client architecture is designed to deliver end‑to‑end private and local AI capability, without any reliance on cloud APIs or outbound network traffic. Here’s how it works:

1. Developer: Prepares prompts or workflows using a local development environment (such as a secure IDE or terminal). All interactions originate and remain on the local device.

2. MCP Client: Acts as the interface between the developer’s inputs and the AI model. It routes prompts to the embedded LLM, orchestrates the workflow, and handles results.

3. Offline LLMs (LlamaCpp / Ollama): Powerful large language models are loaded and executed directly on the local hardware. No external API calls; all model inference and response generation happen on the device, fully offline.

4. Local SQLite Database: Stores chat logs, prompts, and results securely and privately. Provides an audit trail and the ability to revisit past interactions, entirely within the local infrastructure.

5. Secure UI/API: Presents results to the developer via a local web interface or terminal UI. Enables further integration with internal systems while ensuring data never leaves the trusted environment.

Think about it. You don’t want your data, your prompts, or your workflows slipping out into the cloud. With this architecture, nothing leaves your machine.

Zero external exposure. No tokens. No API keys. No hidden traffic.

If you’re in a regulated industry, whether it’s defense, legal, healthcare, or any air-gapped environment, this setup checks every box. It keeps you compliant, private, and secure while still giving you the power of modern AI. And here’s the best part: it’s extensible by design.

Want to add another LLM? Done.

Need to customize workflows? Easy.

Ready to experiment with agentic AI? Go ahead. You can build without ever breaking the privacy barrier.

Most importantly, this isn’t a short-term solution. It’s future-proof. As on-device AI models become larger and smarter, this architecture will scale with you, handling more automation, more intelligence, and more complexity.

Now it’s time to get our hands dirty and implement it.

Implementation

Using LM Studio, Streamlit, and Python, you’ll set up and run local open-source models directly on your machine. Unlike online AI assistants like ChatGPT or Google Bard, which constantly need internet connectivity and send data back to external servers, this approach runs completely offline.

Along the way, you’ll gain hands-on experience with the full cycle: you’ll understand how local LLMs really work, set up all the required software and dependencies, download and run an open-source model in LM Studio, and then build a simple yet powerful chat interface using Streamlit. From there, you’ll integrate your local LLM into the Streamlit app and learn how to store and review chat history using a local database securely. By the end, you’ll have a

Before you dive into building your offline Enterprise Assistant, it’s important to get familiar with a few key concepts.

At the heart of this setup is the Offline Assistant itself: an AI system that runs entirely on your computer, performing all language model inference locally without ever needing an internet connection.

Powering this is an LLM (Large Language Model), a type of AI trained on massive datasets to generate human-like text responses.

To make it simple to use, you’ll rely on LM Studio, a desktop app that lets you download, run, and serve open-source LLMs on your machine, exposing them through a local API.

For the interface, you’ll use Streamlit, a Python framework that makes it easy to build interactive web apps and quickly prototype AI-driven tools.

And finally, for securely managing chat history, you’ll work with SQLite, a lightweight local database that keeps all your interactions private and fully stored on your device.

By the end of this hands-on exercise, you’ll have your own local Enterprise Assistant running directly in your browser—powered by an open-source LLM that operates fully offline through LM Studio. You’ll interact with it using a simple but effective interface built with Streamlit, making your assistant practical and easy to use.

Most importantly, every conversation will be securely stored as local chat logs in your system, never sent to the cloud, never exposed. By the time you’re done, you’ll walk away with a private, offline AI assistant that runs fast and stays entirely under your control.

Demo Video and Repo

Demo Video

Lab guide

Conclusion

Congratulations! You’ve just built your very own offline Enterprise Assistant, powered entirely by open-source tools and running fully on your machine. Along the way, you learned how to set up LM Studio to run an LLM locally, how to create a lightweight but effective interface with Streamlit, and how to store all your conversations securely using SQLite. Most importantly, you now understand how to put privacy first, keeping every prompt, response, and workflow under your complete control, with no reliance on external servers or cloud APIs.

This hands-on exercise gave you more than just a working prototype. You gained insight into how local LLMs work, how to integrate them into real-world applications, and how to design AI tools that balance functionality with security. You’ve also seen the bigger picture: how on-device AI can reshape the way enterprises approach sensitive tasks, from R&D to legal reviews to compliance-heavy workflows.

But this is only the beginning. You can now extend your Enterprise Assistant with advanced features:

1. Add a smarter UI with more interactive elements.

2. Try out different open-source models to experiment with speed, accuracy, and capabilities.

3. Layer in analytics and insights to track and optimize your usage.

4. Even push towards agentic AI, giving your assistant the ability to automate tasks and workflows while still running securely offline.

With what you’ve built, you’ve proven that you can harness the power of Generative AI without compromise: no data leaks, no internet dependency, no loss of control.

Your private AI journey starts here.

- Saurabh

This is where most cloud teams still operate. And it’s exhausting.

I realized this after our AI-Powered Platform Engineering workshop last week.

If you were there, you know it was packed. We had George Hantzaras (Director of Engineering, MongoDB) and Ajay Chankramath (Founder, Platformetrics) up there walking through how AI, golden paths, and internal developer platforms are completely reshaping the way modern teams ship software. The energy in the session was incredible. And the conversations didn’t stop when the session ended.

But here’s the thing that stuck with me the most:

MCP (Model Context Protocol) turns your platform into something an AI can actually do things with, not just talk about.

This is the difference between TicketOps and brittle runbooks versus workflows like provisioning, rolling back, and scaling that become assistant-triggered actions with guardrails and full visibility into what’s happening. Your AI goes from being a really smart search engine to being an actual teammate.

That’s the jump I think a lot of us have been waiting for.

So in this issue, I’m going to dig into what that actually looks like, and give you a practical starter pack you can adapt to your own stack. Because if you’ve been wondering how to move from AI as “a chat window” to AI as “a teammate who actually does the work,” this is a good place to start.

Cheers,

Shreyans Singh

Editor-in-Chief

The Problem We’re All Facing

Let me paint a picture of how most cloud teams still operate today. You write a ticket. You wait for approvals. You hunt through runbooks to find the right commands to copy-paste. You watch CI/CD spin up. You cross your fingers that the safety nets catch anything that could go wrong.

Documentation and internal portals help you find things, sure. But they rarely do things. That gap, between knowing what to do and actually doing it, creates this constant context switching, slow feedback loops, and inconsistent safety guardrails.

The result is messy. Really messy. Brittle handoffs. Workflows duplicated across teams. And what should be “golden paths” that empower teams end up becoming “golden cages” that block velocity instead of enabling it.

Here’s what I think is the real core issue: we’ve separated knowledge from action. Your runbooks live in wikis. Your SLOs live in monitoring dashboards. Your approval workflows live in ticketing systems. And your developers, the people who actually need to ship things, they’re stuck stitching all of this together manually, one step at a time.

This friction doesn’t just slow shipping down. It creates inconsistency. One team deploys with proper approvals; another skips them. One team checks SLO impact before scaling; another scales blind. You end up with fragmented practices across your org, and nobody likes that.

We need a different model. Instead of “read the docs, then run the steps,” we should be asking our systems: “propose a plan, then execute it with guardrails.”

Here’s What Changed:

The solution rests on two foundational ideas working together, and honestly, the way they complement each other is elegant.

First: golden paths. These reduce decision fatigue without sacrificing flexibility. Think of a golden path as an end-to-end workflow with sensible defaults, something like: stateless service → preview environment → automated checks → production. These paths capture your team’s collective knowledge about how to do things safely. But they’re not straightjackets. You build in escape hatches for the 20% of cases that don’t fit the mold. Golden paths let you standardize without fossilizing your processes, and they’re the antidote to “TicketOps.”

Second: the Model Context Protocol (MCP). This is the glue that makes it all work. MCP is a standard that exposes your golden paths as tools that an AI assistant can actually call. Think of it as an adapter layer between your assistant and your platform. The assistant can observe your systems: what services exist, what their SLOs are, what incidents are open right now. It can propose a plan (“I’ll deploy this to preview, run tests, then promote to prod”). And it can execute approved actions while logging everything for audit and observability. MCP turns your platform into a set of composable, auditable operations.

Here’s what this looks like in the real world. An engineer types: “Spin up a preview environment and load our staging data.”

The assistant gathers context. What’s the service’s dependency tree? What are the current SLO baselines? Who owns this service? What recent incidents or postmortems should I know about? It drafts a plan that respects your runbooks and standards. It shows you the diffs and policy checks that apply. Then it either executes immediately (low-risk actions) or routes to the right approver (medium/high-risk actions). Everything gets logged.

This isn’t theoretical anymore. It works.

How You Actually Build This

The architecture starts simple: pick one golden path. One high-value workflow, like service deployment, that you want to standardize.

Next, you build MCP servers that act as adapters to your existing systems. Your runtime layer exposes Kubernetes operations (deploy, scale, health checks) and feature flags as callable tools. Your delivery layer connects to Git, GitHub Actions, or GitLab CI to handle builds, promotions, and canary deployments. Your reliability layer taps into SLO systems, alerting platforms, and observability tools so the assistant can query metrics, create SLOs, and mute alerts with proper context. Your change control layer enforces approvals and integrates with compliance workflows.

Underneath all of this runs retrieval-augmented generation (RAG). Before the assistant proposes any action, it indexes and searches your runbooks, compliance standards, postmortems, and architectural guidelines. The plan that comes back doesn’t just say “deploy the service”, it references your procedures. “Deploy using our standard blue-green pattern [link to runbook]. SLO impact: +2% latency at p99 (within budget). Dependencies: notify the data team [link to postmortem]. Policy check: OK, proceed.”

Safety gets enforced as policy-as-code, not friction. You define risk tiers: low-risk actions (like querying logs) auto-execute. Medium-risk actions (like scaling a service) require human approval. High-risk actions (like deleting a database) are blocked unless routed through a formal approval path. Standards violations get auto-fixed when confidence is high, or escalated when not. Everything is logged.

The user experience ties it all together. An engineer uses chat or a slash command to describe what they need. The assistant gathers context from your systems and knowledge base, drafts a plan with full diffs and impact estimates, shows what policy checks apply, and executes: staying in the loop for decisions that matter (approvals, tradeoffs) but handling the rote work. Everything that happened gets logged: the initial request, the plan, who approved it, what actually ran, what the outcome was.

The Real Payoff

Over time, this architecture unifies your platform. Your internal developer platform (IDP) becomes more than a portal where people click and read documentation. It becomes an actor that moves with your engineers, understanding context, respecting guardrails, and turning workflows into outcomes.

You measure it differently too. Not by pageviews to your portal, but by lead time to production. By mean time to recovery when things break. By consistency of safety across teams. You tie actions to business impact: AI-assisted scaling and predictive capacity planning can deliver up to 25% cost optimization while keeping SLOs intact.

The shift from ticket-based workflows to action-based workflows with AI assistance and policy-driven safety doesn’t happen overnight. Start with one golden path. Build the MCP adapters for one system at a time. Add guardrails incrementally. But the direction is clear.

Push intelligence and safety down into your platform so that doing the right thing becomes the easy thing. And the hard work, decision-making, tradeoff analysis, exception handling, stays where it belongs: with your engineers.

That’s where we’re headed. And honestly? I think it’s going to change how we all work.

Today’s CloudPro is about the five batch-scoring knobs most engineers overlook. If you’ve ever watched a job stretch from minutes to hours and wondered why, this is where you start.

Subscribe now

This article is adapted from Chapter 5 of Hands-On MLOps on Azure. In that chapter, author Banibrata De dives into the gritty details of model deployment: batch scoring, real-time services, and the YAML settings that make the difference between smooth pipelines and midnight firefights.

(The book goes much further, covering CI/CD pipelines, monitoring, governance, and even LLMOps across Azure, AWS, and GCP. CloudPro readers can grab it at the end of this piece with an exclusive discount.)

Cheers,

Shreyans Singh

Editor in Chief

Get The Book

Tuning Batch Jobs on Azure ML: 5 Knobs Every Engineer Should Know

It’s late. The batch run you trusted starts crawling. Dashboards spike, Slack pings light up, and you’re debating whether to kill the job or ride it out. You don’t need a re-platform. You need to tune the controls Azure ML already gives you.

Below are the five knobs that tame throughput, flakiness, and costs. They live in your batch deployment YAML, and they work.

1) mini_batch_size: The throttle for your workload

Batch jobs in Azure ML process data in chunks. mini_batch_size controls how big each chunk is. Push it too high, and you’ll hit memory or I/O bottlenecks; keep it too low, and you’ll waste time on overhead. Think of it like loading a truck: too few boxes and you’re underutilizing space, too many and you risk breaking the axle. Getting this balance right often cuts hours off long-running jobs.

2) max_concurrency_per_instance: How many cooks in the kitchen

Each compute node can process tasks in parallel, but how many at once depends on its resources. max_concurrency_per_instance is that dial. If you pack too much onto a single node, CPU and memory will thrash, and everything slows down. Start low, then gradually raise it while watching system metrics. The goal is steady throughput, not chaos.

3) instance_count: Scale out, don’t just scale up

Even with tuned concurrency, sometimes one node just isn’t enough. That’s where instance_count comes in. It decides how many nodes you’ll spread the workload across. It’s the knob you turn when you need predictable completion times. For example, making sure the nightly run finishes before business hours. More nodes mean more cost, but also fewer late-night surprises.

4) retry_settings: Resilience for the real world

In batch jobs, things fail: a network hiccup, a corrupted file, a transient storage timeout. Without retries, the whole job can collapse because of one small blip. retry_settings lets you say, “Try again a few times before giving up.” Set sensible timeouts and retries per mini-batch so small failures don’t derail the entire pipeline.

5) error_threshold: Fail smart, not early

What happens if some data records are bad? By default, too many errors can abort the run. With error_threshold, you control how many you’ll tolerate. Setting it to -1 tells Azure ML to ignore errors completely. For messy real-world datasets, this is a lifesaver: you can still ship 99% of results and deal with the outliers later, instead of losing the entire batch.

Extra sanity checks

• Respect the contract: Batch jobs are built for files/blobs in, files/blobs out. Don’t try to wrap them around per-record HTTP calls.

• Keep scripts separate: Use batch_score.py for batch and online_score.py for real-time. Different handlers, different expectations.

• Watch metrics that matter: Throughput, per-batch latency, error rate, and CPU/GPU/memory use. Wire alerts so you’re not caught off-guard at 2 a.m.

Takeaway

Batch scoring doesn’t have to be a black box. Azure ML gives you the levers. You just have to use them. Tune these five settings, keep batch and online flows separate, and you’ll get faster, more reliable runs without babysitting every night.

This walkthrough is pulled straight from Chapter 5 of Hands-On MLOps on Azure. The full book expands on everything here: deployments, monitoring, alerting, governance, pipelines, and operationalizing large language models responsibly.

For the next 48 hours, CloudPro readers get 35% off the ebook and 20% off print. If Azure ML is part of your stack, or about to be, this is the reference worth keeping open on your desk.

Get The Book

Today’s CloudPro is written by Daren Fulwell, Field CTO at IP Fabric. Daren has over 25 years of experience in networking, and he is well-known for his work mentoring engineers, and helping organizations bridge the gap between design fundamentals and modern automation.

In today’s CloudPro, he explores why AI on its own won’t deliver true network autonomy. Instead, Daren shows how the real path forward lies in combining automation, AI agents, and a network digital twin, so teams can move beyond hype and build networks that are transparent, predictable, and genuinely autonomous.

And if you’re looking to put these ideas into practice, we’ve just released the Network Automation Cookbook, Second Edition. Packed with over 100 hands-on recipes, it shows you how to automate network devices and cloud platforms using Ansible, AWX, Nautobot, and Terraform. It’s 30% off exclusively for CloudPro readers, for the next 72 hrs. Grab your copy and start building real-world automation workflows today.

Cheers,

Shreyans Singh

Editor in Chief

Subscribe now

Share

AI alone won’t deliver the autonomous network

By Daren Fulwell

In the network engineering community right now - as in most areas of IT - you can't escape the AI hype. We've been working to understand how network automation will change the way we operate our infrastructure, and agentic AI is being proposed as the missing piece of the puzzle. Folks in the know have been experimenting and making their results available in blog posts and Youtube videos for the rest of the world to salivate over. Finally, it looks like we have taken the right turn towards the self-driving network.

Or have we? Are a handful of small-scale experiments with limited scope and even more limited capability proving anything? At best, there is a lot more investigation required, at worst the experiments that we don't see are proving that AI is not to be trusted with our critical infrastructure yet.

Networks aren't just collections of individual devices that we configure and then they do what we tell them: they are interconnected, propagating their world view to their immediate neighbors and beyond, to create a "hive mind" behavior for the whole system. And in most cases, our networks are actually networks of networks - interconnected and sharing state information to extend that collective view from user to workload.

In traditional network operations, this meant having multiple teams - with their own documentation and subject matter experts in the technologies and platforms - who all needed to interface to provide end-to-end service. Maintenance of the infrastructure required deep collaboration between teams and across silos. A thorough understanding of the networking technologies needed to be applied to tooling and documentation to ensure change impacts were tracked and understood.

In the agentic AI world, this is taken to the next level. The work is divided up for agents to be given small, carefully-defined scopes to work within, making specific types of change or reporting on specific behaviors. But due to the distributed, interconnected nature of networking, none of those agents can work independently of the others: the effects caused by one will potentially be felt by them all. Without true collaboration between the agents, it becomes impossible for us to trust that they will give us the desired outcomes without humans (with an understanding of the infrastructure) manually checking everything they do.

In short, AI agents cannot operate the network autonomously without some collective understanding of the end-to-end network.

The Sources of Truth that we have been building for our network automation processes seem to fulfil at least elements of this need. But they alone are not enough as they really represent the desired state of the network, not its current operating state.

Consider these four key requirements for that source of knowledge:

1. We need a view of the end-to-end network in the form of structured data, with a well-documented schema, and able to be accessed over clearly defined APIs or protocols to provide a consistent end-to-end view to all agents

2. It must be a complete and up to date view of the network as it is operating. There is little point in having a clear view of part of the infrastructure then little or no understanding of other parts when one can so heavily impact the operation of the other.

3. Relationships and collective behavior are key to understanding how the network behaves: maintaining a list of devices (that may or may not be complete) and some data points about those devices may be useful but does not give the full picture

4. Network behavior is on the whole deterministic: a set of devices with specific state and connectivity should always behave the same way. So the data model must be based on facts collected from the network devices themselves, analysed and modelled as behavior - rather than being formed from conjecture, opinion or correlation of related events (the best you can expect from that is a general indication of direction)

Share

A true Network Digital Twin has all of these characteristics:

A Network Source of Truth system has some of these, but misses the key aspect of understanding network behavior end-to- end. For example, consider:

1. A change is required to enable Internet users gain access to an application hosted in a private DC. The external firewall is updated with NAT rules and policy changes to provide access; DNS changes are made; and routing is checked from the DC to ensure that traffic can be forwarded from user to frontend and back. But it still fails when the changes are pushed, because the security policy applied in the DC fabric only allows testing from internal hosts. The coordinated effort across multiple domains (read AI agents) has failed due to an incomplete view of the service dependencies;

2. A DR exercise is under way, causing applications to be switched from one location to another. Load balancing rules are being changed to facilitate that and the virtual IP successfully moves traffic flows to the new location. Two of the four servers in the load balancing pool are working fine, so the pool is up and being serviced, but not at full capacity. While the remaining servers are up and the correct services are running, routing from the load balancer to those servers is not correct: using the Digital Twin this end-to-end behavior can be diagnosed in advance and remediation carried out to fix this before live traffic is diverted through this path.

AI is going to change the way we operate networks. But in order to deliver its true potential, it needs not only to be able to deliver automated process, but to be fed real understanding of the networks it will operate in order to validate that it is doing what it needs to.

Share

If today’s article got you thinking about how to move from talking about automation to actually building it, you’ll want to check out our brand new release: Network Automation Cookbook, Second Edition.

This updated edition is packed with over 100 hands-on recipes showing how to use Ansible, AWX, Nautobot, and Terraform to automate both on-prem and cloud networks. It’s written for engineers who want practical workflows, not just theory, and every recipe comes with reproducible labs so you can practice safely.

As a CloudPro reader, you can grab it at 30% off for the next 72 hours.

Get The Book

Thanks for reading CloudPro!

Subscribe now

In today's CloudPro, he looks at how developers can use LXD containers on Ubuntu to keep their setups clean, spin up secure environments quickly, and avoid the headaches of traditional VMs.

Cheers,

Shreyans Singh

Editor-in-Chief

Share

Subscribe now

Have you ever broken your Ubuntu setup by installing conflicting packages, or wasted an entire afternoon waiting for a virtual machine to boot just to test one library? These little frustrations are all too common for developers. Containers on Ubuntu offer a cleaner way forward, and with LXD, you can build fast, secure, and reproducible environments that don’t weigh down your system.

Streamlining and Securing Development with Containers on Ubuntu

Developers often add tools and services directly onto their Linux desktops because it feels quick and convenient. The problem is that every new service increases your system’s attack surface, especially if something opens a network port in the background. A safer, more efficient approach is to run your development environments in containers. You spin them up only when you need them, and they stay isolated from your daily workflow.

In this article, we’ll discuss LXD, the Linux Container Daemon, due to its outstanding integration with Ubuntu. Conceptually, this would apply to other container technologies as well, but the usage would vary.

LXD stands out as a powerful solution for developers using Ubuntu, providing a lightweight and flexible approach to containerization, offering a compelling alternative to traditional virtual machines and other container technologies.

Why LXD instead of Docker or VMs?

If you’ve worked with Docker or virtual machines, you may wonder why LXD matters. Here’s a quick comparison to put it into perspective:

That last row is the key: LXD gives you a lightweight “virtual machine–like” environment, without the VM bloat.

Why Choose LXD for Development?

LXD containers are specifically designed to meet the needs of developers, offering a unique set of benefits:

1. Lightweight and Efficient: Unlike resource-intensive VMs that require full OS installations, LXD containers share the host kernel. This minimizes overhead, leading to significantly faster boot times, a reduced memory footprint, and improved overall performance. This efficiency is crucial for rapid iteration and testing across various environments without performance penalties.

2. Image-Based Management: LXD's reliance on images for container creation transforms environment management. It enables effortless sharing, versioning, and reproducibility of development environments, ensuring consistency across different machines and simplifying collaboration. This approach streamlines workflows, allowing developers to spin up new environments with specific configurations and dependencies quickly.

3. Security Fortified: LXD provides robust isolation through kernel namespaces and advanced security features, safeguarding the host system and other containers from potential vulnerabilities. This secure environment allows developers to focus on their code with peace of mind.

4. Scalability and Flexibility: LXD excels in scalability, allowing developers to easily create multiple isolated environments for different projects, branches, or feature implementations. This fosters a highly organized and efficient development process, enabling rapid switching between environments without impacting other projects.

5. Seamless Ubuntu Integration: LXD's tight integration with Ubuntu leverages the operating system's robust package management system and offers access to a vast repository of pre-built images and tools. This streamlines development and ensures compatibility with a wide range of software and libraries.

Quick use case:

Let’s say you want to try out PostgreSQL 17 without risking your workstation setup. Launch an LXD container, install PostgreSQL inside it, test it safely, and if things break, just roll back to a snapshot. Your main system stays untouched.

Getting Started with LXD on Ubuntu

Installing and configuring LXD on Ubuntu is straightforward, as it's available directly from the Snap Store.

ken@monster:~$ sudo snap install lxd
ken@monster:~$ sudo usermod -aG lxd "$USER"
ken@monster:~$ newgrp lxd
ken@monster:~$ lxd init --auto

The lxd init --auto command initializes LXD with recommended settings. For more control, omit --auto to go through an interactive configuration process, allowing you to choose storage backends (like ZFS for advanced features or LVM for flexibility), configure network settings (bridge interfaces or NAT), and set up image remotes to access pre-built images.

Essential LXD Container Management Commands

LXD provides a comprehensive command-line interface (CLI) for managing containers:

1. lxc launch <image> <name>: Creates and starts a new container from an image.

2. lxc list: Displays a list of all running containers.

3. lxc start/stop/restart <name>: Manages container lifecycle.

4. lxc exec <name> -- <command>: Executes commands within a running container.

5. lxc file push/pull <local_path> <remote_path>: Transfers files between the host and a container.

For development, it's often more convenient and secure to run as an ordinary user with your home directory mapped into the container:

ken@monster:~$ lxc launch ubuntu:25.04 plucky-devel -c raw.idmap="both $UID 1000"

ken@monster:~$ lxc config device add plucky-devel homedir disk source=$HOME path=/home/ubuntu

ken@monster:~$ lxc exec plucky-devel -- su -l ubuntu

This configuration launches a container, maps your user ID, mounts your home directory, and provides a login shell as the ubuntu user inside the container, allowing you to use your favorite editor on your host system while executing code within the isolated container.

Unlocking Advanced Features

LXD offers features that further enhance development workflows:

1. Remote Access: Manage containers remotely via the secure REST API.

2. Networking Mastery: Configure virtual networks to isolate containers and simulate complex network topologies for testing.

3. Storage Management: Optimize storage performance with different backends like ZFS or LVM.

4. Profiles for Reusability: Define reusable profiles to simplify container creation with consistent configurations.

5. Snapshots and Rollbacks: Capture container states to revert to previous working configurations, ideal for experimentation quickly.

6. Moving and Migrating Containers: Easily move or migrate running containers between LXD hosts or even to different cloud providers.

Pro tip:

If you often create containers with similar settings, use profiles. They’ll save you from repeating the same config steps over and over. The Ultimate Ubuntu Handbook shows how to build reusable profiles for real projects.

The Future of LXD

LXD continues to evolve, with ongoing efforts to integrate with Kubernetes for seamless orchestration and improved virtualization support for demanding workloads. Enhanced security features and a developing web-based user interface (sudo snap set lxd ui.enable=true && sudo snap restart lxd) are also on the horizon, making LXD even more accessible and powerful for developers.

The bottom line? LXD is a game-changer for developers on Ubuntu, offering a compelling blend of efficiency, security, and flexibility. By embracing LXD, developers can create efficient, reproducible, and secure environments that streamline workflows, enhance collaboration, and accelerate innovation.

Share

Ken’s walkthrough is just a glimpse into what’s possible when you bring containers into everyday development on Ubuntu. If you’d like to go deeper, his book The Ultimate Ubuntu Handbook is full of practical examples, from building secure containers to streamlining workflows and preparing for production deployments. It’s a guide designed to stay useful long after the first read.

Get The Book