Author: maribellopez

  • HPE Updates Hardware, Private Cloud And Networking For Agentic AI Era

    HPE Updates Hardware, Private Cloud And Networking For Agentic AI Era

    When public cloud computing emerged in the late 2000s and began scaling through the early 2010s, the prevailing theory was straightforward. Cloud computing theory claimed nearly every workload would eventually migrate off-premises. The economics were compelling, the convenience undeniable, and the momentum felt unstoppable. More than 15 years later, enterprise IT leaders are still managing substantial on-premises infrastructure — and many are actively investing in upgrades.

    Today, various research reports estimate that between 35 and 50 percent of workloads have moved to the cloud. Whether that figure is above or below 50 percent, it’s clear that workloads remain distributed. Cost, data sensitivity, regulatory compliance, latency requirements, and operational control all shape where a given workload belongs. The public cloud became one option in a complex portfolio, and the same will be true for AI workload placement. 

    Organizations have absorbed that lesson. In the early days, everyone ran AI proofs of concept in the cloud, but enterprise leaders are asking more specific questions on how to design scalable AI architecture. Today’s discussion centers on which AI workloads belong where and under what conditions? Cost recently surfaced as a major concern as AI token use skyrocketed. In many cases, AI costs escalated due to flawed policies that incentivized employees to consume as many tokens as possible to prove they were using AI.

    Today, organizations are considering the rationale for keeping workloads on-premises and whether upgrading their on-premises technology will be a cost-benefit or a disadvantage. It is not an easy question to answer. No technology vendor has delivered a definitive framework or spreadsheet that simplifies that decision. What has happened is that every major cloud and hardware vendor now offers some combination of managed AI services and pre-validated AI factory reference designs intended to help organizations scale AI deployments beyond proof of concept.

    The Hybrid AI Reality Is Already Here and Continues to Gain Momentum

    Walk into a strategy conversation with a large enterprise today, and you will rarely encounter a pure cloud or pure on-premises AI strategy. Hybrid deployments are the operating assumption. The more substantive discussion is about placement logic — what drives a workload toward private infrastructure, what drives it toward a public cloud, and what governance and connectivity model bridges the two. It is worth noting up front that HPE, as a hardware and infrastructure company, has a clear commercial interest in upgrading on-premises deployments. That context does not invalidate the market need, but it is relevant when evaluating how the company frames its positioning.

    Regulated financial institutions, healthcare systems, defense contractors, and national governments all have data residency requirements, sovereignty mandates, and security classifications must consider partitioning workloads between cloud and updated on-premises infrastructure.

    The AI Infrastructure Market Responds to Private and Sovereign Demand

    In 2026, most vendors are discussing which infrastructure advancements are needed to support agentic AI. While there were many hardware announcements at HPE’s annual Discover conference, the company also discussed updates to private cloud and sovereign AI infrastructure for agentic AI. HPE launched its first private cloud offerings roughly 2 years ago. 

    HPE is not alone in this space. Dell, Lenovo, and others have announced comparable on-premises AI infrastructure products built around Nvidia accelerators. Google Cloud was among the early movers in offering air-gapped, disconnected cloud offerings for regulated industries. The differentiation between these offerings — at the architecture, software, and services layer — is still being established in the market and warrants scrutiny from buyers evaluating alternatives. 

    HPE CEO Antonio Neri described the AI infrastructure decision as inseparable from data governance and sovereignty. Lopez Research has found this framing is consistent with what enterprise buyers in regulated industries report when asked about deployment constraints. HPE is delivering a pre-validated, purpose-built on-premises environment for AI workloads that reduces integration complexity and accelerates deployment timelines relative to assembling components independently. HPE also announced a Sovereign AI Factory configuration targeting governments and regulated industries, with built-in defense-grade security hardening, federal compliance readiness, and air-gapped operation. Let’s talk specifically about some of the ways HPE is addressing the agentic AI challenge. 

    Agentic AI Adds New Complexity to the Security and Governance Problem

    Neri articulated a theme that was consistent across the 2026 enterprise technology conference season when he discussed how AI has moved beyond generative assistants to autonomous AI agents. Technology vendors have discussed AI agents for more than a year. Many enterprises are already encountering agentic AI through their existing SaaS platforms. More advanced organizations are building and deploying their own agents. Lopez Research’s conversations with early adopters consistently surface the same operational pain points, including multi-agent orchestration across enterprise applications, securing and permissioning AI agents, governance, and company-wide observability into what agents are doing.

    Agentic AI introduces a security and governance surface for every organization that most existing enterprise security stacks were not designed to handle. Today’s security products were designed for individuals, not AI agents. These solutions are anchored on user credentials, access policies, and behavioral patterns. An AI agent, if allowed to do so, can operate autonomously, continuously, and at machine speed across multiple systems simultaneously. Bad situations propagate across workflows fast before any human reviewer is aware that something has gone wrong.

    HPE’s response at Discover included a three-tier identity model for agentic workloads that includes user verification, agent-level governance, and human approval gates for sensitive actions. It also offers the ability to wrap agents built in any framework with security controls, including API protection, identity management, and encryption, without requiring code changes. Integration with Nvidia OpenShell provides isolated execution environments per agent. NeMo Guardrails enforce policy at the model level. Zerto integration enables rollback to a clean state if an agent executes incorrectly.

    Private Cloud AI now includes a governed data layer with deep integration into the Nvidia AI Data Platform, giving enterprises a unified way to access, prepare, and manage data across their existing environments — no custom pipelines required. The HPE Alletra Storage MP Extend 1000 serves as the storage foundation, purpose-built for the performance demands of modern AI workloads. It adds real-time metadata enrichment and native MCP support, so agents and applications can retrieve the right data and context faster across both structured and unstructured data. HPE claims the result is a 7–12x faster time to value compared to building the environment yourself.

    Once your data is governed and ready, Private Cloud AI delivers the infrastructure to scale inference. Multi-node inference allows larger models to be served across multiple systems, so capacity grows naturally with demand. A new unified gateway gives teams a single API for accessing both frontier and open-source models, with centralized credentials, budgets, and policies built in. New configurations now scale up to 256 GPUs, which includes the new ProLiant DL394 with Nvidia GPUs optimized specifically for inferencing and long-context workloads. Additionally, shared KV cache capabilities eliminate the need to repeatedly recompute context, reducing cost per first token and delivering significant performance gains across the board.

    No architecture from any specific vendor will ever fully address a company’s governance or security problems. Still, buyers need to ensure that their vendors are addressing the problem and that they are willing to work with others to support a holistic approach. What HPE’s offering does represent is a concrete, specific engineering response to a recognized gap. Rami Rahim, HPE’s EVP and President of Networking, expanded on this in a separate day 2 session, arguing that the network itself must become an active enforcement layer for agentic security through zero-trust architecture, AI-driven anomaly detection, and automated policy enforcement. 

    Familiar AI Themes, With A Focus on Execution

    Assessed across the first half of the 2026 enterprise technology conference season, HPE Discover did not introduce themes that were new to the industry conversation. Sovereign AI requirements, the governance gap in agentic systems, and hybrid placement logic have all been visible in analyst briefings, vendor roadmaps, and customer conversations for some time. 

    That observation, however, should not diminish the significance of what Neri and Rahim presented. Identifying a trend early is necessary but not sufficient. The value of HPE Discover lies not in the novelty of the concept but in the focus of execution. What HPE customers were looking for was the degree to which the company has translated an accurate read of market direction into deployable infrastructure that enterprises and governments can procure and operate today. Whether HPE’s implementation proves durable competitive differentiation in a space where competitors are moving quickly is a question the next twelve months will answer. 

    HPE’s position is architecturally sound and consistent with broader industry direction. The customer deployments already underway illustrate there’s real demand in this space from various industry segments. The U.S. Defense Information Systems Agency (DISA) awarded HPE a ten-year contract to modernize its digital and AI platform capabilities, requiring a NIST-compliant private cloud environment that meets federal security classifications. In Europe, HPE is building the HammerHAI system at the High-Performance Computing Center Stuttgart (HLRS) in Germany. It is a sovereign AI installation delivering more than 15 exaflops of peak AI inference performance for research institutions and industrial organizations that must comply with European data residency requirements. In healthcare, St. Jude Children’s Research Hospital is using HPE Private Cloud AI to bring AI capabilities to its clinical and research teams while protecting sensitive pediatric oncology data. These three deployments — federal defense, national research infrastructure, and regulated healthcare — represent the segment of buyers for whom private and sovereign AI is a requirement, not a preference.

    Scaling AI Requires A Portfolio Approach

    The cloud never won all of the workloads. The economics, the regulations, and the operational realities of enterprise IT ensured that on-premises infrastructure remained relevant long after public cloud momentum suggested otherwise. The same dynamics are now shaping AI infrastructure decisions. 

    For organizations in regulated industries, private and sovereign AI is not a conservative hedge against innovation. For many, it is the enabling condition for AI adoption at all. But private AI infrastructure is not a complete exit from cloud services, and buyers should be cautious about treating it as such. 

    Even organizations running heavily on-premises AI environments (regulated or not) will almost certainly rely on the public cloud for a portion of their AI workloads. The question is how much. AI model training is the most frequently cited example — training large foundation models requires burst compute capacity that few enterprises can justify owning outright. But the dependencies extend further. AI experimentation and prototyping typically benefit from the speed and low commitment of cloud environments before workloads are validated for on-premises production. And accessing specialized frontier models — from providers like Anthropic, Google, OpenAI, or open-source alternatives — will often happen via cloud APIs, particularly for capabilities that do not require fine-tuning on proprietary data.

    In some cases, even those cloud touchpoints will need to meet sovereign requirements. Major hyperscalers have developed sovereign cloud offerings for regulated industries. A growing tier of neoclouds is positioning explicitly around sovereign infrastructure for organizations requiring local data residency, compliance certification, and jurisdictional control within a managed cloud model. The decision, in most cases, is not binary — it is a portfolio question about which workloads run where and what governance conditions each environment must satisfy.

    Regardless of the type of organization you are, validated reference designs for private deployment that can scale in a reasonable timeframe with minimal execution risk serve a real purpose. AI is not trivial to engineer independently. Pre-validated stacks lower the barrier for organizations that need private AI the most but have the least tolerance for deployment risk. HPE has made a substantive set of announcements in this space. So have others. Organizations keep getting better solutions to the “How do I build AI?” question nearly every month. Perhaps, the bigger question businesses need to focus on is “What do we need to build?” 

  • The Enterprise AI Time Bomb Is Ticking. Cisco Shares Its Plan.

    The Enterprise AI Time Bomb Is Ticking. Cisco Shares Its Plan.

    At Cisco Live in Las Vegas this week, the company delivered a sobering security message for enterprise buyers. AI helps the bad actors move faster, and the window to get ahead of it is closing quickly.

    “AI changes the speed of defense. The bad corollary to that is it’s empowering our adversaries at a pace that we’ve never seen in our careers. These models are as bad today as they’re ever going to be,” Cisco CEO Chuck Robbins told the packed keynote audience — a line that landed with more weight than a typical tech conference applause line. He wasn’t talking about AI being ineffective. He was talking about it being weaponized.

    A New Kind of Threat

    The cybersecurity industry has spent years warning about AI-powered attacks. What’s changed in 2026 is that frontier AI models — particularly Anthropic’s Claude Mythos have made those warnings concrete.

    What sets Mythos apart from prior AI models is not general intelligence but what it can do in a cybersecurity context. According to Anthropic, it can autonomously identify and exploit software vulnerabilities at a level that outpaces almost all human security experts. In controlled testing, the model has been shown to identify thousands of zero-day vulnerabilities over several weeks — a pace no human security researcher or team could match.

    The dual-use nature of that capability is what makes Mythos a defining moment for enterprise security. The same model that can find and patch vulnerabilities at unprecedented speed can, in the wrong hands, find and exploit them. CrowdStrike’s 2026 Global Threat Report found an 89% increase in attacks by adversaries using AI — and Mythos-class capability represents a meaningful step change in what those adversaries can bring to bear.

    Anthropic has acknowledged that “models of this capability level require stronger cyber safeguards before they can be generally released,” which is why public access has been withheld while safety work continues. But what this tells us is that enterprises must prepare for a post-Mythos threat environment where any number of increasingly capable open and commercial models can and will help bad actors exploit vulnerabilities in legacy or unpatched systems. We can also see that patching isn’t enough.

    Robbins warned that the capability floor for AI-assisted attacks had just risen significantly and will not come back down. The most alarming shift is speed. Where it once took days or weeks for bad actors to move from a disclosed vulnerability to a working exploit, that timeline has compressed to minutes. Cisco’s own security team demonstrated the flip side of that same capability. Robbins said in the past eight weeks, Cisco used AI to scan 1.8 billion lines of code across 25 programming languages. Before these models existed, Robbins said, that would have taken approximately eight years.

    The implication is uncomfortable but unavoidable. The same technology accelerating legitimate security work is accelerating attacks at the same pace. Neither side has an obvious advantage, and the defender’s job — protecting a complex, distributed enterprise — is structurally harder than the attacker’s.

    Agents Make Everything Harder

    If AI-powered threats were the only problem, that would be manageable. But Cisco’s President and Chief Product Officer, Jeetu Patel, outlined a second, compounding challenge: the rapid proliferation of AI agents is creating an attack surface that enterprises are almost entirely unprepared for.

    The AI industry evolved from chatbots that respond to questions to AI agents that can act autonomously. Patel said Cisco’s research found that a single AI agent generates roughly 450% more network traffic than a human performing the same task. Multiply that by thousands of agents running across an enterprise, and the infrastructure and security implications are significant.

    More importantly, agents have access to tools. Agents call APIs, query databases, submit code, and interact with external services. The goal of an agentic AI system is to perform tasks without a human in the loop. Patel’s framing was blunt: “Agents are like teenagers. They’re supremely intelligent, but they have no fear of consequence.”

    Agentic AI creates new attack vectors that aren’t easy to manage with existing solutions. For example, prompt injection attacks can manipulate an agent’s behavior. Data poisoning can corrupt its decision-making. Meanwhile, bad actors can perform tasks at high speed with a compromised agent  before anyone notices anything is wrong.

    While agentic AI has great potential, most enterprises lack the proper visibility, security and management to handle agents. Companies need a systematic way to know how many agents are running in their environment, what those agents are authorized to do, or whether they are behaving as intended. This is one security gap Cisco is racing to close alongside other security companies, hyperscalers, and startups.

    The Identity Problem Nobody Has Solved

    Businesses are just waking up to the problem of non-human identity posed by AI agents. Every person accessing a corporate system has an identity with a role, credentials, and permissions. Machines, services, and AI agents largely do not, at least not in any consistent or governed way.

    In May, Cisco acquired Astiix Security, an AI company focused on the non-human identity category.  Before enterprises can enforce meaningful controls on agent behavior, they need a reliable way to know which agents exist, what they have access to, and what they should be allowed to do. The platform helps organizations discover, govern, and protect machine identities, preventing unauthorized access and securing AI agents from malicious attacks. Cisco can integrate this technology into its Cisco Identity Intelligence and zero-trust products, such as Duo and Secure Access, to safely manage the proliferation of AI agents.

    This is not a theoretical future problem. Enterprises are deploying agents today, and most are doing so without the right identity infrastructure to govern them. If they deploy agents within a specific SaaS stack, permissions and governance are typically handled by that software. Once we start discussing multi-agent workflows that cross applications, the challenge becomes more complex. Astrix gives Cisco more capabilities to support identity for an agentic future.

    Cisco’s Response In Three Moves

    Beyond the Asterix acquisition, Cisco announced a set of products and capabilities aimed directly at the threat landscape it described.

    1. AI Defense, extended for agents. Cisco launched AI Defense roughly 18 months ago to provide visibility and guardrails for AI models and applications. The updated version adds capabilities specifically for agentic deployments: adaptive testing, behavioral guardrails, security for agentic supply chains, and support for all major agent platforms, including Claude, Codex, and OpenAI.
    2. Zero trust that gets an update for AI agents. The traditional zero trust model is built around access control: verify identity, grant minimum necessary permissions, and monitor behavior. Cisco correctly argues that today’s access control is insufficient for agents. What enterprises need is action control — the ability to intercept and verify every action an agent takes, not just whether it was authorized to log in. This is a meaningful architectural shift, and one that Cisco is embedding into its platform rather than offering as a standalone product.
    3. An agentic SOC. The cybersecurity talent shortage is severe. Approximately 4 million positions go unfilled annually in the US alone, according to Cisco. The volume of security alerts already exceeds human capacity to investigate. Cisco’s answer is an AI-powered Security Operations Center where agents autonomously triage alerts, identify anomalies, and, in time, predict and prevent breaches. The foundation is Cisco Data Fabric, a Splunk-powered platform that ingests petabyte-scale telemetry from network, security, application, and third-party sources.

    The Galileo Acquisition: Watching the Watchers

    Governing AI agents requires knowing what they are doing — not just whether they are authorized to act, but whether they are producing the outcomes they were designed for. This is the observability problem, and it is harder than it sounds.

    To address it, Cisco acquired Galileo, an AI observability company founded by researchers who previously worked with Google and DeepMind. Galileo’s technology powers what Cisco calls full-stack agent observability. This is visibility into infrastructure performance, model behavior, application runtime, and agent output quality. It also includes whether agents consume tokens at a sensible rate.

    That last point surfaced repeatedly during the keynote and reflects a real operational concern. A runaway agent that has been misconfigured or has drifted from its intended behavior can consume an entire organization’s annual AI budget in a matter of days. Token cost management is not a glamorous feature, but it is required for this new era of infrastructure.

    Cisco Cloud Control: The Platform Beneath All of It

    One of the more surprising announcements was the newly launched Cisco Cloud Control. For anyone who’s followed networking and Cisco for years, the concept of a true unified management console has been discussed for many years, and it’s devilishly difficult to execute. Every part of the portfolio had its own management tools that were loosely coupled at best, if at all. Cisco Cloud Control aims to be a new unified management platform that consolidates the company’s entire product portfolio under a single interface with single sign-on. Cloud Control is the operational layer through which Cisco intends to deliver its AI security and observability strategy.

    The security-specific capabilities embedded in Cloud Control, such as agent security monitoring, cross-domain threat correlation, and policy enforcement in natural language, represent a meaningful shift from how enterprise security tools have historically operated. Rather than logging into separate dashboards for networking, security, and operations, administrators can query their entire infrastructure environment in natural language and receive correlated, actionable insights across domains.

    The demos made it look like Cisco had finally cracked the code. Whether that vision holds up at enterprise scale remains to be tested. But the architecture Cisco described — silicon to semantics, from custom networking chips to AI agents operating on top of them — reflects a deliberate bet that the company’s control of the full infrastructure stack is a genuine competitive advantage in an AI-defined security landscape.

    The Reality. Enterprise AI Threats Are Real.

    Cisco’s keynote was, of course, a product announcement. But stripped of the stage production, the underlying argument is sound and worth taking seriously.

    AI is compressing attack timelines. Agents are expanding the attack surface in ways that existing security architectures can’t handle. The cybersecurity workforce is not growing fast enough to compensate. And most enterprises are deploying agents today without the governance infrastructure to know what those agents are doing, let alone control them.

    The organizations that will navigate this well are not necessarily the ones that move fastest. They are the ones that treat agent governance — identity, authorization, behavioral monitoring, and action control — as a first-class infrastructure concern rather than an afterthought. Enterprise technology leaders want and need their existing technology stack providers to evolve their security and management stacks to support AI threats. Cisco is making a significant bet that enterprises will pay for that infrastructure. Given the threat landscape it described, the bet seems rational.

    This article was originally published on Forbes.com.

  • Moving Beyond Building AI Agents With IBM’s Suzanne Livingston

    Moving Beyond Building AI Agents With IBM’s Suzanne Livingston

    Enterprises have agents. Most can't run them at scale. IBM's Suzanne Livingston explains what changes when you have hundreds — not two.

    Full Show Notes

    Scaling agentic AI is not the same problem as building it. At IBM Think 2026 in Boston, I sat down with Suzanne Livingston, VP of Product for IBM watsonx Orchestrate, to talk about where enterprise organizations actually are on this journey — and what it takes to move from a pilot to a production environment running hundreds of agents across dozens of departments.

    Suzanne walks through the full watsonx portfolio, then goes deep on the challenge she hears from customers constantly: the agent worked in the demo, but now it needs to run reliably at scale, with proper governance, observable across the estate, and permissioned correctly for every user and every system it touches. That is a fundamentally different problem than building the agent in the first place. The new Orchestrate Agent Control Plane is IBM's answer to it.

    This episode is for enterprise technology leaders who have moved past “should we do agents” and are now asking “how do we run them well.” If your organization is somewhere between first pilot and full production deployment, this conversation is the one to listen to this week.

    What We Cover

    • Why the jump from generative to agentic AI changes the operating model, not just the technology
    • What agent orchestration means in practice when you have 40 sub-agents reporting to one master agent
    • What the Orchestrate Agent Control Plane does and why cross-estate visibility matters more than per-agent optimization
    • How enterprises are treating AI agents like digital employees — with identities, goals, managers, and performance reviews
    • Why governance isn't optional in an agentic environment and what “governance light” looks like for organizations just getting started.

    Guest Bio

    Suzanne Livingston is Vice President of Product Management for IBM watsonx Orchestrate, IBM's enterprise AI orchestration platform. She leads the product team responsible for agent building, orchestration, evaluation, and the recently announced Orchestrate Agent Control Plane. Suzanne presented at IBM Think 2026 in Boston.

    Resources Mentioned

    📢 STAY CONNECTED

    🔍 ABOUT MARIBEL LOPEZ

    Maribel Lopez is founder and principal analyst at Lopez Research, a technology research and strategy firm focused on enterprise AI. She advises CIOs, CDOs, CMOs, IT leaders and technology vendors on AI adoption, agentic systems, AI governance, and AI-driven customer experience. Her insights have been featured in mainstream TV and print media such as Bloomberg, CGTN, Marketwatch, Reuters, Wall Street Journal, and Yahoo Finance. She's also a contributor to Forbes.com, and her research is used by organizations navigating the gap between AI capability and enterprise deployment reality.

    SEO Keywords I

  • The New AI Math: Time-to-Token and Cost-per-Token Gets Highlighted at Dell Technologies World

    The New AI Math: Time-to-Token and Cost-per-Token Gets Highlighted at Dell Technologies World

    At Dell Technologies World this morning, Michael Dell introduced new metrics for measuring whether enterprise AI infrastructure is actually delivering. The AI infrastructure conversation has been dominated by GPU counts, cloud-versus-on-premises debates, and model benchmarks. Dell’s opening keynote added two measures that tie those inputs to outcomes. The first is  how quickly your infrastructure generates tokens, and the second is at what cost.

    Uptime, GPU capacity, and model advances are all foundational. GPUs are what get you to tokens in the first place. But they are not enough on their own to make infrastructure decisions. Organizations are now facing a more challenging optimization problem. Companies face a seemingly endless demand for AI compute and the energy required to support it. Businesses must also balance the performance of these evolving AI workloads within budgetary and location constraints.

     Time-to-token and cost per token are the metrics that tie these competing priorities together. They measure how quickly and how cheaply your infrastructure converts data and compute into intelligence that agents and models can act on. Jensen Huang reinforced this on stage alongside Dell, and OpenAI’s Greg Brockman made the same point independently on X today: “tokens are rapidly becoming the universal input for solving problems.” When the infrastructure providers and the model providers converge on the same metrics within weeks of each other, that is a directional signal worth acting on.

    What Michael Dell described was a two-year refinement of the Dell AI Factory with NVIDIA, informed by 5,000 enterprise customers now running production AI workloads on it. The announcements were substantial. What they mean for enterprise buyers is worth unpacking.

    The Data Bottleneck Is the Real Constraint

    Michael Dell said something on stage that every CIO needs to hear: “If your data is siloed, your agents are blind.” That is a concise description of why so many enterprise AI programs stall after the pilot. It also echoes what Irfan Khan and Muhammed Alam described as the need for business context at SAP’s Sapphire and in an online event about business data. 

    Most organizations are simultaneously trying to prepare data for AI and reengineer the data infrastructure needed to support it. Those are two hard problems happening at the same time, on top of each other. Dell’s announcements around the Dell AI Data Platform addressed both directly.

    One of the things that has changed is the data orchestration engine, the intelligent control center within the Dell AI Data Platform that turns raw, fragmented enterprise data into production-ready AI fuel. It indexes billions of unstructured files of all types, builds governed data pipelines, connects them to the models and agents that need them, and delivers structured outputs at speeds that make agentic workflows viable. Dell claims the platform now delivers 12 times faster vector indexing, 6 times faster data querying, and 19 times faster time to first token than prior generations. While the claims still need to be verified, the direction is exactly what enterprise buyers need.

    Why does this matter? AI agents need business context to be useful. An agent that can reason brilliantly but cannot reliably access your CRM, internal knowledge bases, operational systems, or proprietary data is not doing useful work. The data orchestration engine is what connects the model to the context. Without it, you have a powerful system with nothing meaningful to act on.

    Dell’s approach integrates orchestration, search, and governed pipelines natively into the platform. Getting that platform connected to your actual data sources still requires integration work. Budget for it before you buy the hardware.

    AI Infrastructure Is a Team Sport

    The broader lesson from the Dell Technologies keynote is not about any specific product. It is about what has changed in two years.

    When Dell announced the Dell AI Factory with NVIDIA in 2024, it was largely a hardware and partnership story. Today, with 5,000 enterprise customers running production workloads on it, the conversation has shifted to execution. How do you get from pilot to production? How do you keep agents from being blind to your actual business data? How do you manage cost curves as token consumption scales? How do you maintain security and governance when agents are operating autonomously at machine speed?

    Part of Dell’s answer is its ecosystem. The new Dell AI Ecosystem Program gives AI software providers a validated path to certify solutions on Dell infrastructure. For enterprise buyers, this speeds AI deployments by reducing integration some of the integration burden. Rather than assembling a custom stack from scratch, you get pre-validated blueprints that automate the deployment of software, services, and models together. That automation is a direct lever for reducing time-to-token at the program level. Dell claims it can deliver hundreds of AI racks a week to a given customer and have them generating outcomes within hours. Part of this is also achieved with ecosystem partner blueprints for automation. 

    The ecosystem also extends to the agent layer itself. Jensen Huang described on stage how agents do not run directly on the large language model. They run on a harness. The harness sits in a secure, governed container called a sandbox. It manages the agent’s reasoning loop, handles tool use, controls what data and systems the agent can access, and determines when to call the larger model and when to use a smaller local model instead. NVIDIA’s OpenShell is the open-source sandbox now supported across the entire Dell AI Factory. For enterprise buyers evaluating AI infrastructure, the harness is not a detail. It is a primary evaluation criterion. An infrastructure stack that does not clearly define how agent harnesses are deployed, secured, and governed is not production-ready.

    The ecosystem partners Dell named today include Google, Hugging Face, OpenAI, Palantir, ServiceNow, and SpaceXAI, among others. AI is not a solo deployment. The strength of the ecosystem around the infrastructure determines how fast you can actually move.

    Michael Dell put the security dimension plainly: “You can’t protect what you can’t see, and you can’t manage what you can’t see.” That applies to agents as much as it applies to data. Agents have credentials, memory, and access to systems. When they operate autonomously at machine speed, the blast radius of a security failure is no longer contained to one system. It can propagate across workflows and infrastructure. There are also tech tools such as X that help with confidential computing. 

    The Token Economics of Hybrid AI

    Sixty-seven percent of AI workloads already run outside the public cloud, on-premises, at the edge, or in co-location environments, according to Dell’s own survey data. Eighty-eight percent of organizations are running at least one AI workload on-premises. But, that does not mean cloud is going away. It means the real question for enterprise infrastructure leaders is not cloud versus on-premises. It is how to run both well.

    Hybrid AI is not a compromise. It is the architectural reality for most large enterprises. Some workloads need the cloud, which offers speed, training, high capacity, and flexibility. Others belong on-premises because it may access sensitive data that a company doesn’t want in the cloud or regulations require to be in a certain place. There may also be high-volume, continuous inference, where unpredictable cloud token costs create real budget exposure. The strategic challenge is matching the workload to the right environment and doing it consistently at scale.

    Jensen Huang described on stage why the compute requirements have shifted so dramatically. Agentic systems require 100x to 1,000x more computation than responding to a simple query because the agent has to reason, plan, use tools, evaluate results, and iterate. At that scale of consumption, every infrastructure decision has a direct cost consequence.

    Dell’s answer for high-volume on-premises workloads is what it calls “unmetered intelligence.” The idea is that owning infrastructure converts variable cloud API spend into a fixed infrastructure cost. Dell claims organizations can break even on API costs compared to the public cloud in as little as 3 months with desk-side agentic AI configurations.

    Balancing this correctly requires thinking about four variables simultaneously. Latency measures the time it takes for a system to process a request and return a response. Performance refers to the overall capability, accuracy, and capacity of the AI model to handle complex tasks. Cost is what you pay to get those outputs at the required latency and performance level. Energy is the fourth variable, and it is no longer theoretical. A single rack of NVIDIA Rubin GPUs can draw over 130 kilowatts.

    Granted, the average enterprise won’t be running a rack of Vera Rubin’s, but energy availability is becoming a real constraint regardless of sustainability goals. And if you’re using the cloud, you pay one way or the other for that energy. The right infrastructure solution varies by workload type. The time to token and the cost per token let you compare options on the same terms.

    Sovereign AI Is Becoming a Procurement Reality

    Two years ago, sovereign AI was a concept mostly discussed in European regulatory contexts and by a small number of governments building national AI infrastructure. Today, it shows up in enterprise procurement conversations across regulated and unregulated industries.

    Sovereign AI means the ability to independently develop, deploy, and govern AI systems entirely within an organization’s strategic, legal, and jurisdictional boundaries. For enterprises, this means your data does not leave your environment, your model choices are not constrained by a hyperscaler’s catalog, and your AI outputs are not subject to external policy changes.

    The ecosystem Dell announced is designed to both speed AI deployments and address sovereign AI requirements. Google’s Gemini 3 Flash models running on-premises via Google Distributed Cloud on Dell PowerEdge servers. OpenAI’s Codex is connected to the Dell AI Data Platform for agentic workflows on enterprise data. Palantir’s Foundry and AIP platform is deployed on-premises with Dell ObjectScale and PowerFlex as the data layer. SpaceXAI’s Grok is available in on-premises or hybrid enterprise deployments. Reflection’s open-source frontier models for regulated industries and sovereign entities.

    The pattern is consistent: bring the model to the data rather than the data to the model. For organizations in healthcare, financial services, defense, and government, this is not a preference. It is often a compliance requirement.

    Planning for Hybrid AI

    Today’s AI question is how to architect a hybrid AI solution that aligns with our organization’s specific workloads, data environment, cost constraints, and governance requirements. Some of that runs on-premises. Some runs in the cloud. The mix differs across organizations and will shift as workloads evolve and model costs change.

    The questions worth asking now: What is your time to first token across your most important workloads? What is your cost per token at scale? Does your data orchestration layer connect your proprietary data to the models that need it? How are your agent harnesses deployed and governed? And do you have the security architecture in place before your agents start making autonomous decisions?

    It’s not easy but nothing worthwhile ever is. 

     

  • Dell Shares AI Advances And New Metrics To Evaluate Infrastructure

    Dell Shares AI Advances And New Metrics To Evaluate Infrastructure

    At Dell Technologies World in Las Vegas, Dell Technologies chairman and CEO Michael Dell made a pointed argument to a room full of enterprise technology leaders: the metrics organizations use to evaluate infrastructure are evolving.

    GPU counts, cloud versus on-premises comparisons, and model benchmarks have dominated the conversation. Michael Dell’s day one keynote introduced two additional measures aimed at tying infrastructure decisions to actual outcomes: time to token, which measures how quickly a system processes a request and returns a usable AI output, and cost per token, which measures how cheaply that output is produced at scale.

    “Time to first token is incredibly important with investments of this scale,” Dell said on stage, noting that the company now has 5,000 enterprise customers running production AI workloads on its Dell AI Factory with NVIDIA platform. The figure represents a significant increase from the program’s launch two years ago.

    NVIDIA founder and CEO Jensen Huang, appearing alongside Dell, described why those metrics have taken on new urgency at both its NVIDIA GTC conference and at Dell Technologies World. Agentic AI systems, which reason, plan, and execute tasks autonomously over extended periods, require anywhere from 100 to 1,000 times more computation than a system simply responding to a query. “What took months now takes weeks, what took weeks now takes days, and what takes days now takes hours,” Huang said, describing the productivity transformation already underway at companies running agentic workflows. The demand implications for infrastructure are substantial.

    OpenAI president Greg Brockman echoed the framing independently on X.com the same day, writing that “tokens are rapidly becoming the universal input for solving problems.” The convergence of infrastructure vendors and model providers on the same metrics within weeks of each other signals a broader shift in how enterprise AI spending will be evaluated.

    The Data Problem Underneath the Infrastructure Problem

    One of Dell’s significant AI product announcements centered on a new data orchestration engine in the Dell AI Data Platform, which the company positioned as the missing layer between enterprise data and production-ready AI agents.

    The data orchestration engine is the platform’s intelligent control center. It indexes billions of unstructured files, builds governed data pipelines, and connects them to the models and agents that need them at speeds designed to make agentic workflows viable. Dell claims the updated platform delivers 12 times faster vector indexing, six times faster data querying, and 19 times faster time to first token compared to prior generations. While these claims still need to be validated, the proposed increase in performance is good news for enterprises looking to scale AI.

    The underlying problem the engine addresses is one most large organizations know well. Enterprises are simultaneously preparing existing data for AI use and reengineering the data infrastructure required to support AI workloads at scale. Those two efforts compete for the same resources and skills simultaneously.

    “If your data is siloed, your agents are blind,” Dell said. The statement is a precise description of why many enterprise AI pilots have not reached production. An agent operating without access to an organization’s proprietary data, internal knowledge bases, and operational systems cannot deliver the business context that makes agentic AI useful.

    Dell also announced GPU-accelerated SQL analytics through the Dell Data Analytics Engine, powered by Starburst, delivering up to six times faster query performance on NVIDIA Blackwell GPUs. Bank of America, which already has a partnership with Starburst, NVIDIA, and Dell, is among the institutions expected to use the capability.

    A Broad Ecosystem Built to Reduce Time to Production

    Dell announced a new Dell AI Ecosystem Program alongside a significant expansion of frontier model partnerships, positioning both as mechanisms for reducing the time between infrastructure procurement and production AI deployment.

    On the model side, Dell announced collaborations bringing several major AI providers on-premises to the Dell AI Factory. Google and Dell are collaborating to run Gemini 3 Flash models via Google Distributed Cloud on Dell PowerEdge XE9780 servers, enabling enterprises to run advanced generative AI workloads in a confidential computing environment that meets data residency and sovereignty requirements. OpenAI’s Codex will connect with the Dell AI Data Platform, giving enterprises a path to deploy agentic coding capabilities against their internal codebases, documentation, and business systems. SpaceXAI’s Grok is available in on-premises or hybrid enterprise deployments. Palantir’s Foundry and AIP platform is coming on-premises with its Ontology layer deployed on Dell ObjectScale and PowerFlex, allowing organizations to connect data sources and automate business workflows within their own environment.

    The Dell Enterprise Hub on Hugging Face gives enterprises on-premises access to a curated collection of open-weight models including MiniMax-M2.7, DeepSeek Pro, DeepSeek-V4, GLM 5.1, and Kimi K2.6, optimized for Dell AI Factory infrastructure.

    The Dell AI Ecosystem Program formalizes the partner relationship by providing software providers with a validated path to certify their solutions on Dell infrastructure. For enterprise buyers, the practical benefit is pre-validated deployment blueprints that automate the configuration of a specific software, service, or model, reducing integration work that has historically extended timelines from procurement to production.

    The Agent Harness: An Evaluation Criterion Enterprises Are Not Yet Asking About

    One of the more technically substantive moments in the keynote came from Huang’s description of how agents actually operate in production. Agents, he explained, do not run directly on the large language model. They run on a harness, a software layer that sits in a secure, governed sandbox. The harness manages the agent’s reasoning loop, controls tool access, determines when to call a large external model and when to use a smaller local model, and handles memory and context across multi-step tasks.

    NVIDIA’s OpenShell, the open-source sandbox, is now supported across the entire Dell AI Factory from deskside workstations through PowerEdge data center servers.  Dell also announced support for NVIDIA AIQ i.0 blueprints, which provide tested foundations for deploying multi-agent workflows.

    For CIOs evaluating AI infrastructure, the harness architecture is a meaningful addition to the evaluation checklist. Infrastructure that does not clearly define how agent harnesses are deployed, governed, and secured leaves a significant operational and security gap, particularly as agents acquire credentials, access enterprise systems, and take autonomous actions at machine speed.

    For example, “You can’t protect what you can’t see, and you can’t manage what you can’t see,” Dell said, framing the security challenge in terms that apply as directly to agents as to human users. An agent with compromised access or misconfigured permissions can propagate errors or security failures across workflows in ways that a single human user cannot.

    Hybrid AI Infrastructure and the Energy Constraint

    Dell’s survey data shows that 67% of AI workloads are already running outside the public cloud, and 88% of organizations are running at least one AI workload on-premises. The company positioned hybrid AI not as a transitional state but as the long-term architecture reality for most large enterprises.

    The new Dell PowerRack, announced Monday, is a fully integrated rack-scale system that combines compute, networking, and storage, engineered and validated as a single unit. It is designed to reduce the integration overhead of assembling AI infrastructure from components while supporting thermal management and power optimization at rack scale.

    Dell also introduced the Dell PowerCool CDU C7000, the first rack-mount cooling distribution unit designed to meet the cooling requirements of the NVIDIA Vera Rubin NVL72 platform, delivering more than 220 kilowatts of cooling capacity in a 4U form factor. A single rack of NVIDIA Rubin GPUs can draw over 130 kilowatts of power, and Dell noted that energy availability is an increasingly real constraint on AI deployment timelines, independent of sustainability considerations.

    For high-volume on-premises workloads, Dell introduced Dell Deskside Agentic AI, pairing high-performance Dell Pro Precision workstations with NVIDIA NemoClaw. The company claims the configuration enables enterprises to break even against public cloud API costs in as little as 3 months, converting variable token costs into a fixed infrastructure investment.

    What Changes for Enterprise Buyers

    The announcements from Dell Technologies World day one collectively continue to move the enterprise AI infrastructure conversation from capability to faster execution. The core questions are how quickly a given infrastructure configuration can reach first token on a production workload, at what cost per token, and with what governance architecture underpinning the agents running on it.

    The organizations best positioned to answer those questions are the ones that have already started rationalizing their data architecture, defined their hybrid workload placement strategy, and begun evaluating how agent harnesses will be secured and governed. The infrastructure improves almost daily, but the execution discipline required to use it remains the variable that separates AI programs that reach production from those that stay in pilot.

    Maribel Lopez is the founder and principal analyst at Lopez Research, a market research and strategy consulting firm specializing in enterprise AI, AI infrastructure, agentic systems, AI governance, and AI-driven customer experience. I version of this article of originally posted on Forbes.com.

  • Four Types of AI Agents With Dell’s John Roese. Most Enterprises Are Only Building One

    Four Types of AI Agents With Dell’s John Roese. Most Enterprises Are Only Building One

    Dell's CTO built a 4-category agent framework from real production deployments. Most enterprises are ignoring two of the categories that matter most.


    Full Show Notes

    Enterprise leaders are mapping AI agents to org charts — building digital employees, agentic teams, AI workers — and then wondering why the results fall short. Dell's Global CTO John Roese has been running agents in production long enough to know exactly why that framing fails, and what to do instead.

    In this episode, Roese shares a framework Dell developed from actual production deployments, not pilots. It identifies four categories of AI agents defined by two dimensions: how much autonomy you grant the agent, and how complex the underlying process is. Most enterprises are focused on one category. Two of the four are widely overlooked — and they may represent the fastest path to measurable ROI.

    This is a practical, grounded conversation about where agents are actually delivering value today, how to think about infrastructure cost in the context of agent economics, and why the sequence in which you deploy agents matters as much as which agents you build. If your organization is trying to move from AI experimentation to production, this episode is required listening.


    3. Chapter titles:

    • [00:00] — Introduction: Dell's dual role as tech vendor and enterprise AI user
    • [01:38] — Why the org chart model for agents fails
    • [03:12] — Decoupling human capacity from work capacity for the first time
    • [04:23] — The two-by-two framework: autonomy vs. process complexity
    • [06:14] — Productivity agents: what most enterprises already have
    • [07:00] — Hygiene agents: the overlooked category that fixes foundational data problems
    • [08:01] — The CRM data example: why every CRM is inaccurate and how agents fix it
    • [10:05] — Latent infrastructure capacity: running agents in GPU white space to cut costs to cents
    • [13:53] — Facilitation agents: removing entropy from complex cross-functional workflows
    • [17:30] — The sequencing insight: hygiene and facilitation as the path to expert agents
    • [19:24] — Why coordination agents aren't agentic bosses — and where human control actually lives
    • [22:21] — Roese's closing advice: become literate, pick a few, get them into production


    4. Guest Bio

    John Roese is the Global Chief Technology Officer and Chief AI Officer at Dell Technologies, where he is responsible for technology strategy, AI deployment, and research and development across the company. He has held senior technology leadership roles at Nortel, Enterasys Networks, Broadcom, and EMC. At Dell, he operates at a rare intersection: leading AI strategy for a major technology vendor while also deploying AI internally at enterprise scale — which means his frameworks are tested against real production constraints, not just market positioning.


    About This Podcast

    AI with Maribel Lopez is a podcast for enterprise technology leaders navigating AI adoption, agentic systems, AI infrastructure, and AI governance. Host Maribel Lopez covers enterprise technology and advises CIOs, CDOs, CMOs, and technology vendors on how to move from AI experimentation to measurable business outcomes. New episodes published bi-weekly.

    Subscribe on your platform of choice: buzzsprout.com/1947446

  • AI Has A Business Context Problem.

    AI Has A Business Context Problem.

    Data quality and availability must be fixed. But Agentic AI also requires a connection to business context.

    Ask most enterprise technology leaders about their biggest obstacle to AI, and the answer is data. The data isn’t clean enough, accessible enough, or consistent enough to feed AI with confidence. They’re right. Data quality and availability remain the number one challenge Lopez Research hears from enterprises deploying AI.

    But fixing the existing data problem alone won’t get you there. There’s a second data problem that has to be addressed in parallel, and most organizations aren’t thinking about it yet: business context.

    Context is the difference between AI that has data and AI that understands your business. Clean data tells AI what the numbers say. Business context tells AI what they mean — which customers have contractual guarantees, which products are strategic, and what trade-offs are acceptable under pressure. Without it, AI optimizes for the wrong thing, at speed.

    These are not sequential problems. You can’t fix data quality first, then worry about context later. As Irfan Khan, President and Chief Product Officer for SAP Data and Analytics, put it at a recent virtual summit on data and AI strategy: “AI is incredibly good at producing results. It moves fast, but without context, it can’t exercise good judgment, and good judgment is what creates return on investment for the business. Speed without judgment doesn’t help.”

    I attended that summit to understand how enterprise leaders are thinking about both problems — and what changes they decided were required. Three companies shared their experiences: Ericsson, Vodafone, and Google. Their challenges were different. Their conclusions pointed in the same direction.

    Two Problems, One Strategy

    For years, enterprise data strategies focused on a familiar cycle: extract data, land it in a centralized system or dashboard, and run reports. It worked decently, but not great, for analytics. It is not working for AI.

    The first problem — data quality and availability — has always existed. AI makes it more urgent. Models trained or grounded on inaccurate, incomplete, or inconsistent data produce outputs that are inaccurate, incomplete, or inconsistent. Between 60% and 80% of AI budgets go to data preparation, according to various research reports.

    The second problem is less urgent. Traditional data architectures were designed to capture what happened in the past and surface it for human interpretation. AI is different. It acts. An agentic system making autonomous decisions on behalf of the business needs to know more than what the data says. It needs to understand the business’s values, the rules, and the trade-offs. Business context is not something most data architectures were designed to preserve or carry.

    Khan described the stakes with a supply chain example. Two companies both use AI to manage disruptions. The first feeds it raw signals such as inventory levels, lead times, and supplier scores. The second adds context across business processes, policies, and metadata: which products are strategic, which customers need to be prioritized, and what trade-offs are acceptable under pressure. His summary was direct: “Without context, AI doesn’t know this customer is flagged as strategic. It doesn’t know their lifetime value, whether substitutions are allowed, or when to expedite, so it calculates differently, and the decision changes completely. Both systems move very quickly, but only one moves in the right direction.”

    The implication for enterprise leaders is practical. As you work through modernization tasks such as cleaning, consolidating, and governing, data stewards must simultaneously ask how business meaning will travel with that data.

    Ericsson: Built for Analytics, Not for AI

    Malin Persson, CIO and Head of Enterprise IT at Ericsson, described a data architecture that had served the company well for years — and then hit a wall when AI entered the picture.

    Ericsson’s traditional setup had three layers: data creation, data analysis, and analytics. For reporting and dashboards, it worked. For AI, Persson identified three specific points of failure.

    Context was locked inside individual systems. Business meaning — embedded in application-specific models, calculations, and system-specific rules — couldn’t travel across applications. “AI operates across systems,” Persson explained. “When context is trapped inside them, AI can only stitch together partial truths.”

    The architecture was designed to capture the past, not support decisions about the present. AI needs to judge information and take action on the company’s behalf. A system built to explain historical data is not built for that.

    Every AI initiative required rebuilding the same logic from scratch. Without governed data products, each use case started at zero — recreating models, assumptions, and definitions that had already been built elsewhere. “Without data products,” Persson said, “every AI use case required recreating models, logic and assumptions from scratch, which made scaling slow, expensive, and unsustainable.”

    Her summary was blunt: “We did not have a data foundation built for AI.”

    Ericsson’s response was to redesign its data strategy around three shifts: preserving business meaning in a knowledge core, scaling it through governed data products, and connecting it across an open architecture. The approach allows data to stay where it lives, across SAP and non-SAP systems, while business context is managed centrally. Persson described the principle: you define what revenue means, how hierarchies roll up across markets, which rules apply — once, centrally — and that context stays consistent as data moves across platforms.

    The data and context problems were addressed together. That was a deliberate choice.

    Vodafone: Available Data, Inconsistent Meaning

    Ricard Rovira, Head of Corporate IT Platforms at Vodafone, described a common challenge in large enterprises that have grown through mergers and acquisitions: plenty of data, but no shared understanding of what it means.

    As Vodafone expanded across markets, each acquisition brought its own systems, local processes, regulatory requirements, and KPI definitions. The data existed. The problem was that the same business concept was defined differently depending on which system or market you asked.

    The practical consequence was one most enterprise technology leaders will recognize. Teams spent disproportionate time reconciling numbers and explaining why two reports produced different figures, rather than acting on the data. Time to insight stretched. Confidence in the output eroded. End users stopped trusting the systems and started downloading data to build their own versions of the truth.

    The loyalty section of the My Vodafone app made the problem concrete. The same capability was running across five markets with five separate data models, five dashboards, and 40 report pages. Each market had its own reality. There was no shared one.

    The fix wasn’t just cleaner data. It was consistent meaning. Vodafone built a unified semantic layer, which is a single place where business definitions are established once and consistently carried across processes, platforms, and use cases. Rovira described the goal plainly: “Governance is not about control. It’s about preserving the business meaning so it can be reused safely across the enterprise.”

    The company consolidated onto SAP Datasphere and Business Data Cloud, reducing its data footprint by 80 percent on its first Business Warehouse instance. The shift moved teams from reassembling data repeatedly to drawing from governed data products that already carry the right definitions and constraints. Time to insight improved. So did confidence in the output.

    Vodafone’s case illustrates a version of the data problem that often goes undiagnosed. The data is available. The data is not inaccurate in the traditional sense. The data’s meaning is inconsistent, which, in itself, is a form of bad data. For AI systems that act on it autonomously, the consequences are worse than a wrong number in a report. Google faced the same core problem. The cause was different.

    Google: The Culture Problem Underneath the Data Problem

    Jannie Affeld, VP of Finance Systems and ERP at Google, described the same symptom Vodafone experienced — the same data carrying different meanings across the organization — but traced it to a different root cause. At Vodafone, fragmented meaning arose from mergers and acquisitions, with incompatible systems layered over time. At Google, it came from its innovation culture.

    Google operates across more than 200 data centers and offices on six continents, structured by product areas each large enough to function as a standalone global enterprise. The culture has long rewarded individual autonomy within product areas. Teams built their own solutions and defined the same business data differently. The result looked familiar: ten definitions of headcount, multiple approaches to foreign exchange transactions, no single version of the truth that anyone trusted.

    “Technology alone isn’t enough for AI to truly scale,” Affeld said. “Culture must be a significant part of that equation.”

    The data consequence was proliferating definitions. Ten definitions of headcount. Multiple approaches to foreign exchange transactions. When definitions multiply, you don’t have a data quality problem in the traditional sense. You have an alignment problem. And alignment problems do not get fixed by better pipelines or more sophisticated models.

    Affeld described what the fix actually requires: “We actually have to take away some of the access or freedom to create solutions. We’re trying to segregate what is business data from product innovation. We shouldn’t have 10 definitions of headcount in the organization.” Getting there requires sponsorship from both the business side and finance partners — not just a mandate from IT.

    This is a point most data modernization programs underestimate. The data governance conversation tends to focus on architecture and tooling. Google’s experience suggests that the harder work is getting the business to agree on what the data should mean, and then holding that line as teams accustomed to building independently push back.

    For AI, the stakes of this organizational work are higher than they were for analytics. A dashboard with an inconsistent definition of headcount produces a wrong number that a human might catch. An AI agent making workforce decisions based on ten competing definitions produces confidently wrong autonomous actions that are harder to detect and harder to reverse.

    What All Three Companies Have in Common

    Ericsson, Vodafone, and Google came to the AI-readiness problem from different starting points. Ericsson’s challenge was architectural: context locked inside systems, no reusable data products, a foundation built for the past. Vodafone’s challenge was semantic. It had data available everywhere, meaning consistent nowhere. Google’s challenge was cultural: an organization that rewarded independence, producing data that couldn’t be shared with confidence.

    But all three arrived at the same conclusion: fixing the data problem and establishing business context are not sequential steps. They are parallel workstreams.

    You cannot finish cleaning and governing your data and then turn to context. By the time the data is clean, AI deployments are already in motion. Context has to be built into the architecture from the beginning, into how data products are defined, how semantics are governed, and how meaning is preserved as data moves across systems.

    That is a meaningful shift from how most enterprises have approached data modernization. The question is no longer only “how do we make our data more accurate and accessible?” It is “how do we make sure our data carries the business understanding AI needs to act on our behalf?”

    Where to Start

    If you are in the middle of a data modernization program or about to start one, three questions are worth adding to the agenda.

    Are you addressing both problems at once? Data quality and business context are separate challenges that require parallel effort. A data modernization program that focuses only on cleanliness and availability will produce better-quality inputs for AI, but it still lacks the judgment to use them well.

    Where is business meaning living today, and can it travel? In most organizations, meaning is embedded in individual applications. It doesn’t survive when data moves. Identify the definitions, policies, and semantic rules that matter most for AI decision-making and decide how they will be captured and carried consistently. Some firms are calling this a context library.

    Is this a leadership issue or an IT issue? Google’s experience suggests it has to be both. IT can build the architecture. Business leaders have to agree on what the data means and defend those definitions against teams accustomed to building their own. That requires sponsorship, not just tooling.

    More than a decade ago, in my book Right-Time Experiences, I wrote about the importance of context in creating experiences that are adaptive, predictive, and prescriptive. It wasn’t a new concept, but mobility was the catalyst to drive that change. Companies made significant progress, especially as we moved into the early days of machine learning. But very few organizations today can say business context flows coherently across the systems that run their operations.

    Agentic AI has made that gap consequential in a new way. When a human reads a dashboard with missing context, they can compensate for it. When an AI agent acts on data without context, the error compounds automatically, at scale, without a flag.

    Fix the data. Build the context. Do both at the same time.

    Subscribe to my AI Decoded Newsletter here and share with a friend. You can also find the AI with Maribel Lopez podcast on your channel of choice by clicking here.

  • Why Enterprises Need an AI Operating Model | IBM Think 2026

    Why Enterprises Need an AI Operating Model | IBM Think 2026

    Last year produced several sobering research findings on AI’s business value. The McKinsey “State of AI in 2025: Agents, innovation, and transformation” survey found that only 6 percent of organizations are seeing a significant financial impact from AI. Deloitte’s research puts typical payback timelines at two to four years. While the exact numbers vary by study and sector, the pattern is consistent: most enterprises are managing something genuinely difficult. AI is a technology that changes every few months, costs more than projected, and carries real governance and security risks that regulators, boards, and risk teams take seriously. Eighty-eight percent of organizations now use AI in at least one business function. The McKinsey study found that approximately one-third have begun to scale it across the enterprise. No matter what research report you review, including those from Lopez Research, you’ll find the number is less than 50%. The gap between “using AI” and “running the business on AI” is real, and it exists for legitimate reasons — fragmented data, evolving tools, integration complexity, and compliance requirements that don’t pause while the technology moves fast. IBM’s Think 2026 announcements are aimed squarely at that gap. The company is calling its approach an AI Operating Model, comprising four connected systems: agents, data, automation, and hybrid infrastructure. Arvind Krishna, IBM’s Chairman and CEO, framed the urgency directly in the Think 2026 keynote: “The enterprises pulling ahead are not deploying more AI — they’re redesigning how their business operates. Running AI in the enterprise requires a new operating model, and IBM is enabling organizations to manage AI-driven systems with the same rigor, governance, and scale as their most critical infrastructure.” IBM argues that these problems are connected, and solving them one at a time, such as buying a point solution here, running a pilot there, is why many AI programs stall. Yet, companies have told Lopez Research they can’t wait for a complete AI strategy before acting. That tension is real, and IBM is trying to help enterprises navigate it.Here’s what it means for organizations in that position. 

    The Real Reason AI Projects Stay in Pilot Mode

    The standard explanation for slow AI scaling is that organizations aren’t moving fast enough. That framing isn’t fair.Deloitte’s 2025 AI survey of 1,854 executives found that 85 percent of organizations increased AI investment over the past year, and 91 percent plan to increase it again. These are not organizations standing still. They are organizations that have invested heavily and are still waiting for returns that take longer than expected. Deloitte found that most executives expect significant AI payback to take 2 to 4 years — far longer than the 7- to 12-month payback period they expect from traditional technology investments. The reasons are structural, not motivational. Lopez Research discussions found that: 

    • Data hygiene issues persist. Most enterprise data is siloed, static, and inconsistent. AI systems — especially agentic ones that take actions on your behalf — need real-time, reliable data to make decisions you can trust. Lopez Research’s 2025 Enterprise AI Benchmark found that 85 percent of companies were struggling to find AI ROI, with data quality problems the most consistently cited cause. McKinsey’s research reaches the same conclusion: fragmented data and legacy architecture are the most persistent blockers to AI scaling, across industries and company sizes.
    • Governance that hasn’t caught up. Deloitte’s 2026 State of AI report found that only one in five companies has a mature model for governing autonomous AI agents. The Cloud Security Alliance (CSA) puts a finer point on why that matters. In its December 2025 CSA study, only 1 quarter of organizations reported having comprehensive AI security governance in place. Companies with governance policies were twice as confident in their ability to protect AI systems.  Governance isn’t just a compliance exercise. It’s the factor most strongly correlated with successful AI adoption.
    • Security exposure is growing faster than most organizations realize. The Cloud Security Alliance’s April 2026 survey of 418 IT and security professionals found that 82 percent of organizations have unknown AI agents running in their IT infrastructure — agents deployed by employees or teams without central visibility. Sixty-five percent have experienced an AI agent-related security incident in the past twelve months, with consequences including data exposure (61%), operational disruption (43%), and financial losses (35%). This isn’t a theoretical risk. It’s happening now, in organizations that believe they have reasonable visibility into their AI deployments.
    • Integration debt continues to escalate. McKinsey projects that IT infrastructure costs will increase by two to three times by 2030 as AI workloads expand, while budgets remain flat. Organizations are being asked to adopt new tools on top of existing tools that were already expensive to operate and difficult to connect.

    These are structural constraints, not capability gaps. IBM’s AI Operating Model is designed around them. 

    What IBM Announced and What It Solves

    IBM defines the AI Operating Model as the system by which enterprises move from fragmented AI experimentation to AI that runs the business. Where most technology vendors frame AI adoption as a capability question — which models, which tools, which platforms — IBM frames it as an operational question: how do you connect intelligence, action, operations, and trust into a system that functions at enterprise scale? The four pillars are designed to be sequential. Intelligence comes first, because AI amplifies whatever data foundation it sits on — fragmented data produces fragmented decisions, faster. Actions follow, because insight without the ability to act is observation, not transformation. Operations addresses the scale problem: individual AI actions become valuable only when they can run across thousands of systems and decisions simultaneously. Trust closes the loop, allowing an action to be audited and explained. Rob Thomas, IBM’s Senior Vice President, Software and Chief Commercial Officer, frames the progression not as a linear journey but as a zigzag — organizations will move two steps forward and one step back — with the meaningful milestone being the transition from isolated pilots, to connected projects, to a program where AI is embedded in daily operations. IBM is addressing multiple specific problems that enterprise buyers have told it matter most. 

    Giving developers an AI partner that understands enterprise constraints, not just code.

    IBM Bob, now generally available, is an agentic development partner designed to work across the full software development lifecycle — from requirements gathering and architecture planning through code generation, testing, security scanning, and documentation. Bob is not only a code autocomplete tool. Coding assistants can respond to individual prompts, but IBM’s Bob also functions as a persistent team member that reads your organization’s standards, follows your approval gates, and meets the same compliance requirements as any other developer on the team.For organizations running core workloads on mainframes, IBM Bob Premium Package for Z extends these capabilities to IBM Z environments—a detail worth noting for financial services, insurance, and government agencies, where Z infrastructure handles the most sensitive transaction processing. IBM reports that 80,000 of its developers are using Bob, with an average productivity improvement of 45 percent. Those are IBM’s own numbers, but the Dublin development team featured in the keynote reported independently: a 70 percent reduction in onboarding time, 40 percent faster feature implementation, and sprint forecast variance tightening from 35 percent to 15 percent.

    Managing agents you didn’t all build yourself. — and the ones you didn’t know you had.

    IBM watsonx Orchestrate is IBM’s answer to a problem every scaling enterprise will face. AI agents are proliferating faster than the ability to govern them. In most large organizations, agents are already being created across different teams, tools, and frameworks — some built in-house, some embedded in vendor applications, some procured as point solutions. What has been missing is a way to manage that reality without forcing teams to rebuild what they already have. Orchestrate addresses this through an agentic control plane that brings agents into a single operational layer regardless of how they were built or where they run. Today, that includes IBM native agents, LangGraph agents, Langflow agents, and agents built on the open A2A protocol, with broader interoperability planned. Beyond connectivity, Orchestrate adds observability and tracing across agent interactions, build-time, and runtime evaluation. It adds a governed catalog, which is a centralized registry of agents and tools with performance metrics, certification workflows, and lifecycle management. The catalog allows organizations to see which agents exist and assess their trustworthiness. The positioning is deliberate. IBM is not leading with agent-building tooling. The argument is that enterprises don’t need another way to build agents — they need a way to operationalize the ones they’ve already built. As organizations scale from a handful of AI agents to dozens, hundreds, or thousands, built by different teams on different platforms, the governance problem grows faster than the deployment problem. Orchestrate is designed to enforce policy, log actions, and provide accountability across agents regardless of which vendor produced them. This matters because the agent governance gap is already visible in breach data, not just survey responses. Having a place to see what agents are doing, what they’re accessing, and whether they’re operating within sanctioned boundaries is a reasonable requirement before deploying them in consequential workflows. The 82 percent unknown-agent figure from CSA is the risk case for why this capability exists.

    Giving AI access to data that reflects what’s happening now.

    IBM acquired Confluent and is integrating the company’s Kafka streaming and Flink processing capabilities into watsonx.data. The practical effect: AI systems can act on data that’s current, not data that was accurate several hours ago.Most enterprise AI runs on batch data with snapshots taken at intervals and loaded into a system that the AI then queries. For low-stakes use cases, that’s fine. For AI agents making supply chain decisions, resolving customer service issues, or assessing fraud, the gap between what the data says and what’s actually happening in real time poses real risk. In the keynote, Krishna described the logic directly: “Confluent, which is the data streaming platform used by over 6,500 enterprise clients and 40% of the Fortune 500, brings real-time streaming data into our data foundation. After all, AI agents are only going to be as good as the data they can access.” The Confluent acquisition is recent, so buyers should validate the depth of integration in production scenarios before committing.

    Fixing security vulnerabilities, not just finding them.

    Concert Secure Coder addresses a gap that every enterprise security team lives with. Scanners surface vulnerabilities, and developers don’t always fix them. It’s not because developers don’t care. Developers struggle because fixing a dependency that’s been in production for years requires understanding what else will break. The blast radius of a patch is often unknown, which means the patch doesn’t happen. Concert provides visibility into the dependency chain first, then uses an AI agent to execute the fix, verify the result, and create the pull request. Dinesh Nirmal, SVP of IBM Software, described the Sovereign Core design philosophy in terms that apply equally here: “AI has made sovereignty a runtime requirement, not a policy statement.” The same shift applies to security — from point-in-time scanning to continuous, embedded remediation.

    Giving regulated enterprises a sovereignty foundation they actually control.

    IBM Sovereign Core is a full-stack deployment foundation designed for organizations where data residency, model governance, and operational control are non-negotiable — particularly in Europe, where the EU Sovereignty Framework issued in October 2025 introduced a measurable eight-criteria standard for evaluating sovereignty claims. The distinction from conventional approaches is meaningful: most vendor-sovereignty offerings stop at contracts, data-residency commitments, and policy documentation. Sovereign Core goes further — the control plane, secrets, keys, identity, and access all stay within the customer’s environment boundary, and the customer decides what runs inside it. It ships with 160 compliance frameworks out of the box, continuously monitored and automatically verified, with proof generated at the ready rather than reconstructed at audit time. It is also explicitly architected for replaceability. A customer can retain a credible exit strategy rather than trading one form of dependency for another. For organizations in heavily regulated industries — financial services, healthcare, government — Sovereign Core is positioned as the answer to whether a company can adopt AI at scale without surrendering operational control. But the harder problem is the accountability gap. Governance frameworks from NIST AI RMF and ISO 42001 require explicit accountability lines for AI decisions — specific people with documented oversight responsibilities. In practice, security teams assume compliance owns model monitoring. Compliance assumes security owns it. When an agent makes a consequential error, the question “who approved that decision?” often generates no clear answer. 

    What’s Still Hard

    IBM’s portfolio addresses structural problems, but structural problems don’t resolve quickly. For example: 

    1. Observability consolidation takes time. Concert’s value proposition — currently in public preview — depends on bringing signals from applications, infrastructure, network, and cost into a single view. Most enterprises already have Datadog, Dynatrace, Splunk, or a combination of these tools handling parts of that job. IBM’s positioning is that Concert doesn’t require replacing those tools. That’s the right framing, but integration depth varies, and the work required to connect existing tooling into a coherent view should be factored into any realistic timeline.
    2. AI infrastructure costs are continuing to rise. Deloitte found that AI is now the fastest-growing line item in corporate technology budgets, with cloud costs rising roughly 19 percent in 2025 for many enterprises. IBM’s GPU-accelerated Presto capability, co-developed with NVIDIA and currently in private preview, aims to reduce data processing costs. IBM cites 83 percent cost savings and a 30x price-performance improvement from a proof-of-concept with Nestlé spanning 186 countries. That reference is credible, but a proof-of-concept in one environment is not a production benchmark. Test against your own data before treating it as a baseline expectation. General availability is targeted for later in 2026.
    3. The governance gap isn’t policy — it’s proof. Many, but not all, enterprises have AI governance strategies. For those with governance in place, many are still missing the audit trail that demonstrates it’s working. The EU AI Act comes into full effect on August 2, 2026. High-risk AI systems, such as those that touch employment decisions, essential services, or critical infrastructure, must have conformity assessments completed, human oversight mechanisms operational, and technical documentation ready for regulatory inspection.

    What the Customer Evidence Actually Shows

    IBM’s strongest proof point is internal. Krishna cited $4.5 billion in annualized productivity gains from applying AI and automation across IBM’s own operations — a reported figure in financial filings, not a projection. Eighty thousand IBM developers use Bob, achieving an average productivity improvement of 45 percent. External customer evidence is early but directional. Aramco, whose partnership with IBM dates to 1947, described moving AI from experiments to field-scale operations across upstream, refining, and corporate functions — generating more than $5.2 billion in value from AI executions, with over 50 percent of that coming from production deployments rather than pilots. Elevance Health described investing approximately $1 billion in AI to simplify the healthcare experience for members, providers, and internal staff — using 500 data points to match members with appropriate providers and deploying AI to help members understand their benefits through a virtual assistant. These are meaningful reference points. They also reflect organizations with substantial data infrastructure, technical teams, and leadership commitment already in place. Neither story starts from zero.

    One Thing to Remember

    In the Think 2026 keynote, Krishna drew a historical parallel worth taking seriously. He traced the arc from computing in the 1960s through the internet era of the 1990s and 2000s. In each case, the organizations that redesigned their business model around the new technology pulled decisively ahead of those that used it only at the margins. His assessment of where most enterprises stand today: “Most enterprises run AI at the margin. The core end-to-end processes — how an enterprise makes money, makes decisions — are largely untouched.” That observation is accurate, and the data support it. The organizations making progress with AI are not the ones with the most tools. They are the ones who have connected the right data to the right processes with clear accountability for what happens when AI gets it wrong. IBM is not the only company providing these types of AI strategies. Different vendors have one or more of these aspects; however, it’s good to see that IBM’s portfolio is built to address real enterprise challenges.

  • Harness Engineering, Orchestration, and Compound Agents: The Enterprise AI Vocabulary You Need To Know

    Harness Engineering, Orchestration, and Compound Agents: The Enterprise AI Vocabulary You Need To Know

    Most enterprise AI practitioners are running multiple AI models. The question was never how many models or whether they were open models.  The question that’s harder to answer — and the one that determines whether your AI investments compound or fragment — is which system those models are part of, and what you are actually evaluating when a vendor puts a platform in front of you.

    At NVIDIA‘s GTC, Jensen Huang convened a session with the CEOs of Cursor, Perplexity, LangChain, Reflection AI, Thinking Machines Lab, and several others building at the edges of the AI ecosystem. What they described isn’t a debate about models. It’s a map of how AI systems are being assembled — orchestration layers, agent harnesses, multi-component architectures, and specialized vertical systems that combine foundation models with proprietary data and domain logic. Vendors are no longer selling model access. They’re selling systems. Understanding the components of those systems is what makes the difference between a well-matched procurement decision and an expensive one.

    Here’s the updated map.

    The Model Is a Component. The System Is the Product.

    Jensen Huang opened the session with a distinction worth internalizing: a model can be a technology or not a product. He said that ChatGPT is a product. The model underneath it is a technology that someone assembled into that product.

    This reframe is useful for enterprise buyers evaluating vendor offerings. When a vendor presents an AI platform — whether that’s Perplexity Computer, an agentic desktop assistant designed to function as an autonomous coworker, or a vertical industry system built on top of foundation models — you’re not evaluating the model. You’re evaluating everything assembled around it: how the system connects to your data, what tools it can invoke, how it manages memory and context across tasks, what guardrails constrain its actions, and how it handles the handoff between automated steps and human oversight.

    The model is the engine. The system is the car. And you’re buying the car.

    Michael Truell, CEO of Cursor, added a structural observation that clarifies why vendor evaluation has gotten more complex. For years, he said, there were two groups. There were foundation-model companies that built large general-purpose models and sold API access.  Or application companies that built models into their products or on top of them. Truell argues a third category is now well established — companies that combine the best foundation models available through APIs with their own purpose-built models and proprietary domain knowledge, assembled into a specialized vertical system. It’s not a foundation model or application layer. It’s both, plus the integration work that makes them useful together.

    When you evaluate a vendor in this third category, the question isn’t just which model it runs on. It’s whether the vertical specialization, the data architecture, and the system design match the use cases you’re actually trying to solve.

    What Harness Engineering Is, and Why It’s Now a Discipline

    Harrison Chase, CEO of LangChain, introduced a term that’s worth adding to your vocabulary: harness engineering.

    Harness engineering is the discipline of building reliable, structured environments around AI agents. The agent itself — the model running in a loop, calling tools, taking action — is only part of the system. The harness is everything surrounding it: the workflows, the tool interfaces, the validation loops, the context management strategies, and the memory architecture. It’s what makes the difference between an agent that works in a demo and one that operates reliably in production.

    NOTE: This is one definition of the term. The market is still debating this term, and I will write another specific piece on harness engineering.

    Chase made the point directly: even the closed model labs practice harness engineering constantly. He gave the example of Anthropic’s Claude and Claude Code. A model may be exceptional, but the harness around it — how it connects to file systems, how it manages long tasks, what guardrails constrain its actions — is equally responsible for the results. When enterprise teams underinvest in the harness and focus only on the model, they end up running expensive experiments that don’t scale.

    For technology leaders, this has a direct implication. Technical evaluations that benchmark models against each other without assessing the harness — the orchestration framework, the tooling, the integration architecture — are incomplete. The model is one variable. The harness is where most of the enterprise-specific work lives, and where most of the deployment risk concentrates.

    Multi-Component (Multi-Agent) AI Systems: What the Term Actually Means, and What to Ask

    You will hear vendors use terms like “compound agents,” “multi-agent systems,” and “agentic platforms” to describe their offerings. These terms are not interchangeable, and the market has not settled on consistent definitions. That ambiguity is worth understanding before you evaluate vendor claims.

    The most rigorous current framing comes from UC Berkeley’s Sky Lab, which defines a compound AI system as one that combines multiple AI components — models, retrievers, tools, databases, external APIs — to complete a task, rather than relying on a single model call. The system’s behavior emerges from how those components interact, not from any one of them individually. This framing has practical logic behind it: composing specialized components often outperforms a single frontier model on both capability and cost, particularly for complex multi-step tasks.

    Where it gets murkier is in how vendors apply the label. “Compound agent” in active use can mean three different things: a compound AI system that takes actions rather than just generating output; multiple discrete agents collaborating, each with its own reasoning loop; or an orchestrator-and-subagent architecture in which a controlling agent decomposes tasks and delegates them to specialized agents. These have meaningfully different architecture, cost, and governance implications. A vendor calling their product a “compound agent platform” may mean any of the three. The label alone tells you nothing about the actual design.

    The governance implication is the one most enterprise buyers miss. Multi-component systems diffuse accountability. When a consequential decision emerges from the interaction of a retriever, a reasoning model, and a tool execution layer, which component is responsible for the output? Traditional audit trails track the system’s final action. They often don’t track which component drove the decision that led to it. Before deploying any multi-component AI system in a business-critical workflow, buyers should require component-level architecture disclosure and confirm that audit logging covers component interactions, not just system outputs.

    The practical posture: treat “compound,” “agentic,” and “multi-agent” as marketing descriptors until a vendor discloses their specific component architecture. Ask what components the system includes, how they interact, how failures in individual components surface, and where in the stack governance and audit trails are enforced. Those answers will tell you far more than the product label.

    Orchestration Is the New Core Infrastructure

    Arvind Srinivas, CEO of Perplexity, described what his company calls Perplexity Computer: a multi-model, multi-cloud orchestration system where the models themselves become tools, and the orchestration layer determines which tool to apply to which task. The goal is that an enterprise can delegate a goal without specifying which model handles each step — the system manages that routing. Here is another take he gave on the topic in February.

    The analogy he offered is useful for enterprise framing: sub-agents are musicians, models are instruments, and the orchestration system is what produces the symphony. The quality of the output depends on all three, not just the instruments.

    The practical translation: the orchestration layer is where the strategic architecture decisions live. It determines which models get used for which tasks, how context is managed across long-running workflows, where governance and guardrails are enforced, and how exposed you are to vendor dependency. If your orchestration layer is tightly coupled to a single model provider, every future model decision becomes a migration project. If it’s designed to be model-agnostic, you preserve optionality as the model market continues to evolve rapidly.

    Mira Murati, CEO of Thinking Machines Lab, added a related dimension. Her firm has focused on making post-training — the layer of model development that adapts a foundation model to specific domains and tasks — accessible to enterprises and researchers. Most enterprise AI value doesn’t come from a raw pre-trained model. It comes from a model tailored to your domain, data, and task requirements. Accessible post-training means more organizations can build the specialized models that multi-component architectures require, without depending entirely on what general-purpose foundation models provide out of the box.

    What to Do Before Your Next AI System Decision

    The architecture described in this conversation isn’t on a roadmap. Cursor, LangChain, Perplexity, Mistral, and Thinking Machines Lab are all in production with enterprise customers today. The market has already moved.

    Three things worth doing before your next AI procurement decision:

    Evaluate the system, not just the model. Ask vendors to show you the harness — the orchestration framework, the tool interfaces, the memory architecture, the governance layer — not just model benchmark scores. You’re buying the system. Evaluate it as one.

    Require component-level architecture disclosure. When a vendor describes their offering as a compound agent, an agentic platform, or a multi-agent system, ask them to specify the components the system includes and how they interact. The label is not a specification. The architecture is.

    Treat orchestration as strategic infrastructure. The orchestration layer is where vendor dependencies are created or avoided, where governance is enforced or bypassed, and where the long-term flexibility of your AI architecture resides. It deserves the same scrutiny as your data infrastructure decisions. Evaluate orchestration before you’re locked into a system that makes changing it painful.

    The model was never the moat, but perhaps the system is. Knowing how to evaluate the totality of an AI system is what separates a well-matched AI investment from an expensive lesson.

  • AI Success Requires Redesigning the Future of Work

    AI Success Requires Redesigning the Future of Work

    Cisco’s Systematic Approach to Redesigning Processes for the Future of Work Offers a Blueprint for Enterprise Leaders Struggling with AI ROI

    Originally posted in the March 6, 2026 “AI Decoded With Maribel Lopez” LinkedIN newsletter that discusses AI and the future of work for enterprise leaders. 

    Most enterprises are layering AI tools on top of broken processes and wondering why the ROI never materializes. Cisco took a different approach. Instead of adding more tools to existing workflows, Cisco built a methodology for redesigning work from the ground up. The results from its initial pilot suggest that approximately 60% of workflow activities can be AI-augmented. But the more important finding is what had to happen before any of that augmentation delivered value: the work itself had to be re-architected.

    This mirrors a pattern I’ve seen repeat across mobile, cloud, and now AI adoption. Organizations that treat new technology as a layer on top of existing operations get incremental gains at best. Organizations that redesign how work gets done around the technology’s capabilities capture the real value. Cisco’s approach is worth studying because it offers a replicable model for making that shift.

    See the Work Before You Redesign It

    Cisco created Atlas, an AI agent system that analyzes jobs and workflows to build an enterprise-wide map of how work actually gets done. Atlas cataloged approximately 4,000 entities and 25,000 relationships across job roles, activities, and tools. For each activity, the system identifies which AI tools can augment the work and suggests how roles may evolve.

    The most useful insight wasn’t about AI at all. Atlas revealed that roughly 75% of project management tasks are identical across IT, operations, and software development. Without that visibility, each department would redesign independently, duplicating effort and missing opportunities to reuse what works.

    This is the step most organizations skip. They deploy AI tools without understanding how work is actually performed across the enterprise. Pattern recognition across functions prevents waste and ensures that successful redesign approaches can be applied broadly. You can’t redesign what you can’t see.

    Give Leaders a Redesign Tool, Not Just an AI Tool

    Cisco paired Atlas with a digital workflow canvas that translates analytical insights into an actionable design interface. Leaders can see their current workflows, drag in available AI tools, reconfigure roles, and deploy new agents or assistants. When a leader saves a redesigned scenario, the system calculates the percentage of work now AI-augmented, estimates efficiency or growth gains, and produces an implementation plan.

    This matters because workflow redesign requires structured methodology, not ad hoc experimentation. A formal design interface forces leaders to make explicit tradeoffs between efficiency, growth, role changes, and tooling investments. Most organizations lack this discipline. They experiment with AI tools in isolation, resulting in tool sprawl rather than transformation.

    Gianpaolo Barozzi, VP and Chief Innovation and Technology Officer for Cisco’s People, Policy & Purpose Organization, put it directly: “Let’s pause and let’s not just keep layering on more AI agents or tools. Let’s actually reengineer the workflow and understand what the use cases that are in flight.”

    That’s a message every enterprise leader needs to hear. Proliferation of AI tools without process redesign creates complexity, not value.

    What Cisco’s Pilot Actually Proved

    Cisco tested the methodology with its People, Policy, and Purpose (3P) organization. The pilot identified 28 transformational use cases and found that approximately 60% of workflow activities could be AI-augmented. Cisco is now expanding the approach to Product, Engineering, and Strategy organizations.

    The deliberate balance between efficiency gains and growth opportunities is worth noting. Cisco explicitly avoided framing AI as a headcount reduction play. Instead, it positioned augmentation as enabling existing teams to expand scope or improve quality. This distinction matters for adoption. Teams that believe AI exists to eliminate their jobs will resist it. Teams that see AI as a way to do more meaningful work will embrace it.

    This is consistent with what I see across enterprise AI deployments. The organizations getting measurable ROI from AI are not the ones deploying the most tools. They are the ones redesigning processes around specific, scoped use cases and measuring outcomes against defined business KPIs.

    The Leadership and Talent Shift Most Companies Miss

    Cisco is repositioning workflow redesign as a core leadership competency, not a delegated HR or IT responsibility. Fran Katsoudas, EVP and Chief People, Policy & Purpose Officer, described the shift: “It’s a leadership and a cultural change that has to happen, not just a talent change. Leaders need to lead change, embrace AI and reinvent their work.”

    On the talent side, Cisco is revising its systems to identify AI explorers, employees demonstrating high AI adoption. AI tool usage data now informs engagement assessments, promotion prioritization, and career acceleration. AI proficiency is being treated not as a secondary skill but as a primary indicator of adaptability and future leadership potential.

    Both moves are significant. Without visible leadership commitment, workflow redesign initiatives get treated as HR programs rather than strategic transformation. And if AI proficiency is strategically important but not formally recognized in performance management, you’re asking employees to change behavior without aligning incentives. That rarely works.

    What Enterprise Leaders Should Do

    Cisco’s approach reinforces a principle that applies to every enterprise AI deployment: tools alone don’t transform work. Redesigned workflows, combined with leadership commitment and updated talent practices, do.

    Three actions to take now:

    • Map your workflows before deploying more AI tools. You can’t redesign what you don’t understand. Build visibility into how work is actually performed across functions and identify where the overlaps and redundancies live.
    • Make workflow redesign a leadership responsibility. If AI transformation is delegated to middle management or treated as an IT project, it will be seen as tactical rather than strategic. Leaders must own the redesign.
    • Align talent systems with AI priorities. If you want employees to adopt AI, recognize and reward the ones who do. Update performance management, promotion criteria, and retention strategies to reflect AI proficiency as a core competency.

    The question for most enterprises isn’t whether to adopt AI. It’s whether they’re willing to do the harder work of redesigning how their organizations operate. The technology exists. The use cases are proven. What’s missing is the organizational discipline to redesign workflows before deploying more tools. Start there.

    Also, don’t forget to subscribe to the AI with Maribel Lopez podcast on your channel of choice here and the LinkedIn newsletter here.

  • Amazon Connect Is Now a Family of Products That Adds Agentic AI to CX, HCM, Supply Chain and Healthcare

    Amazon Connect Is Now a Family of Products That Adds Agentic AI to CX, HCM, Supply Chain and Healthcare

    AWS is betting that Amazon Connect agentic AI belongs in supply chain, hiring, and healthcare — not just customer service. The branding is smart. Here’s my quick take. 

    For years, Amazon Connect meant one thing: contact center software. As of this week, it means four products, three new markets, and a bet that agentic AI is ready to run business operations — not just answer customer calls.

    At its “What’s Next with AWS” event, Amazon Web Services announced the expansion of the Amazon Connect name into a family of agentic business solutions. The original contact center product is now called Amazon Connect Customer. Three new products join it: Amazon Connect Decisions (supply chain and demand planning), Amazon Connect Talent (high-volume hiring), and Amazon Connect Health (clinical documentation and patient coordination). All four products sit under the Connect name. All four are agentic by design.

    The naming will raise eyebrows — more on that shortly. But the strategic logic is sound, and enterprise buyers should pay attention.

    What “Agentic by Design” Actually Means Here

    It’s worth being precise about what makes these products different from the AI-infused software most enterprises already live with.

    Agentic AI doesn’t just surface recommendations. It plans a sequence of actions, executes them, monitors the results, and adjusts. The word “connect” is doing double duty in this brand: it references both the product family name and the agents’ actual function — connecting to your systems, your data, and your workflows to get something done without waiting for a human to click “approve” at every step.

    The original Amazon Connect spent the last year being rebuilt on this principle. In 2025, AWS introduced what it called “next generation connect” — adding AI across the full customer journey, not just within a single interaction. Sentiment analysis, agent assist, post-call wrap-up, outbound communication, and full transcription all came along. The shift from the original Connect to Connect Customer is a shift from AI as a feature to AI as the operating model.

    The three new products start from that same premise, except they aren’t retrofits. They were built from scratch for agentic execution.

    Three Reasons the Benefits Case Is Credible

    Vendor AI announcements are easy to be skeptical of. This one has a few things working in its favor.

    Scale. Amazon Connect Customer handled 20 million interactions per day and processed 12 billion AI-powered minutes of conversation last year. That’s not a pilot. The new products are built on the same infrastructure. For enterprise buyers who have watched AI proofs of concept collapse under production load, operational scale at this level is a legitimate differentiator.

    Domain expertise embedded in the product. Amazon didn’t hire supply chain consultants to build Connect Decisions. It extracted the models and decision frameworks from its own retail and logistics operations — systems managing demand planning across more than 400 million SKUs. Connect Talent draws from Amazon’s process for hiring 250,000 seasonal workers in a single season. Connect Health is built on the clinical AI running at One Medical, which has now processed more than one million ambient documentation visits. This is proprietary operational knowledge baked into the product, not a general-purpose LLM applied to a new domain. That distinction matters for buyers evaluating whether a product will actually understand their problem.

    Integration with existing AWS infrastructure. For organizations already running on AWS, these products inherit the identity management, access controls, audit logging, and compliance certifications already in place. Buyers don’t start from zero on security posture or governance. That’s a real reduction in implementation risk, particularly in regulated industries like healthcare and financial services.

    On the Branding: Confusing Short-Term, Coherent Long-Term

    The name “Amazon Connect” has strong recognition in the enterprise market specifically as a contact center product. Adding supply chain, hiring, and healthcare products under the same name will require education.

    That said, the decision is defensible. The Connect products share a common architecture and a common design philosophy. AWS is calling that philosophy “Humorphism” — building products designed around how humans and AI agents collaborate, rather than how humans use static tools. Agents ask clarifying questions. They capture the reasoning behind manual edits. They improve over time as they learn from user decisions. Every Connect product is designed to work this way.

    The naming creates a coherent category: all Connect products are agentic, all are built on Amazon’s internal operational experience, and all are designed for line-of-business adoption rather than IT-led implementation. That’s a real product strategy, not just a logo change.

    Buyers evaluating these products should simply be explicit in conversations with AWS about which Connect product they mean. In the short term, that’s a small friction. In the long term, a unified family brand is cleaner than four separate product names with no connective tissue.

    The Open Questions That Need Answers

    Pricing is TBD. AWS did not address how these products will be priced or licensed. For supply chain and hiring products competing with established enterprise software, pricing model matters significantly. Per-transaction, per-user, and consumption-based models all create different budget implications. Enterprise buyers should not evaluate these products without getting pricing clarity first.

    The ERP and HCM question is unresolved. Connect Decisions targets supply chain planning. Connect Talent targets high-volume hiring. Both markets have entrenched incumbents — SAP and Oracle on the ERP side, Workday and Oracle HCM on the talent side — that already hold enterprise data and run existing workflows.

    The question isn’t whether Amazon can build better AI. The question is how Connect Decisions and Connect Talent interact with the systems enterprises already have. A few scenarios are possible, and AWS hasn’t clarified which one applies. The existing ERP or HCM system could become a data source that feeds the Connect agents. The incumbent vendor could build its own agents that call Connect products as tools. Or both systems end up running parallel agent workflows that need to be orchestrated together. Each of these plays out differently for buyers in terms of integration complexity, data governance, and total cost of ownership.

    The demos shown at the event depict Connect Decisions and Connect Talent operating as primary systems of action — generating demand plans, running interviews, surfacing candidate assessments. That implies some displacement of existing workflow software, at minimum for the activities these agents handle. Whether that displacement requires wholesale replacement of incumbent systems, or whether it can coexist alongside them, is not clear from what was announced. Buyers who already run SAP or Workday should press AWS specifically on this before evaluating further.

    What to Do With This Information

    If you’re an existing Amazon Connect customer, evaluate what the next-generation Connect Customer capabilities mean for your current deployment before looking at the new products. The AI-across-the-journey architecture is a meaningful shift from the original product, and understanding it fully is the right starting point.

    If you’re in supply chain, high-volume hiring, or healthcare and are currently underserved by your existing software, these products are worth a serious look. The domain expertise and scale credentials are real. Get pricing clarity and understand the integration model before committing.

    If you’re running SAP, Workday, or another incumbent system in these domains, don’t assume this announcement is irrelevant to you. The better question to ask your existing vendor is: what is your agent strategy, and how does it interact with what AWS just announced?

    The question isn’t whether Amazon Connect should be a family of products. The question is whether or how to make your current stack work alongside it.

    Subscribe to my AI with Maribel Lopez podcast on your channel of choice at https://www.buzzsprout.com/194744.

  • Google Splits Its TPU Chip in Two. Here’s Why That Decision Matters for Enterprise Buyers.

    Google Splits Its TPU Chip in Two. Here’s Why That Decision Matters for Enterprise Buyers.

    The AI chip acronym soup of CPUs, GPUs, TPUs, etc., shows how the computing landscape continued to expand and change over the past decade. At Google Cloud Next, the company released two distinct TPUs (Tensor Processing Units) instead of one — TPU-8t, built for training, and TPU-8i, built for inference and the emerging demands of agentic workloads. The launch highlights an architectural decision that reflects how AI workloads are diverging, with real implications for how enterprise buyers should think about AI infrastructure strategy.

    What Google Actually Announced

    During a press and analyst session at Google Cloud Next, Amin Vahdat, Google’s SVP and Chief Technologist for AI Infrastructure, introduced the eighth-generation TPUs — and emphasized the plural intentionally. Vahdat said the two chips were designed from the ground up separately.

    TPU-8t is the training workhorse. Compared to last year’s Ironwood generation, it delivers roughly three times the floating-point compute per pod, twice the network bandwidth per chip, and four times the bandwidth at scale-out — all with approximately the same pod size of 9,600 chips, but with denser, faster interconnects.

    TPU-8i is the inference and agent engine. It quadruples the pod size to 1,152 chips, delivers 10x the FP8 compute, 7x larger HBM memory capacity, and offers bidirectional scale-out bandwidth. The design priority is latency, not just throughput — a meaningful distinction as enterprises move from batch processing toward real-time agentic workloads.

    Vahdat put the pace of progress plainly: “2x, 4x, 8x, 10x all in one year — the rate of progress, the rate of advancement is just stunning.”

    That’s impressive on paper. The more important question for enterprise buyers is what it means for how they plan and procure AI infrastructure.

    The Specialization Signal

    The two-chip decision acknowledges that training and inference have different physics.

    Training is throughput-bound, which means you’re moving enormous amounts of data through interconnected chips in a coordinated, largely predictable batch process. Inference, especially for the new upcoming wave of agentic systems, is latency-bound.  For this use case, chips need to respond in near-real time as agents plan, act, evaluate, and route across multiple tools and workflows.

    To address the latency problem directly, Google and DeepMind collaborated on a new network “boardfly” topology for TPU-8i, designed to reduce the number of hops between any two chips, significantly cutting chip-to-chip latency. As Vahdat described it: “Our default way of connecting them didn’t support latency. It supported bandwidth. What you really care about in the age of agents is latency — the minimum time it takes to get the data.”

    This mirrors a trend Jensen Huang surfaced at NVIDIA, where chip-to-chip connectivity is increasingly central to total system performance, not just an afterthought to compute specs. The implication: network topology is now a first-class variable in AI infrastructure design, not just chip count or memory.

    Vahdat was direct about the broader trajectory: “The age of specialization is going to continue.” His prediction for the industry — not just Google — is that workloads will continue diverging, and two chips may eventually become more. General-purpose improvements, he noted, are now yielding roughly 5% annual performance gains normalized to cost. Specialization is how you get past that ceiling.

    What This Means for Enterprise Buyers

    Enterprise buyers don’t purchase TPUs. They consume AI services through public cloud, SaaS platforms running on cloud infrastructure, and increasingly through hybrid architectures spanning on-premises and cloud. There are at least three reasons why a chip announcement matters.

    1. AI infrastructure costs are becoming a material business decision. Google is running AI inference on TPUs across Search, YouTube, Gmail, and its enterprise Gemini services. The efficiency of that infrastructure directly affects the cost structure of AI-powered services. When Google cuts inference costs through better hardware, the economics of running AI at scale improve for Google and for its cloud customers. Citadel Securities, the securities trading firm, was cited as a TPU customer that reduced costs 30% and achieved two to four times efficiency improvement on trading systems. Specialized hardware scales well beyond its original design targets.
    2. Inference is where AI delivers the most value to most enterprise buyers. For several years, we’ve been discussing the shift from large-scale frontier model training and enterprise AI fine-tuning towards inferencing. It’s finally here, and we have multiple ways to improve inference, including new TPUs designed for inference.  As Vahdat noted, using a historical parallel to web search: the heavy lifting happens in training, but the value is created in serving. “Serving is where the value is created for Gemini enterprise and search, and ads and YouTube.” Enterprise AI budgets and infrastructure roadmaps need to weigh inference infrastructure proportionally to where value is actually produced.
    3. Reliability at scale is still an unsolved problem — and it matters. Vahdat was candid about a challenge the industry rarely advertises: at the scale of tens of thousands of chips working in coordination, at least one chip will fail several times per day. If human intervention is required to detect and recover from failures, the minimum response time is 30 minutes — enough to halt progress entirely. Google’s approach delivers over 97% of good computational throughput, enabling failures to be automatically detected and remediated. Still, Google Cloud said enterprises aren’t interested in any failure. For enterprises evaluating AI infrastructure providers, reliability and observability at scale are now table-stakes questions, not nice-to-haves.

    The Agentic Infrastructure Shift Is Already Here

    A surprising forward-looking element of Vahdat’s remarks was a prediction about CPUs. As agentic systems grow, general-purpose compute will make a comeback — not to replace specialized chips, but to orchestrate them. Agents require sandboxed environments, virtual machines, code execution, and dynamic routing across inference calls. He stated that it’s CPU work.

    Enterprise infrastructure planners should take note: agentic AI isn’t just an inference problem. It’s a systems design problem that spans specialized accelerators, general-purpose compute, network topology, and increasingly, identity and governance layers sitting above the hardware. The companies Google cited as running on TPUs today — from its own consumer services to financial services firms — are already thinking holistically about infrastructure.

    The infrastructure decisions enterprises make now will determine how quickly and cost-effectively they can deploy agentic systems at scale. Building on platforms engineered for latency, reliability, and specialization is a different starting point than building on platforms that aren’t.

    Google Cloud’s eighth-generation TPUs are a signal that the advancement of AI infrastructure is far from over.  

    This article was originally published on Forbes.

  • Managing a Fleet of Thousands of Agents Is the Real Problem. Google Cloud Showed Its Answer.

    Managing a Fleet of Thousands of Agents Is the Real Problem. Google Cloud Showed Its Answer.

    Enterprises spent most of 2025 figuring out what AI agents are and which tools could build them. The conversation in 2026 is different. The question now is how to govern, monitor, and scale fleets of agents across the enterprise — without losing control of what they’re doing or why. That shift was visible at Google Cloud Next. One of the headline announcements — the Gemini Enterprise Agent Platform — is more than a product consolidation. It reflects where the enterprise AI market is actually headed: away from point tools and toward platforms that manage agents at scale, with governance and observability built in rather than bolted on afterward.Here’s what was announced, and more importantly, what it means for enterprise buyers trying to move from individual pilots to production-grade agentic systems.

    What Google Actually Announced

    Google combined both Vertex AI and Agentspace into a single unified offering called the Gemini Enterprise Agent Platform. Vertex was its managed AI development platform, while Agentspace was its enterprise-focused platform for deploying and managing agents across organizational data and applications such as Jira, Salesforce, and Google Workspace. Neither Vertex AI nor Agentspace will exist as standalone products. The new platform combines what each did separately, such as  Vertex AI’s model building and generative AI development capabilities, and Agentspace’s agent deployment, workflow automation, and enterprise application integration. The platform adds new or improved capabilities for orchestration, governance, security, and observability. That last part matters most. On the model side, enterprise buyers now have access to a model garden with more than 200 options. The model garden includes Google’s own Gemini 3.1 Pro, Gemini 3.1 Flash Image, and Lyria 3, alongside third-party models such as Anthropic’s Claude Opus, Sonnet, and Haiku. The breadth is notable. A single platform that spans first-party and third-party models gives enterprises flexibility to match the model to the task — rather than locking into one provider’s output quality for every workload.On the development side, the platform spans from low-code tooling via Agent Studio to a more capable Agent Development Kit for engineering teams. A new graph-based framework organizes agents into networks of sub-agents, allowing enterprises to define reliable logic for how agents collaborate on complex tasks. An Agent Garden provides access to a curated set of agent templates that cover use cases such as code modernization, financial analysis, economic research, and invoice processing. These templates serve as building blocks for multi-agent systems. The operational layer is where the platform makes its clearest argument for enterprise buyers. Agent Runtime delivers sub-second cold starts and supports long-running agents that maintain state for days, backed by a Memory Bank for persistent context.  This allows agents to run more complex tasks. An Agent Gateway provides unified connectivity between agents and tools across environments while enforcing a consistent security policy. Agent Sandbox provides a hardened environment for executing model-generated code and browser-based automation tasks without exposing host systems. And critically, the platform includes Agent Identity and Agent Registry. Every agent — whether built internally or sourced from a third-party partner — carries a trackable identity and operates within defined guardrails. Model Armor protections guard against prompt injection and data leakage. Testing and observability round out the picture. Agent Simulation, Agent Evaluation, and Agent Observability provide execution traces and real-time insight into agent reasoning. Agent Optimizer goes further, automatically clustering real-world failures and suggesting refined system instructions rather than requiring teams to dig through logs manually.

    Why the Consolidation Matters

    Google also announced updates to its Cloud Data Cloud offering, which improves how agents access and interpret enterprise data. Better data grounding means agents work with accurate, current, enterprise-specific information rather than relying on general model knowledge, which hallucinates at rates that make it unsuitable for business-critical decisions. The Gemini Enterprise Agent Platform competes directly with Amazon’s Bedrock AgentCore and Microsoft’s Azure AI Foundry. All three hyperscalers are converging on the same recognition: enterprise buyers don’t need more ways to build a single agent. They need platforms that manage how hundreds or thousands of agents behave, interact, and scale — without requiring a dedicated engineering team to babysit each one. That’s the real shift in 2026. The challenge is no longer proof-of-concept. It’s production life cycle management with security and governance.For enterprises that had already deployed Agentspace, the consolidation raises a practical question: what happens to what you built? Google’s framing suggests continuity rather than migration — existing Agentspace capabilities carry forward into the new platform rather than requiring a rebuild. But enterprises currently running Agentspace workflows should verify specifically how their integrations, agent configurations, and user access models map to the consolidated platform before assuming a seamless transition. Consolidations that look clean on a slide often surface friction in production environments. Ask Google directly what the migration path looks like and what, if anything, requires rework.

    What’s Hard About It

    The technology being ready and your organization being ready are two different things. A few realities worth holding onto as you evaluate this platform. Model flexibility is only valuable when you define what you need for your workloads. Two hundred models in a garden is a resource if you have a framework for selecting among them. Without a clear use-case taxonomy — which tasks require higher accuracy versus lower latency, which workloads require on-premises data handling versus cloud inference — the abundance becomes a selection problem rather than a solution. Agent Identity and Agent Registry are necessary, not sufficient. Registering agents and assigning identities is a prerequisite for governance, not the governance itself. Enterprises still need to define what each agent is authorized to do, under what conditions it escalates to a human, and how they will audit agent behavior over time. The platform provides the infrastructure for those decisions. The decisions still belong to the enterprise. Observability tooling requires someone to act on what it surfaces. Agent Optimizer, which automates the suggestion of improved instructions, is genuinely useful. But organizations still need the operational capacity to evaluate those suggestions, test changes, and maintain accountability for agent behavior in production. Automation reduces the burden; it doesn’t eliminate the need for human judgment. The partner ecosystem is announced, not fully proven. Google named a broad set of integrations and ecosystem partners. As with every hyperscaler launch, the gap between announced partnerships and certified, production-ready integrations takes time to close. Before building production workflows on partner integrations, confirm what is shipping now versus what is on the roadmap.

    What Enterprise Buyers Should Do

    If you are evaluating the Gemini Enterprise Agent Platform — or any hyperscaler agent platform — three questions will tell you more than the demo. First, ask what the platform does when an agent fails. Not how it handles errors gracefully, but what happens when an agent takes a wrong action at scale, across a fleet of similar agents running the same logic. Failure modes at scale differ from those in a pilot. Platforms that offer real-time observability and automated clustering of failure patterns are meaningfully ahead of those that don’t. Second, ask how agent identities integrate with your existing identity and access management infrastructure. If agents need to be registered and governed separately from human users, the platform adds operational overhead. If agent identities extend naturally from your current IAM framework, adoption is faster, and governance is less fragile. Third, ask how data grounding works within your specific data architecture. The value of grounding AI agents in enterprise data depends entirely on the quality and accessibility of that data. If your data is scattered across disconnected systems with inconsistent formats, the grounding layer will struggle regardless of how capable the platform is. Google’s Cloud Data improvements are in the right direction. But no platform substitutes for data readiness on the enterprise side.

    The Broader Signal

    What Google announced at Cloud Next reflects something the enterprise AI market has needed for a while. Enterprise buyers need platforms from credible vendors that treat governance, security, and observability as core features rather than afterthoughts. We spent 2024 and 2025 building agents. The organizations that will succeed in 2026 are the ones that build the management layer around those agents — the identity frameworks, the observability infrastructure, the governance policies that define what agents are allowed to do and what requires human review. The Gemini Enterprise Agent Platform is a serious attempt to deliver that layer. It is not the only attempt. Amazon and Microsoft are building toward the same destination. But the consolidation of Vertex AI and Agentspace into a unified platform with built-in governance and observability signals that Google understands where the real enterprise challenge lies. That’s the right problem to be solving. Whether this platform solves it for your specific environment depends on how well it fits your data architecture, your existing security stack, and your organizational capacity to govern agents in production. 

    Subscribe to my AI with Maribel Lopez podcast on your channel of choice at https://www.buzzsprout.com/194744.Lopez Research is a market research and strategy consulting firm specializing in enterprise AI, AI infrastructure, agentic systems, AI governance, and AI-driven customer experience. Learn more at www.lopezresearch.com.

    Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut elit tellus, luctus nec ullamcorper mattis, pulvinar dapibus leo

  • Scaling AI with Proven Strategies and Frameworks

    Scaling AI with Proven Strategies and Frameworks

    Picking a use case, proving value, and expanding is the standard advice for getting started with AI. For the early stages of AI deployment, this advice is still sound. But at NVIDIA GTC, Cameron Davies, Chief Data Officer of Yum Brands, made the case that scaling AI in a large enterprise requires companies to think differently—and he had the results to back it up.

    Yum Brands is one of the world’s largest restaurant companies with 63,000 locations, processing more than 100 million transactions per day, across 155 countries through 1,500 franchisees. Davies didn’t come to GTC to talk about a pilot. He came to talk about what happens after the pilot, when the real complexity begins.

    His session, “Scaling AI Agents Globally Across Brands, Use Cases, and Restaurants,” wasn’t a product pitch. It was a framework. And it resets the conversation about what it actually takes to put AI into production at scale.

    Stop Thinking in Use Cases. Start Thinking in Skills.

    Over the past two years, enterprises have been plagued by failed AI proofs of concept. The firms that demonstrated returns from AI started with a fairly straightforward approach: identify a use case, build a proof of concept, demonstrate ROI, and expand. Davies challenged that model directly, not because it’s wrong in principle, but because it doesn’t scale.

    “Doing AI in a lab, it’s easy. We’ve all done it before. In fact, the models aren’t the problem anymore… Getting it to work in the lab, getting it to work with a phone call, that wasn’t the hard part. Getting it to scale in a messy, imprecise world, that’s hard.”

    At Yum’s scale, a use-case-first approach produces monolithic agents that are good at one thing in one context and fall apart everywhere else. The company operates over 500 different point-of-sale systems globally. Its menus differ not just across brands but across regions within the same brand. An AI that works perfectly at a Taco Bell in California may not transfer cleanly to a KFC in the UK or a Pizza Hut in India.

    Davies reframed the question. Instead of asking “what use case should we build?”, his team asks “what skills do we need, and how do we make those skills reusable?”

    He described it using a sports analogy: “I could ask you to build me a baseball pitching robot… That’s very different from me saying to my team, I need a throwing machine. This machine doesn’t care what’s in its hand, and it doesn’t care what the target is. It’s just really good at throwing things.”

    The practical implication: Yum built customer-facing agent skills and team productivity agent skills that can be deployed across brands, markets, and use cases — rather than building discrete agents for each problem. The same voice-ordering capability that operates a drive-through in one country can surface in a customer service context in another, because the underlying skill is real-time voice processing, transcription, and translation.

    Scaling AI requires a meaningful shift for large enterprises. It requires more architectural thinking upfront and more coordination between IT and business teams before a single POC is built. But the payoff is a reusable capability layer rather than a growing inventory of one-off AI deployments that each require their own maintenance, integration, and governance.

    You Can’t Scale AI Without a Governance Strategy.

    Davies was unambiguous on this point, and it is worth quoting him directly.

    “If you’re going to do AI, people often ask me, what’s the first thing you do? … It’s governance, because there is no intelligence without governance.”

    He used a vivid example from a colleague, Manoj Saxena, chair of the Responsible AI Institute: “You are all excited about these (AI) agents and what they’re going to do, but you don’t have the right governance in place, so what you’re doing is you’re all building these little Chuckies (from the movie)… in one hand’s a knife and the other hand’s a credit card, and you’re sending him loose into the system and he’s stabbing and swiping, and you don’t know what he’s doing, because you have no agent registries. You have no control.”

    At 100 million transactions per day, the risk profile of an ungoverned AI agent is not theoretical. A bad decision made at machine speed — the wrong menu item, a mishandled order, a brand-damaging interaction — can propagate across thousands of restaurants before anyone catches it. Davies is explicit that governance is not a post-deployment concern. It is the foundation.

    For most enterprise organizations, this is the piece that gets deprioritized. Governance feels like overhead when the pressure is to demonstrate AI value quickly. Davies’ experience suggests the opposite: organizations that skip governance in pursuit of speed end up constrained later, when the complexity of managing ungoverned agents becomes a bigger obstacle than moving slowly would have been.

    The practical starting point is an agent registry that tracks which agents are running, which tools they have access to, what decisions they are authorized to make, and how their outputs are monitored. That discipline doesn’t require a mature AI platform. It requires a decision to treat governance as infrastructure rather than an afterthought.

    The Practical Caveat: This Requires Knowing What You’re Trying to Accomplish

    Davies’ framework works because Yum entered this process with a clear understanding of what they were trying to do and what outcomes they needed to achieve. They have a dedicated data science team. They worked hard to create clean data, expand data sources, and define a platform strategy, and were supported by an executive mandate.

    That context matters. Smaller organizations, or those earlier in their AI journey, should not interpret “don’t think in use cases” as “don’t focus on defining a specific business value.” The opposite is true. Yum’s skill-based approach requires a sophisticated understanding of what capabilities the business needs, how those capabilities connect to customer or operational outcomes, and how the underlying architecture will support reuse.

    Davies described decomposing something as simple as a taco order into a set of discrete tool calls — finding a product, applying a modification, adding it to the cart, and submitting the order. Each of those is a separate decision point, a separate skill. Getting that decomposition right required deep knowledge of Yum’s systems, menus, and the ways customers actually interact with them.

    If you are selecting a specific use case to prove value, that is still sound advice — especially if you are still building organizational confidence in AI or don’t yet have the infrastructure to support a platform approach. The piece of Davies’ advice that applies universally is this: whatever you build, know the outcome you are trying to achieve before you start. The goal and the measurement need to come before the tool selection.

    Davies put it succinctly in his closing guidance: “Build in your measurement from day one. Build it into your systems from day one. Continually measure it and continually talk about the measurement.”

    How Yum Solved the Scaling Problem

    None of this is easy to replicate. Yum has resources, a mature data organization, and an executive mandate that made this approach possible. But the framework Davies laid out is worth capturing — not to copy it, but to understand the decisions behind it.

    Start with governance, not a pilot. Define what agents are allowed to do, how they are registered, and how their behavior is monitored before deploying anything at scale. Governance is infrastructure.

    Build an AI platform, not a collection of POCs. Yum invested in its proprietary platform — Byte — as the connective tissue for its AI work. Davies was direct: “Platforms, not pilots.” The platform enables skills to be reused. Without it, every deployment starts from scratch.

    Design for reusable skills, not one-time use cases. Break capabilities into discrete, transferable components. Each skill should be able to operate in multiple contexts without modification. This requires decomposing workflows into specific decision points and building and training against them rather than against an end-to-end scenario.

    Use synthetic data to address data gaps. Yum worked with NVIDIA’s Nemo tools to generate over 20,000 training records from limited production data. This allowed them to train small, domain-specific models on the kinds of decisions that matter in their environment — without waiting for years of production data to accumulate.

    Measure continuously and own your data. Davies was emphatic on two points that are easy to underestimate. First, always measure, always share measurements, and never stop. Second, do not give up your data or your orchestration layer to a vendor partner. “No matter who you partner with, don’t give them up. That’s your intellectual property. That’s what matters most.”

    The results Yum reported: a three-times improvement in tool call accuracy over a base model after fine-tuning, 100% function match for complex multi-step orders, and a 20-times reduction in inference cost compared to general-purpose closed models. Those numbers reflect what happens when the architecture, the training approach, and the measurement discipline are all aligned.

    Scaling AI is not just a technology problem. It is a business strategy, architecture, and governance problem that technology enables. The lesson for other organizations is not necessarily to copy Yum’s specific approach — it is to ask the same questions Davies asked before assuming a POC is a strategy.

    Define what your business outcome looks like. Start with governance. Build a platform. Design for reuse. Measure everything.

    A version of this article was originally posted in my AI Decoded with Maribel Lopez newsletter. Subscribe to my LinkedIn Newsletter here.

    Subscribe to my podcast here.

     

  • Three AI Trends That Change Jobs

    Three AI Trends That Change Jobs

     What Sam Altman’s Vision at the Cisco AI Summit Means for Enterprise Workforce Strategy

    By Maribel Lopez

    Cisco builds over 70% of its AI software products using AI. Not on a roadmap. Not as a pilot. Today, in production, through its partnership with OpenAI’s Codex platform. When Jeetu Patel, Cisco’s Chief Product Officer, shared this AI trend at the Cisco AI Summit alongside OpenAI CEO Sam Altman, the audience heard more than a product update. They heard a preview of how labor itself is about to be restructured.

    For CIOs and CEOs rethinking workforce strategy, three shifts from this conversation demand immediate attention: AI that acts on your behalf, the transformation of software development roles, and the emergence of AI-only companies as a new category of outsourced labor.

    Shift 1: AI That Acts on Your Behalf

    AI is crossing from finding information to acting on it. For years, the promise centered on surfacing insights, answering questions, connecting dots across silos. What Altman described is an evolution of the agentic AI trend. He described an always-on AI that accesses your computer, browses the web, edits your documents, and executes tasks without waiting for human approval.

    This shift is already underway. Consumers use OpenClaw’s Clawdbot as a personal assistant, granting it access to everything (risky, but the usefulness is undeniable). On the enterprise side, SaaS vendors are embedding agents into customer service platforms, IT operations workflows, and sales processes where AI doesn’t just recommend an action but completes it. These deployments remain narrow: an agent that resolves a tier-one support ticket, triages security alerts, or drafts and sends a follow-up email after a sales call. But they mark the beginning of a fundamental change in knowledge work. The AI no longer waits for you to act on its suggestion. It acts.

    Altman described giving Codex full access to his computer and lasting only two hours before he couldn’t go back. He acknowledged the real challenges this creates around security, data access, and permissioning. Existing software, hardware, and even legal frameworks weren’t designed for always-on AI that watches what you do and takes action on your behalf.

    For enterprise buyers, this reinforces a message I’ve been sharing for some time: the AI infrastructure conversation extends well beyond models and compute. Identity frameworks, governance stacks, observability, and security architectures all need rethinking, because they were designed for people, not AI agents. The good news is that organizations already investing in these foundational capabilities will absorb AI labor more safely and more quickly. But it requires treating security and governance as enablers of AI adoption, not obstacles to it.

    Shift 2: Software Development Roles Are Being Redefined, Not Eliminated

    Patel described how Cisco works with OpenAI and Codex to fundamentally change how it develops software. AI Defense, a security product Cisco launched last year, will have nearly 100% of its code written by Codex within weeks. This reflects a pattern that will spread across the enterprise.

    Developers aren’t going away, but their job is evolving. The core competency shifts from writing code to constructing precise software requirements, evaluating whether AI output meets those requirements, and articulating what needs to change when it doesn’t. Running tests, writing documentation, producing boilerplate? AI handles that. Defining what the software should accomplish and judging whether it got there? Still human.

    Altman described Codex as feeling less like a tool and more like a teammate: “The Codex app is the first time, to me, it has truly felt like interacting with a teammate.” That distinction matters. When AI shifts from tool to collaborator, the human role shifts from operator to supervisor. CIOs should already be rethinking team composition, performance evaluation, and career development within their engineering organizations.

    Even with AI doing the heavy lifting, design still matters enormously. As Altman noted: “There’s so much value in how you package it, how you have users interact with it, how easy you can make it.” Better models alone don’t guarantee better outcomes. The interface, the workflow, the experience determine whether adoption accelerates or stalls.

    A deeper shift sits underneath this AI trend.  The future of software requires designing it to work equally well whether a human or an AI operates it. That’s not how software works today. Most software isn’t even easy for humans to use, let alone optimized for AI agents. Altman illustrated this with a telling example: his AI agent used Slack on his behalf, marked everything as read, and broke his workflows. Software built for one type of user doesn’t automatically serve another. This is a design problem as much as a technology problem, and product teams and CIOs need to tackle it now.

    Shift 3: AI-Only Companies and the New Workforce Marketplace

    The third shift is the most speculative but potentially the most disruptive. Altman described a future with “full AI companies”: a coding model creates a complete, complex piece of software and also interacts with the real world to build a company around it.

    Consider what that implies. Not AI-assisted companies. AI-only companies: entities with no human employees, just AI systems performing the work. You would hire them the same way you hire a consulting firm or a staffing agency today.

    The concept follows a natural progression from agentic AI. Today, leading enterprises build a variety agents with the aim of having the agents collaborate to accomplish specific goals. Agents perform a task here, an automated workflow there. As agents grow more sophisticated, more of a given role consolidates into a single agentic entity. That entity can then be sold as a digital employee, just as you would hire a temporary worker from an agency or outsourcing firm.

    I can see a marketplace emerging where enterprise buyers source these agents. Today, you acquire them from software vendors and hyperscalers. But nothing prevents a person from building an entirely new AI workforce company. However, it’s probably too soon to call this an AI trend, but I expect we’ll see a variant of this soon. Envision your company hiring a cybersecurity agent from an AI agent company to build new security playbooks. The technology to support this is coming together now.

    But CEOs and CIOs need to understand something: the existence of an agent marketplace doesn’t mean you can just show up and shop. It will be like facing a thousand choices in the cereal aisle. You need to know whether you want hot or cold cereal before you walk into the store, and that’s just the first filter. Cold cereal? Sweet like Fruity Pebbles or plain like Rice Krispies? True success requires knowing exactly what talents your organization lacks and targeting AI to fill those specific gaps. Skip the hard work of defining the skills and roles you actually need, and you’ll end up overwhelmed by options or acquiring agents that don’t solve your real problems. The companies that benefit most from this marketplace will be the ones that mapped their talent gaps first.

    The implications run deep. Outsourcing firms that provide human labor for repeatable tasks face a direct competitive threat and must learn to integrate AI faster and better than their customers do. Companies struggling with persistent talent gaps in cybersecurity, data engineering, or compliance could discover a genuinely new category of solution. But it also raises hard questions about governance, accountability, and quality assurance when the “worker” is an AI system contracted from a third party.

    The Real Shift Is in Software Itself

    All three of these changes point to the same underlying transformation. The question isn’t whether AI will change your workforce. It already has. The question is whether your software, your infrastructure, and your design thinking are ready for a world where AI isn’t just a tool your employees use but a co-worker that uses your software right alongside them.

    Software is changing not just in how it gets developed but in who the user is. When the cloud emerged, companies had to rethink applications for a new delivery model. When mobile took off, they had to redesign for a second screen. AI demands something bigger: a new UX paradigm where humans and AI agents work within the same systems, using the same data, without breaking each other’s workflows. The companies that design for that world will be the ones that capture the value from everything Altman described. Start there. 

  • Four Enterprise AI Spending Pitfalls and How to Avoid Them

    Four Enterprise AI Spending Pitfalls and How to Avoid Them

    By Maribel Lopez, Lopez Research

    A few practical thoughts on where AI spending goes wrong — and what separates the organizations getting it right. Most organizations aren’t failing at AI because the technology doesn’t work. They’re failing because of decisions made before a single model was deployed. Decisions such as how to scope and fund an initiative, what success was supposed to look like, and whether anyone was measuring whether they got there. I recently joined Tom McHale, CFO and VP of Business Operations at SunStream Business Services and Apptio, an IBM company, for a webinar conversation about where spend management goes wrong.   McHale shared how he has navigated technology trade-off decisions as a CFO for years. Our observations converge on the same patterns. Here are the four pitfalls McHale and I spoke about during the session — and what organizations can do about them. 

    Pitfall 1: The Board Issues an AI Mandate Without Funding the Foundation

    Seventy-two percent of companies Lopez Research surveyed had received a directive from their board or senior management to implement AI last year. Most of those mandates arrived without acknowledging the trade-offs required to fulfill them. The pressure is real, and organizations that don’t leverage AI within their apps and services will fall behind. The problem is fixating on the technology without resourcing the operational requirements underneath it. To move into AI effectively, you need data quality, governance, and a clear plan for budgeting for ongoing costs. Boards often ask for AI outcomes without understanding the foundational work it takes to deliver them. There is also a funding gap that sneaks up on organizations. Many companies attempted to fund AI by reallocating from existing cloud or operations budgets. That worked at the margins. It does not work at scale. Internal capital reallocation as the primary AI funding source jumped from 50% to 67% in a single year in Apptio’s 2026 Technology Investment Management Report. At some point, there is not enough money in the couch cushions to do what is being asked. McHale also shared that most management teams expect first-class technology at bargain-basement prices. He brought up the reality many organizations face when he shared an example: you can’t always make trade-offs between technologies, such as funding a batch scheduler in a mainframe environment or investing in AI. You need both. What to do: Before responding to an AI mandate, attempt to map the real cost. That means data preparation, governance infrastructure, security review, and ongoing model costs — not just tool licenses.  Bring that full picture to leadership. The conversation about tradeoffs is easier to have before you start spending than after you have run out of budget. 

    Pitfall 2: Failing to Define Problems and Measurable Outcomes

    In the early days of AI adoption, running experiments made sense. Organizations needed to learn what the technology could do. That phase is over. In 2026, no one should be running an AI proof of concept without a production path and a timeline. In research Lopez Research conducted in mid-2025, 85% of companies said they were struggling to find AI ROI. When we looked at why, three causes kept surfacing. First, there was a data quality problem. Second, the use case was too vague to measure. Third, there were no metrics, monitoring, or observability in place to gauge whether the initiative was working. The fourth issue is that fewer than half of the organizations had a governance strategy, which tends to create downstream compliance and legal exposure. All these solutions are foundational solutions that require time and money. And we didn’t even discuss the cybersecurity concerns, which is always one of the top three technology spending categories. Selecting AI technology solutions before defining what you are trying to accomplish is like buying a full set of hammers, screwdrivers, and impact drivers before knowing what you are building. The tools are not the strategy. What to do: Understand what specific organizational strategic goal or KPI you’re trying to achieve before you start. “Improve customer experience” is too vague. Whereas something specific enough to measure, like reducing billing errors by 80% to improve customer satisfaction, or improving deployable software development velocity by 15%, allows you to understand the impact and the metrics, and provides a set of requirements for AI tool selection. If you cannot define success before you deploy, you are not ready to deploy. Note: I am researching the merits and detriments of an “AI use cases” versus “creating reusable AI skills/capabilities with AI agents”. See the March Newsletter on Yumm Brands for more on this. Given that I don’t yet have solid guidance on how to build and scale reusable AI skills, I maintain that you need to understand which real business problems you need to apply AI to, which helps winnow the platform selection. 

    Pitfall 3: Assuming the Budget You Can See Is the Actual Spend

    Shadow AI is this year’s shadow IT. Every technology wave produces a version of this problem. Employees find tools that help them work faster, stand them up without IT involvement, and pay for them however they can — personal credit cards, discretionary budget lines, expense reports. It adds up quickly and never shows up in the official budget. McHale shared a real example from a prior role. After conducting a full audit of actual spend at a Fortune 500 organization, the actual IT budget was double the official number. Shadow IT had been absorbing that difference for years. With AI tools accessible to anyone with a credit card and a browser, the same dynamic is accelerating. The financial risk is significant. An employee can spend $20 to $300 per month on AI tools, such as ChatGPT and Claude Code. Untracked AI spend scales fast across an organization. But the non-financial risk may be more serious. Unvetted tools accessing company data, unapproved models processing sensitive customer or employee information, and no audit trail if something goes wrong. The governance and security risks posed by shadow AI are not hypothetical. McHale put it well: defining clear objectives at the start, having someone accountable for documenting them, and treating governance as an ongoing discipline rather than a one-time checkbox is what separates organizations that can scale AI from those that cannot. Organizations that lack centralized visibility into AI spend will discover this the hard way. When it comes time to request a budget increase for next year, leadership will ask why more money is needed, given that things seemed to work fine with what was available. The answer — that it was all going on personal credit cards — is not a conversation anyone wants to have. What to do: Treat AI spend tracking as an urgent priority, not a future initiative. Establish a process for centralizing AI tool procurement now, or at least provide guardrails for AI spending. This is not about restricting what employees can use. It is about knowing what is being used, what it costs, and what data it can access. Shadow AI that stays invisible today becomes a budget and compliance problem tomorrow. 

    Pitfall 4: Confusing Operational Maturity with Technical Maturity

    This is one of the more subtle pitfalls, and it trips up organizations that are genuinely sophisticated technically. A company can have strong cloud infrastructure, capable engineering teams, and real AI experience — and still be operationally immature in managing AI investment. The gap is most evident in IT financial management. IBM Apptio’s survey data shows that 59% of ITFM professionals are confident their forecasts are highly accurate. The tools and processes many teams rely on to produce those forecasts were not designed for the pace or variability of AI spend. AI costs scale with usage in ways that are difficult to predict. They appear across every function in the organization. They change as models are updated, as usage grows, and as new capabilities are deployed. Managing that with processes built for a slower-moving environment creates real risk, even when the people running those processes are skilled and confident. Yet the potential visibility gap is where budget surprises live. What to do: Audit your financial management practices against the specific demands of AI spend. Variable usage-based costs, multi-cloud workloads, hybrid AI, and distributed AI tools across business units require practices built for that environment. The goal is not to find fault with what you have been doing. The goal is to identify where the current setup leaves gaps that AI spending will widen. 

    The Pattern Behind the Pitfalls

    These pitfalls are not independent. These pitfalls interconnect. An AI mandate without a real budget forces organizations to fund initiatives on the margins, leading to cuts in data, governance, observability, and security. Without visibility into spend, shadow AI accumulates, and real costs stay invisible. Without defined success metrics, there is no way to know whether cutting those corners mattered. The organizations that are getting AI right did not avoid these problems by being smarter. They avoided them by doing the less exciting work first: defining use cases clearly, understanding true costs before committing, building governance before it was required, and measuring outcomes from day one.While the technology changes,  the adoption challenges remain remarkably consistent. Every wave has its version of the couch cushions problem — organizations moving fast on an exciting new capability without the financial and operational discipline to sustain what they are building. Focus on the foundation first. The shiny AI tools can follow. Subscribe to my LinkedIn newsletter here. Also, you can subscribe to the AI with Maribel Lopez podcast on your channel of choice here.

     

  • The New Rules for Scaling AI: What Yum Brands Learned

    The New Rules for Scaling AI: What Yum Brands Learned

    Picking a use case, proving value, and expanding has been the standard starting point for enterprise AI. For organizations early in their AI journey, that advice still holds. But for large enterprises that are past the pilot stage and trying to scale across business units, geographies, and brands, it isn't enough.

    At NVIDIA GTC, Cameron Davies, Chief Data Officer of Yum Brands, shared how his team is thinking about AI differently — and why they had to. With 63,000 restaurant locations, 100 million daily transactions, and 1,500 franchisees across 155 countries, Yum operates at a scale where a single bad AI decision can fail loudly, repeatedly, and fast.

    In this episode, Maribel breaks down Davies' framework and what it means for how enterprise leaders should be thinking about AI in 2026 and beyond.

    —

    **What you'll learn**

    – Why the use case as a unit of AI planning has a structural limitation at enterprise scale
    – What “scalable AI skills” means and why it's different from building agents for specific use cases
    – Why governance has to come before deployment, not after — and what happens when it doesn't
    – How measurement functions as operational discipline, not just a reporting obligation
    – What Yum's AI flywheel looks like and why it only works if measurement is continuous
    – What this framework means for organizations that aren't Yum-sized

    About Cameron Davies

    Cameron Davies is the Chief Data Officer at Yum Brands, the parent company of KFC, Taco Bell, Pizza Hut, and The Habit Burger Grill. He leads the company's corporate data and analytics strategy and oversees the development and adoption of advanced data capabilities. He previously spent seven years as SVP at NBCUniversal and over 18 years at The Walt Disney Company, where he led the Corporate Center of Excellence for AI and machine learning.

    —

    **Resources and references mentioned**

    -NVIDIA GTC session: “Scaling AI Agents Globally Across Brands, Use Cases, and Restaurants” (S81755) — Cameron Davies, Yum Brands
    – Responsible AI Institute — chaired by Manoj Saxena
    – Trustwise — AI trust startup founded by Manoj Saxena
    – Byte — Yum Brands' proprietary e-commerce, point-of-sale, and menu platform
    – Lopez Research blog: The Rules for Scaling AI Have Changed. Yum Brands Proved It. — [LINK]

    —

    📢 STAY CONNECTED

    Subscribe to the AI with Maribel Lopez audio podcast: https://www.buzzsprout.com/1947446
    Subscribe to my LinkedIn newsletter — AI Decoded with Maribel Lopez: https://www.linkedin.com/newsletters/ai-decoded-with-maribel-lopez-7312533413582827520/
    Lopez Research blog: https://www.lopezresearch.com/research/
    Follow me on LinkedIn: https://www.linkedin.com/in/maribellopez/
    Follow me on X: https://x.com/MaribelLopez

    —

  • Physics AI Explained: Why Hardware Design Requires a Different Kind of AI

    Physics AI Explained: Why Hardware Design Requires a Different Kind of AI

    Not every AI problem is a language problem. I talk with Vinci CEO Hardik Kabaria about what changes when AI has to reason about the physical world.

    Full show notes

    Most of the AI conversation in enterprise circles is about large language models — text, code, maybe images. This episode is about something different: what happens when AI has to reason about physical systems where the laws of physics don't negotiate and a wrong answer can't be patched after the product ships.

    I talked with Hardik Kabaria, CEO of Vinci, about how physics-based AI models are built differently from generative models, why determinism is a requirement rather than a preference in hardware design, and what it means for organizations manufacturing physical products to think carefully about where AI fits in their workflow. The conversation covers data security, scalability, and the practical question of how to evaluate new AI tools when the cost of a mistake is measured in product recalls rather than content edits.

    This episode is most relevant for technology leaders at companies that design or manufacture physical products. But the underlying insight — that deterministic and probabilistic AI serve different purposes and require different evaluation criteria — applies to any organization building a portfolio of AI tools.

    What we cover:

    • Why physics-based AI is a different modality than large language models, and what that means for how you build and evaluate it
    • The case for determinism in AI: why hardware design requires the same answer every time, regardless of who asks
    • How AI is making physics analysis accessible to more engineers, reducing dependence on a small pool of highly specialized talent
    • Why data security requirements are higher for hardware design than for most enterprise AI deployments — and what deployment models address that
    • How to think about AI across the full product lifecycle, from early concept to manufacturing sign-off
    • What “trust but verify” looks like in practice: building benchmarks before deploying AI in high-stakes design workflows

    Timestamps:

    Chapters:
    00:00 Introduction to AI and Vinci
    02:04 Understanding Physics Intelligence Layer
    04:20 The Role of Physics in AI Models
    07:04 Digital Twins and AI Scalability
    09:35 Misconceptions in AI for Physical Systems
    12:15 Determinism vs. Non-Determinism in AI
    15:01 Deployment Challenges for Physics-Based AI
    17:41 Signals of Success in AI Implementation
    20:20 The Future of AI in Hardware Design
    23:01 Preparing for the Shift to AI in Physical Systems

    Guest bio Hardik Kabaria is CEO and co-founder of Vinci, an AI company building foundation models for the physical world. His background is in physics and geometry software for hardware engineering, with experience across the tools mechanical and electrical engineers use to design, simulate, and manufacture physical components. Vinci was founded two and a half years ago and is focused on making physics-based analysis accessible at the speed and scale of AI inference.

    • Company: Vinci

    Resources mentioned:

    📢 STAY CONNECTED

  • NemoClaw, OpenClaw, and the Real Reason Enterprises Haven’t Deployed AI Agents Yet

    NemoClaw, OpenClaw, and the Real Reason Enterprises Haven’t Deployed AI Agents Yet

    

    NVIDIA’s NemoClaw adds enterprise security to OpenClaw. What it does, what it doesn’t, and what CIOs should do before deploying.

    FULL SHOW NOTES

    OpenClaw became the fastest-growing open-source project in history. Enterprise buyers watched from the sidelines — not because the technology wasn’t useful, but because an autonomous agent with access to corporate file systems, credentials, and external communication channels is a governance and security problem that no one had solved at the enterprise level.

    At NVIDIA’s GTC 2026 conference, Jensen Huang announced NemoClaw: a reference stack that adds enterprise security controls to OpenClaw. In this solo episode, Maribel Lopez breaks down what NemoClaw actually does, why the SaaS partner ecosystem matters as much as the technology itself, and where the hype is running ahead of the reality.

    WHAT WE COVER

    •       Why OpenClaw created a shadow IT problem before NemoClaw existed

    •       What OpenShell, the Privacy Router, and Nemotron models actually do for enterprise buyers

    •       Why Salesforce, ServiceNow, SAP, Cisco, and CrowdStrike being in the ecosystem matters

    •       The hardware dependency NVIDIA’s marketing glosses over

    •       Why “working with NVIDIA” and “ready to deploy” are not the same thing

    •       The three questions every CIO should answer before touching any of this

    TIMESTAMPS

    00:00  —  Why enterprise IT teams were watching OpenClaw from the sidelines

    01:45  —  What OpenClaw is and why it created an enterprise security problem

    04:00  —  What NemoClaw actually does: OpenShell, Privacy Router, Nemotron

    06:30  —  The SaaS ecosystem: Salesforce, ServiceNow, SAP, Cisco, CrowdStrike

    08:30  —  Where the hype is ahead of the reality

    10:15  —  Three questions CIOs should answer before deploying

    RESOURCES MENTIONED

    •       NemoClaw announcement and NVIDIA Agent Toolkit: build.nvidia.com

    •       Full written analysis: NemoClaw Brings Enterprise-Grade Security Controls to OpenClaw — lopezresearch.com

    •       NVIDIA GTC 2026 Jensen Huang keynote

    ABOUT THIS PODCAST

    AI with Maribel Lopez covers enterprise AI adoption, agentic systems, AI governance, and AI-driven customer experience. Maribel Lopez is founder and principal analyst at Lopez Research, a technology research and strategy firm.

    Subscribe on Apple Podcasts, Spotify, or your platform of choice here: https://www.buzzsprout.com/1947446

    KEYWORDS

    enterprise AI agents, agentic AI security, NemoClaw NVIDIA, OpenClaw enterprise deployment, AI agent governance, enterprise AI strategy, AI governance enterprise, agentic AI risks

  • Beyond Models and GPUs: Why Enterprise AI Libraries Matter

    Beyond Models and GPUs: Why Enterprise AI Libraries Matter

    By Maribel Lopez

    NVIDIA GTC 2026 Part 2. Everyone is talking about AI hardware and AI models, but companies need more than that to make AI deployable in the enterprise. Let’s talk about enterprise AI libraries.

     Enterprise AI spending has grown eightfold over the past three years. The ambition is real. So is the frustration.

    Ask any CIO who has tried to move a pilot to production, and you’ll hear the same story: the technology worked well enough, but everything around it — the data, the skills, the integration work — took far longer and cost far more than expected. The gap between “we want to use AI” and “we have AI delivering measurable ROI” is where most initiatives stall.

    NVIDIA GTC this week was full of announcements — a new LPU architecture, next-generation inference servers, new models. The hardware gets the headlines. But tucked inside the announcements from both NVIDIA and its infrastructure partners was something that matters as much to enterprise buyers right now as the models: the emergence of AI libraries and validated blueprints as a serious category.

    A briefing with Lenovo on its AI factory and AI libraries brought this to light during the GTC announcements. AI libraries aren’t a new concept, but the category is getting more serious.  Jensen Huang made clear at GTC why that matters.

    The Part of the AI Stack Nobody Talks About Enough

    When most enterprise buyers think about AI investment, they think about two things: hardware and models. Which GPU? Which LLM? These are legitimate questions, but they’re not the only questions that determine whether an AI deployment succeeds.

    At GTC, Jensen Huang made the point directly. Speaking about NVIDIA’s CUDA X libraries, which are domain-specific algorithm libraries that sit between the hardware and the application.  He said:

    “The libraries are the crown jewels of our company. It is what makes it possible for that platform, the computing platform, to be activated in service of solving a problem.”

    He’s describing NVIDIA’s own libraries such as cuDNN, cuOpt (real-time logistics and routing optimization), Parabricks (Genomics Analysis), and many more.  Each one purpose-built for a specific problem domain. But the principle extends beyond NVIDIA. The layer between the hardware and the business outcome is where AI either becomes useful or becomes expensive shelfware.

    Enterprise-grade AI libraries serve the same function at a different level of the stack. They translate validated infrastructure configurations into deployable patterns for specific business problems, such as robotic inspection, customer service agents, and supply chain optimization. They don’t entirely replace data science expertise. They compress the amount of it you need to get started.

    This is an underserved part of the conversation. Infrastructure vendors are competing aggressively on compute specs. Model providers are competing on benchmarks. AI libraries that offer the connective tissue between hardware capability and business outcome — get far less attention than they deserve.

    Why AI Libraries Are Important

    Every analyst (including myself) talks about data as the bottleneck for AI. That’s the first hurdle, but it’s not the only one.

    Most enterprises don’t have enough data scientists. The companies that can hire and retain data scientists at scale are a small fraction of the market. For most organizations, standing up even a well-scoped AI use case requires expertise they don’t have in-house such as the expertise to evaluate which models fit the problem, which infrastructure to run them on, and how to configure the full stack from data ingestion to output.

    A curated, validated AI library addresses this directly. It isn’t a data solution. It’s an expertise solution.

    An AI factory offers the infrastructure layer these libraries sit on top of. It provides the compute, orchestration, and resources to run those use cases. The library tells you what to build and how to configure it. Together, they significantly compress the starting problem.

    Lenovo offers its own AI factory solutions. During a briefing with analysts, Dipak Prasad , who leads hybrid cloud and AI solutions at Lenovo, described the AI Library’s purpose this way: “The AI library is a curated collection of use cases and outcomes that are designed to help customers accelerate their enterprise AI journey. It’s something meant to give them a clear and practical starting point with proven patterns for success.”

    Flynn Maloy , Lenovo’s Chief Marketing Officer for its Infrastructure Solutions Group, framed the buyer need plainly: “They don’t just want to buy the parts. They want to see validated designs. They want to see solutions and outcomes.”

    That’s a real need across the market. Infrastructure vendors building in this direction are responding to the same signal.

    What You Still Need

    To be clear, AI libraries and validated blueprints are a faster on-ramp, not necessarily a complete solution. Three prerequisites remain that no vendor can hand you:

    • Clean, accessible data. Data readiness is still on you. AI outcomes are only as good as what you feed them. Validated blueprints assume data is available and reasonably structured. If your customer data lives in five different systems with inconsistent schemas, that integration work comes first. We’re starting to see some AI factorie address data prepareness, but it’s not universal. A blueprint will help structure your approach, but won’t fix the underlying problem.

    • A governance framework. Roughly half of organizations still don’t have a formal AI governance policy. Deploying production AI — especially in customer-facing or operational contexts — without one creates legal, compliance, and reputational risk that a blueprint can’t manage.

    • Integration planning. Every blueprint connects to your existing systems at some point. The scope of that integration — to your CRM, your ERP, your identity stack — determines actual deployment cost and timeline. It’s rarely trivial.

    Service partnerships help. For example, Lenovo’s expanded collaboration with IBM Technology Lifecycle Services, which will support the deployment and ongoing management of hybrid AI infrastructure in regulated industries. It’s an example of what filling the services gap looks like. But a services partnership expands your support options; it doesn’t substitute for your own operational readiness.

    Early, But Real Outcomes Exist

    One fair critique of AI libraries and validated blueprints at this stage: the evidence base is thin. Most enterprise AI deployments are less than a few years old. Production-grade results with published ROI are still the exception.

    Lenovo references internal deployments — what they call “Lenovo powers Lenovo,” built first to run their own 36 factories and FIFA as an external example of the knowledge super-agent.

    But ‘early’ doesn’t mean there are no results. If we look at AI deployments across industries over the past several years, we see documented real returns. American Express focused on 70 high-impact use cases and saw a 10% increase in developer productivity and a 40% reduction in IT escalations. Cisco applied AI to network management, reducing the time spent on renewals from 40% to under 5%. Walmart used AI to cut inventory waste by 30%. These outcomes came from the same discipline that AI libraries are designed to replicate: a specific problem, a defined scope, foundations built before deployment, and measurement from day one.

    The AI library concept is a mechanism for replicating that pattern without requiring every enterprise to discover it through trial and error. Expect the evidence base to strengthen over the next 18 to 24 months. Companies that start now with well-scoped use cases will be the ones producing it.

    You Have Choices. Start With Your Current Infrastructure Partner.

    Lenovo is not the only infrastructure vendor building in this direction. Dell, HPE, and the major hyperscalers are all developing versions of AI factories with validated software layers and ecosystem programs.

    Dell Technologies‘ AI Factory with NVIDIA wraps validated reference architectures, partner software, and services around comparable infrastructure breadth. Hewlett Packard Enterprise‘s Private Cloud AI combines GreenLake infrastructure with NVIDIA AI Enterprise software. IBM has its own watsonx AI platform and infrastructure stack. The hyperscalers — Amazon Web Services (AWS) , Microsoft Azure, Google Cloud — offer industry-specific AI solution catalogs, primarily cloud-native rather than hybrid.

    The market is moving quickly. Enterprises will have genuine choices, and those choices will vary by infrastructure philosophy, existing vendor relationships, and the specific use cases being targeted.

    The practical starting point: begin your evaluation with whichever vendor already has the most significant footprint in your data center. Not because that vendor necessarily has the best AI library and factory offering because it  may or may not. If your existing vendor has a solid, but perhaps not the best offering, you will have a baseline for your evaluation. With this baseline, you can decide whether the difference in product offerings is worth the pain of switching.

    Three questions to ask any vendor with an AI factory or library offering:

    • Show me a deployed customer in my industry. Not a reference architecture. Not a proof of concept. A production deployment with measurable outcomes and a customer willing to discuss it. If they can’t provide one, treat the offering as early-stage.

    • What do I need to have in place before this works? Push for specifics on data readiness, integration requirements, and governance prerequisites. Vague answers signal the vendor hasn’t worked through enough real deployments to know what breaks.

    • What does the full engagement cost? Blueprints reduce the expertise required to start, but they don’t eliminate service costs. Get the total cost — hardware, software, implementation, ongoing management, etc.

    The use cases are real. The tools are rapidly evolving. Seek out solutions that minimize the execution variable.

     

    Subscribe to the AI with Maribel Lopez podcast on your channel of choice here.

     

  • NemoClaw Gives Enterprise AI Agents The Security Layer They’ve Been Missing

    NemoClaw Gives Enterprise AI Agents The Security Layer They’ve Been Missing

    The NVIDIA GTC announcement of the NemoClaw stack addresses one of the real reasons enterprises haven’t deployed AI agents at scale — and one vendor’s alternative to address those concerns.

    OpenClaw became the fastest-growing open-source project in history while enterprise buyers watched from the sidelines.

    Not because the technology wasn’t interesting. It is. Not because employees weren’t already using it. They were — quietly, on personal machines, sometimes on corporate devices. Enterprises held back because an autonomous AI agent that can access file systems, execute code, log into corporate systems, and communicate externally is not something you hand to 10,000 employees without a security framework underneath it.

    NVIDIA ‘s NemoClaw announcement at GTC 2026 offers one solution to address that gap directly. It is not a competitor to OpenClaw. It is a reference stack that adds the infrastructure layer OpenClaw was missing: policy-based security guardrails, a privacy router, a sandboxed runtime called OpenShell, and integration with the security tools enterprises already use, installed in a single command.

    Jensen Huang put it plainly in his GTC keynote:

    “Agentic systems in the corporate network can have access to sensitive information. They can execute code and communicate externally. You could access employee information, access supply chain, access finance information, and send it out. Obviously, this can’t possibly be allowed.”

    For enterprise buyers, this is the right framing. The question was never whether AI agents would be useful. The question was whether they could be deployed safely inside an enterprise environment. NemoClaw is NVIDIA’s answer to that question for OpenClaw.

    Why OpenClaw Alone Wasn’t Enterprise-Ready

    Before discussing what NemoClaw adds, it is worth clarifying the enterprise IT and security leader’s concerns.

    OpenClaw is designed to act like a digital assistant sitting at your computer. It can view your screen, control your browser, open files, execute commands, and log in to websites. If an employee grants OpenClaw access, it operates the computer the same way the employee would. That means if the employee can access corporate email, CRM systems, internal dashboards, customer data, or finance systems, the tool can access them too.

    The issue is not the AI itself. The issue is how much access the software has and where the data goes afterward. Specific risks enterprises were managing before NemoClaw include:

    • Credential exposure. If OpenClaw interacts with browser sessions or system logins, it can gain access to saved passwords, session tokens, and authentication cookies. This could allow the tool — or anything that compromises it — to impersonate the employee in corporate systems.
    • Data leaving the organization. AI automation tools often send information to external services for processing. That can include screenshots, text from documents, browser content, and system commands. If sensitive enterprise data is transmitted outside approved systems, it may violate GDPR, HIPAA, PCI, or data-residency requirements across multiple jurisdictions.
    • Autonomous actions without audit trails. AI agents can operate autonomously, executing workflows, interacting with websites, and performing transactions without logging. If poorly configured, an agent could send emails, download files, update records, or trigger business workflows without IT or compliance teams having visibility.
    • Shadow IT at scale. Meta instructed employees not to use OpenClaw on work computers due to security concerns. Many companies followed suit. Even so, adoption continued. Prohibition alone does not work when the tool is genuinely useful. Enterprises need a sanctioned, controlled alternative or safeguards— not just a policy.

    What NemoClaw Actually Does

    NemoClaw is not a product. It is a reference stack — an open-source configuration of existing and new NVIDIA tools that installs on top of OpenClaw to add the enterprise infrastructure layer. Here is what each component does:

    1. OpenShell. This is the core of the security layer. OpenShell runs OpenClaw agents in an isolated sandbox that limits what files they can access and restricts network connectivity. Enterprises can write policy rules in YAML to define exactly which systems an agent can access, which data it can process, and which actions require human approval. YAML Ain’t Markup Language (YAML) is a human-friendly, plain-text format used to store data, configure software, or move data between systems. Some rules are hot-swappable, allowing them to be changed without restarting the agent.
    2. Privacy Router. When agents need to call cloud-based frontier models, the Privacy Router ensures sensitive enterprise data is not transmitted to those external models. This is the mechanism that makes hybrid local-cloud architectures viable without creating data residency exposure.
    3. Nemotron Models. NVIDIA’s open model family can run locally on dedicated hardware, including NVIDIA RTX PCs and DGX Station. Running inference locally means sensitive enterprise data stays on-premises for tasks that require it. This also reduces cloud inference costs. NVIDIA reports that its hybrid architecture — using Nemotron for research tasks and frontier models for orchestration — can cut query costs by more than 50 percent.
    4. Single-command installation. This matters more than it sounds. One practical barrier to enterprise AI deployment is configuration complexity. A stack that requires days of professional services to stand up will not achieve broad adoption. NemoClaw installs the entire reference configuration in one command.

    Kari Briski, NVIDIA’s VP of Generative AI Software, described it this way at GTC: OpenShell “provides the missing infrastructure layer beneath claws to give them the access they need to be productive, while enforcing policy-based security, network, and privacy guardrails.”

    That framing is accurate. The productivity value of OpenClaw was never in question. What was missing was the control layer.

    The SaaS Ecosystem Is Already Moving

    For enterprise buyers, the breadth of the partner ecosystem matters as much as the technology itself. You are not just evaluating a security sandbox. You are evaluating whether the tools your teams already use will work within that sandbox.

    The list of software companies integrating with NVIDIA Agent Toolkit and OpenShell includes Adobe, Atlassian, Box, Cisco, CrowdStrike, Red Hat, Salesforce, SAP, ServiceNow, and Siemens. A few specific integrations are worth noting:

    • Cisco‘s AI Defense will provide AI security protection for OpenShell, adding controls and guardrails to govern agent actions. For enterprises already running Cisco security infrastructure, this is a direct integration path.
    • CrowdStrike unveiled a Secure-by-Design AI Blueprint that embeds Falcon platform protection directly into NVIDIA AI agent architectures. Enterprises with CrowdStrike endpoint protection can extend that coverage to AI agents.
    • Salesforce is working with Agent Toolkit to enable customers to build and deploy AI agents through Agentforce for service, sales, and marketing tasks, using Slack as the conversational interface and orchestration layer. This matters because Salesforce and Slack are already inside most enterprises.
    • ServiceNow ’s Autonomous Workforce of AI Specialists is built on Agent Toolkit and includes NVIDIA Nemotron models. ServiceNow is the workflow backbone for IT operations in many large enterprises, which means agentic AI is now moving into ITSM and operational workflows directly.
    • SAP is using Agent Toolkit to enable AI agents through Joule Studio on SAP Business Technology Platform, allowing customers to design agents tailored to specific business processes. For enterprises running SAP as their ERP backbone, this is a direct integration with operational data.

    The pattern here is important. These are not experimental integrations. Salesforce, ServiceNow, and SAP together represent the core of enterprise application infrastructure. When your existing SaaS platforms build their agentic strategies on the same security and identity stack, it significantly reduces the interoperability problem. You are not assembling a security architecture from scratch for every new AI agent. You are extending an existing framework.

    It is also worth noting that NVIDIA is collaborating with Microsoft Security, Google , CrowdStrike, and TrendAI to build OpenShell compatibility with their security tools. The intent is to make OpenShell work within security stacks enterprises already have, not replace them.

    What This Means for CIOs and Enterprise Buyers

    NemoClaw does not eliminate the work required to deploy AI agents safely. It reduces the barrier significantly. Before evaluating whether NemoClaw belongs in your environment, three questions are worth resolving:

    Are employees already using OpenClaw? If the answer is yes — even informally — then the risk exists today. NemoClaw gives you a sanctioned path to bring that activity under enterprise controls rather than competing with shadow IT through prohibition.

    Is your identity framework ready for AI agents? NemoClaw provides the guardrails, but agents still need registered identities and role-based access controls. Most enterprise identity frameworks were designed for people. Before deploying agents at scale, confirm that your identity infrastructure can assign, manage, and revoke agent credentials separately from human credentials.

    Do you have the observability to know if agents are working correctly? OpenShell provides audit logging and network guardrails. That is a starting point, not a complete observability stack. You need monitoring in place to detect when agents are drifting, making errors, or accessing systems they should not.

    The Caveats That Curb My Enthusiasm

    The broader context here matters. Jensen Huang framed the OpenClaw moment as equivalent to the arrival of Linux, HTML, and Kubernetes — foundational infrastructure that reorganized entire industries. That may or may not prove accurate.

    What is accurate is that agentic AI as a category, not just OpenClaw, will fundamentally change enterprise workflow platforms. The companies that define their governance architecture now will be better positioned than those that build it under pressure later.

    It is also worth being realistic about what NemoClaw does not solve. Cross-vendor agent orchestration remains complex. An agent working in Salesforce does not automatically collaborate with an agent in SAP without significant integration work. Governance frameworks for multi-agent systems are still nascent. The tools are improving faster than the enterprise readiness in most organizations.

    Other things to consider. NemoClaw and OpenShell are open source. Anyone can download them. However, to run Nemotron models locally (the privacy-preserving option that keeps data on-premises), you need NVIDIA GPU hardware — an RTX PC, DGX Spark, or DGX Station.

    YAML policy configuration is an IT burden. Enterprises customize OpenShell by writing YAML rules. That’s a developer-friendly approach, not an enterprise admin-friendly one. Large organizations with thousands of use cases will need tooling and staffing to manage that policy layer. This is not point-and-click governance.

    The partner ecosystem is announced, not proven. The list of SaaS partners — Salesforce, SAP, ServiceNow, etc. — represents intent and roadmap, not certified integrations. Most of these are “working with NVIDIA” statements. Before betting enterprise deployments on them, buyers should ask specifically what is shipping, when, and what certification or testing has been completed.

    Start with Governance, Not the Agent

    NemoClaw is genuinely useful for enterprise buyers. It addresses the right problem in the right way — by adding enterprise security controls to an open-source agent platform that employees are already adopting, rather than building a competing proprietary stack.

    The partner ecosystem — particularly Salesforce, ServiceNow, SAP, Cisco, and CrowdStrike — means NemoClaw is not a greenfield deployment for most enterprises. It fits into the existing infrastructure.

    But the technology being ready does not mean you are ready. Before deploying agents in any production environment, define what they are allowed to do, what data they can access, and how you will know when something goes wrong. That work is not optional — and no reference stack does it for you.

    Governance first. Agents second. That is the sequence that works.

    Subscribe to my AI with Maribel Lopez podcast on your channel of choice here.