The biggest obstacle to enterprise AI isn’t models, data science talent, or even infrastructure.  It’s operations.

Across today’s enterprises, hybrid complexity has outpaced IT’s ability to manage it. Applications, workloads, runtimes, and infrastructure now span on‑premises environments, public clouds, edge locations, and air‑gapped sites. Each layer brings its own tools, vendors, and operational language. The result is friction everywhere and a widening gap between AI ambition and operational reality.

Latha Vishnubhotla, chief platform officer at Hewlett Packard Enterprise, tells The New Stack the challenges begin on Day 2.

“People can bring things up and make them functional very quickly,” says. “But where they spend most of their time is after the infrastructure becomes functional. Day 2 to Day N is where they spend a lot of time.”

That’s the problem enterprises are running into now. It’s not getting infrastructure up and running, but keeping it running, optimized, and reliable as AI workloads move from pilot to production.

Read on to dive into not only the Day 2 problem, but to learn how HPE’s GreenLake hybrid cloud management platform has grown to respond to this enterprise complexity — including that cross-platform infusion of agentic AI. 

Day 2 is when the hybrid cloud breaks down

In hybrid environments, operations teams aren’t managing a single stack. They’re juggling multiple runtimes, from bare metal and VMs to containers and AI‑native platforms.  Infrastructure across compute, storage, and networking often from different vendors. Workloads spread across data centers, public clouds, edge, and disconnected sites.  Legacy systems that were never designed to work together

Each layer has its own management tools and telemetry. When something goes wrong, the symptom rarely appears in the same place as the root cause.

“All these different tiers are talking to each other, but it’s not linear. You have to comb through and figure out where the issue actually is.”

“All these different tiers are talking to each other, but it’s not linear,” Vishnubhotla says. “You have to comb through and figure out where the issue actually is.”

Day Zero provisioning may be fast. Day 2 operations are where complexity compounds and teams burn time reacting rather than optimizing.

More AI is making the ops problem worse

AI not only raises the stakes but also delivers a solution.

Enterprises want to run more AI workloads, but data centers have finite capacity. Power, cooling, cost, and sustainability constraints are real. That’s why FinOps and GreenOps have become inseparable from infrastructure operations.

“When you want to run these workloads, you have to ask: what’s not being used?” Vishnubhotla says. “Why am I wasting here? Should I move something? Should I retire it?”

This is where traditional, human‑driven ops models start to break. There’s too much data, too many layers, and too many dependencies to reason about manually, especially at enterprise scale.

The ops platform as connective tissue

What enterprises need isn’t another point tool. It’s an operations platform that acts as connective tissue across the hybrid estate.

That’s the role GreenLake is designed to play.

GreenLake provides a unified platform experience for running and managing hybrid environments across on‑premises, private cloud, edge, and collocated infrastructure while preserving choice and control. Instead of hiding infrastructure behind abstraction, it makes it visible, observable, and operable from a single control plane.

“The control plane is actually running in the cloud,” Vishnubhotla says. “You get visibility across the entire estate.”

For organizations managing thousands of sites and tens of thousands of devices, that visibility is foundational. But visibility alone isn’t enough anymore.

Why agentic AI changes everything

The next step is agentic AI, AI systems embedded directly into the ops platform, trained on the context of specific infrastructure domains.

A networking agent understands networking. A storage agent understands storage. A compute agent understands compute. Each brings deep, domain‑specific intelligence to Day 2 operations.

“Each layer already has intelligence,” Vishnubhotla says. “If we can connect this intelligence, we can unleash very powerful outcomes.”

That’s where the idea of an agentic mesh comes in. Instead of siloed insights, AI agents share context across layers during provisioning, troubleshooting, and optimization. This shortens the time to root cause, reduces alert noise, and opens the door to predictive and, eventually, autonomous operations.

Predictive maintenance is a clear example. Rather than reacting to failures, AI can anticipate what’s likely to break, prioritize what actually matters, and help teams act before outages cascade.

Faster time to value for AI starts with competent ops

Agentic operations also unlock something enterprises care deeply about: faster AI ROI.

With a shared, platform‑level view, ops teams can answer questions like:

• What is connected to the estate
• Where is infrastructure deployed?
• Who’s using it—and how?
• Where is capacity being wasted?

GreenLake supports automation through copilots and MCP servers as well as UI‑driven workflows, reducing provisioning times and operational overhead. AI agents can even help predict demand and close feedback loops that used to take weeks.

“The bottleneck has always been on the ops side. Enterprises are deploying and operating infrastructure from Day Zero to Day N to unlock AI value faster.”

“The bottleneck has always been on the ops side,” Vishnubhotla says. “Enterprises are deploying and operating infrastructure from Day Zero to Day N to unlock AI value faster.”

The answer is a platform, not another tool

Hybrid complexity isn’t temporary. AI pressure isn’t slowing down. And Day 2 operations are only getting harder.

That’s why the industry is converging on a clear conclusion: the answer isn’t more tools; it’s a unified, intelligent ops platform.

GreenLake brings together visibility, agentic AIOps, and cross‑domain intelligence in a platform built for how enterprises actually run today. It connects the silos, scales operations teams, and turns infrastructure from a bottleneck into an enabler.

If AI is the future of the enterprise, operations is the gatekeeper.  And the ops platform powered by agentic AI is how that future gets unlocked.

The post Why agentic AI makes the ops platform the most important layer in the enterprise appeared first on The New Stack.

Platform engineers are some of the most resourceful people in IT. Give them a problem, and they’ll automate their way toward a solution. But what happens when the automation itself becomes the problem?

This is the quiet crisis hiding inside many organizations today. In the race to reduce toil, teams have built what amounts to a mountain of automation. Scripts, layered on blueprints, layered on orchestration workflows, layered on tooling, APIs, GitOps, and infrastructure and label it a “platform.” This isn’t a platform; it’s complexity dressed up in a better outfit.

Trading one problem for another

Here’s the dirty secret about using automation to build your own platform stack: you don’t actually eliminate complexity; you just become responsible for it in a new way.

It starts well enough. You automate a painful workflow, ship it, and you move on to the next fire. But automation doesn’t maintain itself. Over time, the team that wrote it moves on. As they do, the context behind why it was built fades.

Nobody quite remembers what the edge cases were, why that snowflake script was written that way, or the original problem it solved. And when it breaks–and it will break–you’re not debugging an application. You’ll be performing an archaeological excavation of your own infrastructure, to decipher the intent of the team that originally constructed the automation.

When scripts outlive their authors

So you do what engineers do: you automate around it. You add new automation on top of old to address the gaps. Now you’re managing two mountains of automation instead of one. And here’s the impact that rarely makes it into the original business case – the platform team doesn’t get to walk away when it’s “done” because it’s never done.

These engineers can’t be reassigned without your platform decaying beneath the applications and services that make up the business’s backbone. You need a robust team to manage this indefinitely just to keep the lights on. We’re simply trading software costs for people costs. And often, you end up spending more to produce something less scalable and capable than what you had from day one.

“Automation may mask complexity but does not eliminate it, and mountains of automation makes diagnosis and repair exponentially harder when things go sideways.”

This is the real trap. Automation, at its best, is a productivity multiplier. At its worst, it’s lipstick on a pig; all the ceremonies of agility without the true benefits. Automation may mask complexity but does not eliminate it, and mountains of automation makes diagnosis and repair exponentially harder when things go sideways.

What a pre-engineered PaaS actually does

A true Platform as a Service (PaaS) isn’t a collection of automation. It’s a pre-engineered system where the underlying plumbing, services, security, and resilience are already integrated before you ever install and consume it. This is the ‘batteries included’ model where the platform is ready to use on Day 1 based on best practices and proven architectures. This kind of integration out-of-the-box is one of the things that makes a platform trustworthy and predictable at scale.

For example, an integrated platform includes ‘how’ applications are built and deployed is pre-wired out of the box and works consistently across application types. One of the more unique things Tanzu Platform does is build deployment packages, including the base image for developers. This means that when a security problem comes out–like Copy Fail or the flood of AI-discovered vulnerabilities–the platform engineer can rebuild and redeploy apps very quickly without reaching back into the software delivery lifecycle (SDLC). They simply “restage’ the application using a single command.

The consistency of deployment packages and base images also enables developer velocity in the every day. When every application is built, packaged, and deployed the same way, developers stop re-solving the same infrastructure problems, and start focusing on the code that actually matters. This is a distinction worth drawing clearly–assembling capable open source tooling like Terraform, ArgoCD, Kubernetes, cert-manager, OpenBao, and Istio gives you powerful building blocks, but it doesn’t give you a platform.

You still own the integration, automation, the opinions, lifecycle management, and the operational model that ties them together. A pre-engineered PaaS handles the myriad of decisions for you. With a PaaS, onboarding a new team or new application isn’t a one-off integration project; it’s a repeatable, predictable process. Standardization is a core outcome of a pre-engineered PaaS, not a side effect, and it’s precisely what makes it possible to push changes faster and with more confidence, regardless of the team, language, or application type.

Security built into the platform

Security works the same way. When your team makes the decision to pull from open-source components and stitch them together, you now own every security gap between them – data at rest, data in flight, and its running state. This seems like a worthwhile investment at first, but as recent research suggests, AI-assisted attacks are on the rise, and platform teams won’t be able to keep up with surging security vulnerabilities in the build-it-yourself model.

A pre-engineered PaaS standardizes the governance and compliance posture across the board. Updates, patches, and fixes from a trusted, first-party vendor mean you’re not reinventing governance from scratch each time you add a new component. The PaaS can help you uniformly and at scale apply the changes in a cascading fashion rather than relying on custom automation.

The calculus starts to shift when you see deployment, security, and onboarding issues in aggregate. Achieving all of this with custom automation means spanning organizational silos, coordinating teams, sustaining headcount, and continuously funding work that never actually finishes.

And worse yet, this work has no meaningful competitive advantage for your organization. Your competitors are working to solve the same problem, but you’re just burning more resources to accomplish the same end result. You own the problem entirely rather than leaning on a trusted, proven vendor. Embracing a PaaS allows you to focus on higher-value, differentiating initiatives for the business.

AI is the forcing function

The conversation around PaaS is urgent again, and AI is why. Code generation can speed up your development cycles, building and pushing features faster, but production delays will persist if you’re still deploying at the same speed as before. 

To avoid eroding the benefits of code generation, you need to deploy applications nearly as fast as they can be coded with AI. This requires streamlining each step of the path to production. In an era where more organizations are exploring the use of autonomous agents, they need a platform that doesn’t take weeks to rotate credentials, days to provision a database, or require access to JIRA’s MCP Server to accomplish their goals.

“To avoid eroding the benefits of code generation, you need to deploy applications nearly as fast as they can be coded with AI.”

The pace of AI innovation itself compounds the problem. Whether it’s shadow AI use, MCP servers, agentic harnesses, this week’s new foundation models, or whatever emerges next, the landscape is evolving fast enough that what’s bleeding-edge today may be table stakes in six months. When you build your own platform, you’re on the hook to evaluate each layer of these new technologies, determine how they fit into your stack, and then integrate them yourself, on top of everything else your platform team is already managing to keep the business going.

Organizations running VMware Tanzu Platform receive those innovations. With Tanzu Platform 10.4, for example, customers gained MCP Gateway, an expanded service marketplace where developers can publish their own MCP servers and services for cross-organization consumption, as well as an agent buildpack to streamline and secure the deployment of agentic AI applications.

These are capabilities that would have taken a DIY team months to evaluate, build, and harden. And this isn’t unique to AI. Every release brings new capabilities across the platform that customers simply inherit, without the integration tax. That’s the compounding return on your investment in a pre-engineered PaaS. The platform keeps moving forward, and so do you.

VMware customers: You’re closer than you think

Platform engineers are uniquely equipped for this moment. They have the pattern recognition, they have seen the technology waves before, they bring their hard-won operational instincts, and the critical thinking skills to know when a system is genuinely resilient versus cleverly disguised complexity.

That’s exactly why their role in curating and operating this next generation of PaaS matters more than ever. Platform Engineers applying these battle-tested experiences using a PaaS will shortcut the tedious automation pitfalls, jumping straight to safely delivering Agentic AI and GenAI application services.

If you’ve already built your stack on VMware Cloud Foundation you’re already in a position to add the value of a true PaaS. VMware Tanzu Platform layers a pre-engineered PaaS on top of your existing infrastructure APIs, running alongside your VMs and containerized workloads, without ripping out what you’ve built and budgeting for alternatives.

With an incremental step, you can leverage what you know and trust, and layer on the only private cloud PaaS for agents that offers direct integration with Private AI services.

The post The DIY platform trap that’s burning out engineering teams appeared first on The New Stack.

To hear Yasmin Rajabi, chief operating officer at CloudBolt, tell it, there’s an imbalance in how we view automation. We’re happy to automate decisions that result in more productivity and processes — but what about when it comes to turning the dial to the left? For some reason, there’s hesitation there.

“Trust is super-high when it comes to traditional automation, but there’s still a lot of caution when it comes to right-sizing,” Rajabi tells The New Stack. “The same engineers who are deploying multiple times a day through CI/CD aren’t questioning [automation] anymore, but when it comes to delegating right-sizing to the machine, the bar to earn that trust is much higher.”

The data reveal why this imbalance might exist: When faced with the pressure to remain always-on, a higher cloud bill from over-provisioning seems worth the cost. But now that GPU-heavy AI workloads have sent cloud bills soaring, right-sizing automated processes has become a priority for 89% of organizations, according to the March 2026 CloudBolt Research Report.

And yet, 71% of Kubernetes engineers respond that they still require human review for resource optimization, with only 27% allowing CPU and memory changes to be auto-applied. So while the data shows it’s a priority, that motivation hasn’t shown up in the workflows.

“When it comes to delegating right-sizing to the machine, the bar to earn that trust is much higher.”

The New Stack will sit down with Rajabi and Reid Vandewiele, product lead at StormForge, at 9 a.m. Pacific/5 p.m. BST on Wednesday, June 24 to discuss the urgency of this right-sizing gap — especially when it comes to Kubernetes workloads for AI.

Join us live to not only learn how to measure your organization’s automation maturity, but to develop this trust over time, with strategic CPU throttling, out-of-memory (OOM) behavior, and, of course, rollback patterns. 

Register to join this conversation

Right-sizing is a multi-dimensional problem, Rajabi explains, spanning increasingly complex workloads in increasingly complex environments, so that when something goes wrong, it feels almost impossible to reverse. For this automation to work, this trust has to be built not just across teams but scaled across your organization.

“It takes a long time to build up trust in an automation solution, and it’s very fast to eliminate or significantly undermine that trust,” Rajabi warns. “It takes one production incident to take an application team from being willing to entertain automated resourcing to absolutely not, ‘not on my application, we’re special’.”

Join us June 24 to learn how to gain insight into how much your AI workloads actually cost, and to adopt a plan that takes the guesswork out of your provisioning.

The post The fix for soaring AI cloud bills exists — so why won’t we trust it? appeared first on The New Stack.