The Agentic Enterprise Needs an Owner
Agents and models are becoming commodities. The enterprise advantage now lies in the operating model, governance, context, and accountability around them.
Welcome back!
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.
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.
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.
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.
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.
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.