Model Context Protocol (MCP), the emerging standard for connecting AI models to external tools and enterprise data, is undergoing its biggest architectural overhaul yet.

The latest release candidate, scheduled for release on July 28, removes protocol-level sessions in favor of a stateless architecture, a change which industry experts say is intended to make MCP easier to deploy across standard cloud infrastructure as enterprises move AI pilots into production.

“The session-based model made sense when MCP servers were local processes on a developer’s laptop. In production, it became an operational tax,” said Muskan Bandta, cloud associate at ZopDev.

“When your infrastructure team asks whether MCP services can scale like other cloud applications, the answer used to be ‘not quite.’ With the move to a stateless architecture, the answer is now yes,” Bandta added.

Earlier versions of the protocol maintained information about every client connection, meaning servers had to keep track of each session throughout an interaction. While that approach worked well for local development, it complicated deployments across multiple servers because requests often had to be routed back to the same machine, limiting scalability and making MCP a less natural fit for modern cloud architectures.

“Under the new stateless design, every request contains the information needed for any available server to process it independently. Applications that need to maintain context across multiple requests can still do so, but developers must now manage that state explicitly rather than relying on the protocol itself,” she said.

This transition to a stateless design goes beyond simplifying infrastructure by fundamentally changing how AI applications manage and share context across tools, according to Amit Jena, AI development manager at IT consulting firm Kanerika.

Instead of keeping application state hidden inside protocol sessions, the new design makes it explicit, allowing AI models to access, reason over, and pass that information between tools, giving developers greater control over how context is preserved and shared across tools, Jena said.

It should also make AI workflows more portable, resilient, and easier to orchestrate across distributed environments, he said.

MCP’s new features

Other changes to MCP include the addition of a Multi Round-Trip Requests (MRTR) mechanism that changes how AI agents request additional information they need to complete a task.

Instead of relying on a persistent connection between the client and server throughout the interaction, the new mechanism lets the server request additional input through a standard request-response exchange before continuing the task, Jena said.

Routable transport headers, another addition, enable API gateways and other networking infrastructure to identify and route MCP requests without inspecting their contents.

They reduce processing overhead, lower latency, and let enterprise teams enforce routing, rate-limiting and security policies more efficiently using existing API management infrastructure, Jena said.

MCP is also getting an updated authorization framework built around OAuth 2.1 and OpenID Connect; interactive MCP Apps; and deterministic caching of tool and resource listings to improve LLM prompt-cache hit rates, potentially saving on token costs.

Rebuilding the trust boundary

The MCP release steering committee also decided to deprecate some legacy features, including Roots, Sampling, Logging, the older HTTP+SSE transport and Dynamic Client Registration, although these will continue to work in this version and any other released over the next year.

The deprecation of Sampling is likely to have the biggest impact because it changes who is responsible for interacting with foundation models, said Jena.

“Sampling let MCP servers invoke the LLM through the client, which meant the server had a callback path into the model without owning that connection. Deprecating it means rebuilding that trust boundary,” Jena said. “Your server now calls the model provider directly. That changes your network architecture, your auth model, and depending on how you’ve built cost attribution, your billing flow.”

The year-long transition period will be enough for teams to audit their sampling dependencies now, said Jena: “The risk is that teams who haven’t implemented sampling themselves won’t know if a third-party MCP server they’re depending on uses it.”

Updated MCP SDKs

To accompany the protocol update, there are updated MCP SDKs for Python, Typescript, Go, and C#. These support both the old and new protocol versions, so new clients can continue communicating with older servers, while updated servers will also support older clients, reducing the risk of immediate disruptions.

That backward compatibility should make the transition largely incremental, except for enterprises that built custom infrastructure around MCP’s earlier session-based architecture, Bandta said.

Identifying and auditing those session dependencies may not be easy, Jena warned.

“Session management complexity tends to be hidden across multiple layers — the gateway config, the deployment scripts, the monitoring dashboards. The code change is small; finding everywhere the assumption lives is what takes time,” he said.

This article first appeared on InfoWorld.

Model Context Protocol (MCP), the emerging standard for connecting AI models to external tools and enterprise data, is undergoing its biggest architectural overhaul yet.

The latest release candidate, scheduled for release on July 28, removes protocol-level sessions in favor of a stateless architecture, a change which industry experts say is intended to make MCP easier to deploy across standard cloud infrastructure as enterprises move AI pilots into production.

“The session-based model made sense when MCP servers were local processes on a developer’s laptop. In production, it became an operational tax,” said Muskan Bandta, cloud associate at ZopDev.

“When your infrastructure team asks whether MCP services can scale like other cloud applications, the answer used to be ‘not quite.’ With the move to a stateless architecture, the answer is now yes,” Bandta added.

Earlier versions of the protocol maintained information about every client connection, meaning servers had to keep track of each session throughout an interaction. While that approach worked well for local development, it complicated deployments across multiple servers because requests often had to be routed back to the same machine, limiting scalability and making MCP a less natural fit for modern cloud architectures.

“Under the new stateless design, every request contains the information needed for any available server to process it independently. Applications that need to maintain context across multiple requests can still do so, but developers must now manage that state explicitly rather than relying on the protocol itself,” she said.

This transition to a stateless design goes beyond simplifying infrastructure by fundamentally changing how AI applications manage and share context across tools, according to Amit Jena, AI development manager at IT consulting firm Kanerika.

Instead of keeping application state hidden inside protocol sessions, the new design makes it explicit, allowing AI models to access, reason over, and pass that information between tools, giving developers greater control over how context is preserved and shared across tools, Jena said.

It should also make AI workflows more portable, resilient, and easier to orchestrate across distributed environments, he said.

MCP’s new features

Other changes to MCP include the addition of a Multi Round-Trip Requests (MRTR) mechanism that changes how AI agents request additional information they need to complete a task.

Instead of relying on a persistent connection between the client and server throughout the interaction, the new mechanism lets the server request additional input through a standard request-response exchange before continuing the task, Jena said.

Routable transport headers, another addition, enable API gateways and other networking infrastructure to identify and route MCP requests without inspecting their contents.

They reduce processing overhead, lower latency, and let enterprise teams enforce routing, rate-limiting and security policies more efficiently using existing API management infrastructure, Jena said.

MCP is also getting an updated authorization framework built around OAuth 2.1 and OpenID Connect; interactive MCP Apps; and deterministic caching of tool and resource listings to improve LLM prompt-cache hit rates, potentially saving on token costs.

Rebuilding the trust boundary

The MCP release steering committee also decided to deprecate some legacy features, including Roots, Sampling, Logging, the older HTTP+SSE transport and Dynamic Client Registration, although these will continue to work in this version and any other released over the next year.

The deprecation of Sampling is likely to have the biggest impact because it changes who is responsible for interacting with foundation models, said Jena.

“Sampling let MCP servers invoke the LLM through the client, which meant the server had a callback path into the model without owning that connection. Deprecating it means rebuilding that trust boundary,” Jena said. “Your server now calls the model provider directly. That changes your network architecture, your auth model, and depending on how you’ve built cost attribution, your billing flow.”

The year-long transition period will be enough for teams to audit their sampling dependencies now, said Jena: “The risk is that teams who haven’t implemented sampling themselves won’t know if a third-party MCP server they’re depending on uses it.”

Updated MCP SDKs

To accompany the protocol update, there are updated MCP SDKs for Python, Typescript, Go, and C#. These support both the old and new protocol versions, so new clients can continue communicating with older servers, while updated servers will also support older clients, reducing the risk of immediate disruptions.

That backward compatibility should make the transition largely incremental, except for enterprises that built custom infrastructure around MCP’s earlier session-based architecture, Bandta said.

Identifying and auditing those session dependencies may not be easy, Jena warned.

“Session management complexity tends to be hidden across multiple layers — the gateway config, the deployment scripts, the monitoring dashboards. The code change is small; finding everywhere the assumption lives is what takes time,” he said.

Model Context Protocol (MCP), the emerging standard for connecting AI models to external tools and enterprise data, is undergoing its biggest architectural overhaul yet.

The latest release candidate, scheduled for release on July 28, removes protocol-level sessions in favor of a stateless architecture, a change which industry experts say is intended to make MCP easier to deploy across standard cloud infrastructure as enterprises move AI pilots into production.

“The session-based model made sense when MCP servers were local processes on a developer’s laptop. In production, it became an operational tax,” said Muskan Bandta, cloud associate at ZopDev.

“When your infrastructure team asks whether MCP services can scale like other cloud applications, the answer used to be ‘not quite.’ With the move to a stateless architecture, the answer is now yes,” Bandta added.

Earlier versions of the protocol maintained information about every client connection, meaning servers had to keep track of each session throughout an interaction. While that approach worked well for local development, it complicated deployments across multiple servers because requests often had to be routed back to the same machine, limiting scalability and making MCP a less natural fit for modern cloud architectures.

“Under the new stateless design, every request contains the information needed for any available server to process it independently. Applications that need to maintain context across multiple requests can still do so, but developers must now manage that state explicitly rather than relying on the protocol itself,” she said.

This transition to a stateless design goes beyond simplifying infrastructure by fundamentally changing how AI applications manage and share context across tools, according to Amit Jena, AI development manager at IT consulting firm Kanerika.

Instead of keeping application state hidden inside protocol sessions, the new design makes it explicit, allowing AI models to access, reason over, and pass that information between tools, giving developers greater control over how context is preserved and shared across tools, Jena said.

It should also make AI workflows more portable, resilient, and easier to orchestrate across distributed environments, he said.

MCP’s new features

Other changes to MCP include the addition of a Multi Round-Trip Requests (MRTR) mechanism that changes how AI agents request additional information they need to complete a task.

Instead of relying on a persistent connection between the client and server throughout the interaction, the new mechanism lets the server request additional input through a standard request-response exchange before continuing the task, Jena said.

Routable transport headers, another addition, enable API gateways and other networking infrastructure to identify and route MCP requests without inspecting their contents.

They reduce processing overhead, lower latency, and let enterprise teams enforce routing, rate-limiting and security policies more efficiently using existing API management infrastructure, Jena said.

MCP is also getting an updated authorization framework built around OAuth 2.1 and OpenID Connect; interactive MCP Apps; and deterministic caching of tool and resource listings to improve LLM prompt-cache hit rates, potentially saving on token costs.

Rebuilding the trust boundary

The MCP release steering committee also decided to deprecate some legacy features, including Roots, Sampling, Logging, the older HTTP+SSE transport and Dynamic Client Registration, although these will continue to work in this version and any other released over the next year.

The deprecation of Sampling is likely to have the biggest impact because it changes who is responsible for interacting with foundation models, said Jena.

“Sampling let MCP servers invoke the LLM through the client, which meant the server had a callback path into the model without owning that connection. Deprecating it means rebuilding that trust boundary,” Jena said. “Your server now calls the model provider directly. That changes your network architecture, your auth model, and depending on how you’ve built cost attribution, your billing flow.”

The year-long transition period will be enough for teams to audit their sampling dependencies now, said Jena: “The risk is that teams who haven’t implemented sampling themselves won’t know if a third-party MCP server they’re depending on uses it.”

Updated MCP SDKs

To accompany the protocol update, there are updated MCP SDKs for Python, Typescript, Go, and C#. These support both the old and new protocol versions, so new clients can continue communicating with older servers, while updated servers will also support older clients, reducing the risk of immediate disruptions.

That backward compatibility should make the transition largely incremental, except for enterprises that built custom infrastructure around MCP’s earlier session-based architecture, Bandta said.

Identifying and auditing those session dependencies may not be easy, Jena warned.

“Session management complexity tends to be hidden across multiple layers — the gateway config, the deployment scripts, the monitoring dashboards. The code change is small; finding everywhere the assumption lives is what takes time,” he said.

This article first appeared on InfoWorld.

Oracle is expanding its Cloud@Customer on-premises portfolio with a managed database offering that it says will enable enterprises to run databases, applications, and AI agents in their own data centers, helping CIOs modernize mid-sized workloads while meeting data residency, regulatory, and low-latency requirements.

The hybrid cloud offering, Base Database Cloud@Customer, combines existing database and infrastructure services such as the Base Database Service and Data Infrastructure Cloud@Customer X11 platform. It is designed for enterprises that do not need the scale of Exadata Cloud@Customer but still want their infrastructure and AI capabilities on-premises, managed by Oracle, the company said.

The Cloud@Customer X11 platform itself consists of two Oracle X11 compute servers and shared all-flash storage, offering up to 60 usable processor cores and 660 GB of memory per server, 47.2 TB of storage, and 10/25 GbE networking.

For regulated industries or restricted connectivity

Analysts see the new offering filling a gap for enterprises that want the operational and economic benefits of the cloud but cannot send their data to a public cloud because of legal restrictions or technology limitations.

These enterprises, according to Ashish Chaturvedi, executive research leader at HFS Research, are likely to be in regulated industries such as financial services, healthcare, government, and defense that must comply with data residency requirements, or needing low-latency access from remote sites to operational databases.

The offering could also appeal to enterprises modernizing mid-sized workloads at remote locations or within individual business units that could never justify the investment in a full Exadata rack, said Amit Chandak, chief analytics officer at IT consulting firm Kanerika.

In all cases, Chaturvedi said, the appeal of the offering is its managed nature, which takes away the burden of looking after the underlying infrastructure.

Deployment and maintenance becomes easier too, said Michael Leone, principal analyst at Moor Strategy and Insights: “They get automation that mid-size teams rarely have the staff to build. Clustering, patching, standby databases, and backups arrive configured instead of hand-assembled because the offering is managed.”

The economics are equally compelling, Chaturvedi said. The pay-as-you-go pricing model, combined with online compute scaling, helps enterprises avoid overprovisioning and paying license fees for idle cores, which is a “classic waste” of fixed on-premises systems, he said.

Private AI behind the firewall

Beyond the operational and economic benefits, the architecture of the new offering enables databases, applications, VMs, and AI agents to be collocated on the same platform, removing what Chaturvedi called “the single biggest blocker” to AI adoption in regulated environments: the need to keep private data behind the firewall.

“For a CIO in a regulated sector who wants to deploy AI agents but can’t let regulated data touch an external model API, that’s a real unlock,” Chaturvedi said.

More so because most AI offerings, at least in their present form and state, cannot guarantee sensitive data protection, said Igor Ikonnikov, advisory fellow at Info-Tech Research Group.

Even if Base Database Cloud@Customer turns out more expensive than fully cloud-based options, “It’s still attractive as it eliminates reputational and economic risk caused by possible AI-induced data leakage,” Ikonnikov said.

The offering’s consolidation of databases, applications, and AI agents will also simplify deployment of AI-based workflows, said Forrester principal analyst Noel Yuhanna. “It reduces stack complexity and helps accelerate development cycles, deliver real-time data, and eliminate data movement challenges.”

Despite those advantages, Chandak cautioned that the offering is unlikely to see broad adoption outside Oracle’s existing customer base: “If a company isn’t already on Oracle, the pull is weak. You don’t buy into Oracle’s database just to get this.”

Enterprises seeking similar hybrid cloud capabilities have no shortage of alternatives: AWS, Microsoft, Google Cloud, IBM, Dell Technologies, and HPE all offer combinations of on-premises infrastructure, cloud management, and AI services.

However, those alternatives typically require customers to integrate multiple software and hardware components rather than consume them as a single managed offering.

Oracle’s differentiation, although narrow, is hard to match, Chaturvedi said: “The vertical integration of database, engineered hardware, cloud management, high-availability architecture, and now private AI, all engineered together and delivered as a managed on-prem subscription should be genuinely convenient and attractive.”

The offering is compatible with Oracle AI Database 26ai and Oracle Database 19c in Enterprise Edition and Standard Edition configurations. It also supports Oracle Real Application Clusters, Oracle Data Guard, and Zero Data Loss Recovery Appliance through Oracle-managed cloud automation for high availability and disaster recovery, the company said.

Base Database Cloud@Customer is now generally available, Oracle said. It did not provide pricing.

This article first appeared on CIO.

Oracle is expanding its Cloud@Customer on-premises portfolio with a managed database offering that it says will enable enterprises to run databases, applications, and AI agents in their own data centers, helping CIOs modernize mid-sized workloads while meeting data residency, regulatory, and low-latency requirements.

The hybrid cloud offering, Base Database Cloud@Customer, combines existing database and infrastructure services such as the Base Database Service and Data Infrastructure Cloud@Customer X11 platform. It is designed for enterprises that do not need the scale of Exadata Cloud@Customer but still want their infrastructure and AI capabilities on-premises, managed by Oracle, the company said.

The Cloud@Customer X11 platform itself consists of two Oracle X11 compute servers and shared all-flash storage, offering up to 60 usable processor cores and 660 GB of memory per server, 47.2 TB of storage, and 10/25 GbE networking.

For regulated industries or restricted connectivity

Analysts see the new offering filling a gap for enterprises that want the operational and economic benefits of the cloud but cannot send their data to a public cloud because of legal restrictions or technology limitations.

These enterprises, according to Ashish Chaturvedi, executive research leader at HFS Research, are likely to be in regulated industries such as financial services, healthcare, government, and defense that must comply with data residency requirements, or needing low-latency access from remote sites to operational databases.

The offering could also appeal to enterprises modernizing mid-sized workloads at remote locations or within individual business units that could never justify the investment in a full Exadata rack, said Amit Chandak, chief analytics officer at IT consulting firm Kanerika.

In all cases, Chaturvedi said, the appeal of the offering is its managed nature, which takes away the burden of looking after the underlying infrastructure.

Deployment and maintenance becomes easier too, said Michael Leone, principal analyst at Moor Strategy and Insights: “They get automation that mid-size teams rarely have the staff to build. Clustering, patching, standby databases, and backups arrive configured instead of hand-assembled because the offering is managed.”

The economics are equally compelling, Chaturvedi said. The pay-as-you-go pricing model, combined with online compute scaling, helps enterprises avoid overprovisioning and paying license fees for idle cores, which is a “classic waste” of fixed on-premises systems, he said.

Private AI behind the firewall

Beyond the operational and economic benefits, the architecture of the new offering enables databases, applications, VMs, and AI agents to be collocated on the same platform, removing what Chaturvedi called “the single biggest blocker” to AI adoption in regulated environments: the need to keep private data behind the firewall.

“For a CIO in a regulated sector who wants to deploy AI agents but can’t let regulated data touch an external model API, that’s a real unlock,” Chaturvedi said.

More so because most AI offerings, at least in their present form and state, cannot guarantee sensitive data protection, said Igor Ikonnikov, advisory fellow at Info-Tech Research Group.

Even if Base Database Cloud@Customer turns out more expensive than fully cloud-based options, “It’s still attractive as it eliminates reputational and economic risk caused by possible AI-induced data leakage,” Ikonnikov said.

The offering’s consolidation of databases, applications, and AI agents will also simplify deployment of AI-based workflows, said Forrester principal analyst Noel Yuhanna. “It reduces stack complexity and helps accelerate development cycles, deliver real-time data, and eliminate data movement challenges.”

Despite those advantages, Chandak cautioned that the offering is unlikely to see broad adoption outside Oracle’s existing customer base: “If a company isn’t already on Oracle, the pull is weak. You don’t buy into Oracle’s database just to get this.”

Enterprises seeking similar hybrid cloud capabilities have no shortage of alternatives: AWS, Microsoft, Google Cloud, IBM, Dell Technologies, and HPE all offer combinations of on-premises infrastructure, cloud management, and AI services.

However, those alternatives typically require customers to integrate multiple software and hardware components rather than consume them as a single managed offering.

Oracle’s differentiation, although narrow, is hard to match, Chaturvedi said: “The vertical integration of database, engineered hardware, cloud management, high-availability architecture, and now private AI, all engineered together and delivered as a managed on-prem subscription should be genuinely convenient and attractive.”

The offering is compatible with Oracle AI Database 26ai and Oracle Database 19c in Enterprise Edition and Standard Edition configurations. It also supports Oracle Real Application Clusters, Oracle Data Guard, and Zero Data Loss Recovery Appliance through Oracle-managed cloud automation for high availability and disaster recovery, the company said.

Base Database Cloud@Customer is now generally available, Oracle said. It did not provide pricing.

This article first appeared on CIO.

Oracle is expanding its Cloud@Customer on-premises portfolio with a managed database offering that it says will enable enterprises to run databases, applications, and AI agents in their own data centers, helping CIOs modernize mid-sized workloads while meeting data residency, regulatory, and low-latency requirements.

The hybrid cloud offering, Base Database Cloud@Customer, combines existing database and infrastructure services such as the Base Database Service and Data Infrastructure Cloud@Customer X11 platform. It is designed for enterprises that do not need the scale of Exadata Cloud@Customer but still want their infrastructure and AI capabilities on-premises, managed by Oracle, the company said.

The Cloud@Customer X11 platform itself consists of two Oracle X11 compute servers and shared all-flash storage, offering up to 60 usable processor cores and 660 GB of memory per server, 47.2 TB of storage, and 10/25 GbE networking.

For regulated industries or restricted connectivity

Analysts see the new offering filling a gap for enterprises that want the operational and economic benefits of the cloud but cannot send their data to a public cloud because of legal restrictions or technology limitations.

These enterprises, according to Ashish Chaturvedi, executive research leader at HFS Research, are likely to be in regulated industries such as financial services, healthcare, government, and defense that must comply with data residency requirements, or needing low-latency access from remote sites to operational databases.

The offering could also appeal to enterprises modernizing mid-sized workloads at remote locations or within individual business units that could never justify the investment in a full Exadata rack, said Amit Chandak, chief analytics officer at IT consulting firm Kanerika.

In all cases, Chaturvedi said, the appeal of the offering is its managed nature, which takes away the burden of looking after the underlying infrastructure.

Deployment and maintenance becomes easier too, said Michael Leone, principal analyst at Moor Strategy and Insights: “They get automation that mid-size teams rarely have the staff to build. Clustering, patching, standby databases, and backups arrive configured instead of hand-assembled because the offering is managed.”

The economics are equally compelling, Chaturvedi said. The pay-as-you-go pricing model, combined with online compute scaling, helps enterprises avoid overprovisioning and paying license fees for idle cores, which is a “classic waste” of fixed on-premises systems, he said.

Private AI behind the firewall

Beyond the operational and economic benefits, the architecture of the new offering enables databases, applications, VMs, and AI agents to be collocated on the same platform, removing what Chaturvedi called “the single biggest blocker” to AI adoption in regulated environments: the need to keep private data behind the firewall.

“For a CIO in a regulated sector who wants to deploy AI agents but can’t let regulated data touch an external model API, that’s a real unlock,” Chaturvedi said.

More so because most AI offerings, at least in their present form and state, cannot guarantee sensitive data protection, said Igor Ikonnikov, advisory fellow at Info-Tech Research Group.

Even if Base Database Cloud@Customer turns out more expensive than fully cloud-based options, “It’s still attractive as it eliminates reputational and economic risk caused by possible AI-induced data leakage,” Ikonnikov said.

The offering’s consolidation of databases, applications, and AI agents will also simplify deployment of AI-based workflows, said Forrester principal analyst Noel Yuhanna. “It reduces stack complexity and helps accelerate development cycles, deliver real-time data, and eliminate data movement challenges.”

Despite those advantages, Chandak cautioned that the offering is unlikely to see broad adoption outside Oracle’s existing customer base: “If a company isn’t already on Oracle, the pull is weak. You don’t buy into Oracle’s database just to get this.”

Enterprises seeking similar hybrid cloud capabilities have no shortage of alternatives: AWS, Microsoft, Google Cloud, IBM, Dell Technologies, and HPE all offer combinations of on-premises infrastructure, cloud management, and AI services.

However, those alternatives typically require customers to integrate multiple software and hardware components rather than consume them as a single managed offering.

Oracle’s differentiation, although narrow, is hard to match, Chaturvedi said: “The vertical integration of database, engineered hardware, cloud management, high-availability architecture, and now private AI, all engineered together and delivered as a managed on-prem subscription should be genuinely convenient and attractive.”

The offering is compatible with Oracle AI Database 26ai and Oracle Database 19c in Enterprise Edition and Standard Edition configurations. It also supports Oracle Real Application Clusters, Oracle Data Guard, and Zero Data Loss Recovery Appliance through Oracle-managed cloud automation for high availability and disaster recovery, the company said.

Base Database Cloud@Customer is now generally available, Oracle said. It did not provide pricing.

Across industries, a version of the same conversation is playing out in technology leadership meetings. Enterprises have deployed AI broadly, and foundation models keep getting more capable. Yet the outputs still feel generic, shaped by industry patterns rather than by the organization producing them.

McKinsey’s AI Trust Maturity Survey found that while overall AI maturity scores have improved, only about a third of organizations have reached a mature level of strategy and governance. Technical capability is advancing faster than organizational alignment. In my view, the gap is not a model problem. It is a context problem. Enterprises are feeding generic inputs into powerful models because sharing organizational context seamlessly with AI is neither easy nor intuitive today.

Building the analytical and creative capabilities to scale AI, something I explored in a recent piece on the left-brain and right-brain approach to enterprise AI, is necessary but not sufficient. Before either can function effectively, the enterprise needs something more fundamental. AI that actually understands the contextual fabric of the organization it is operating in. A frontier model has processed everything written about your sector, your competitors and your regulatory landscape. It cannot access the reasoning embedded in years of delivery decisions, the patterns encoded in how your teams scope and deliver work over time. That knowledge is organizational memory, and frontier models can’t get that easily. It exists inside every enterprise but has never been structured, connected or made available to any AI system. Without it, even the most capable model answers a generic version of your question.

The next competitive advantage in enterprise AI will not come from a better model. It will come from a better organizational context.

One global technology enterprise set out to solve this across its own operations, building a modular ecosystem of domain-specific agents grounded in its own data across contracting, talent and vendor management workflows. What emerged was not just operational efficiency but a shared intelligence layer connecting decisions across functions for the first time.

Competitive differentiation was never about the tools

Consider what actually separates high-performing enterprises from the rest. In a regulated industry like financial services or healthcare, organizations cannot meaningfully differentiate on product. A bank cannot offer substantially different products or services. A health system uses the same clinical protocols and the same electronic health record (EHR) platforms as its peers. What varies is everything underneath: the rigor of processes, the coherence of cross-functional decisions and the people who carry years of accumulated organizational judgment in how they make those decisions.

An organization with a proper context layer in place can say with precision that for this type of engagement, in this sector, with this risk profile, our institutional history tells us exactly where we stand. That level of specificity is what most enterprises have never made available to AI.

The enterprise AI brain that every organization has but has never assembled

Every enterprise already possesses what I think of as an enterprise AI brain. The problem is that it has never been assembled in one place. The data exists across contracts, project documentation, talent records, delivery metrics and the operational communications of daily execution — the informal reasoning that rarely makes it into formal systems.

None of the standard enterprise platforms were designed to connect this. A customer relationship management (CRM) system captures customer interactions. An enterprise resource planning (ERP) system captures transactions. A project management tool captures tasks and timelines. None of them captures the reasoning behind decisions and none of them surfaces a coherent picture of how the organization actually thinks and operates.

BCG’s study across hundreds of companies found that only 10% of AI value comes from the algorithms and another 20% from the technology that implements them, meaning the remaining 70% depends on people, processes and organizational change. The organizations extracting real value are those that have made their institutional knowledge available to AI in a structured, governed way.

Building a contextual AI fabric

A Contextual AI Fabric is the technical and organizational layer that makes the Enterprise AI Brain usable. It brings together unstructured data ingestion, semantic structuring, retrieval pipelines and governed model access to give AI systems the organizational context they need to produce outputs that are genuinely specific to your enterprise rather than generically accurate about your industry. It rests on three pillars. Core is the secure, governed and interoperable foundation that AI operations run on. Context is reliable, traceable access to the organization’s data, processes, knowledge and history. Coordination connects people, agents, applications and systems into process-driven workflows with clear controls and accountability, so the organization acts as one rather than a set of disconnected functions.

The data layer is where most organizations underestimate the work. Contracts, project reports, talent assessments and operational communications require extraction, chunking, embedding and indexing before a model can retrieve and reason over them meaningfully.

The semantic layer is what makes retrieval meaningful. Even well-ingested data fails if functions use different terminology for the same concepts. What legal calls a contract, delivery calls a scope. Without a shared ontology, AI systems remain precise about the wrong thing. And retrieval alone, however well-structured, only takes an organization so far. Retrieval surfaces the right information at the moment of a query, but it does not give a model genuine memory of the organization. The real source of unique, organization-level relevance comes from training domain-specific small language models on this context directly, models that carry organizational memory forward rather than fetching it fresh every time. That is what ultimately separates a Contextual AI Fabric from a well-organized database.

The governance layer is not an add-on. Access controls, data lineage, approval thresholds and human checkpoints need to be designed in before any agent goes into production. Security is not a layer you add afterward. It is the condition under which organizational AI is worth building. If the institutional intelligence that makes your enterprise distinct gets absorbed into a frontier model’s training data, it becomes everyone’s baseline. That is an architectural decision made, or avoided, at the point of deployment.

Proprietary by design

The institutional knowledge that makes up a contextual AI fabric — delivery history, commercial patterns, talent intelligence and operating culture — is proprietary in ways no external model can replicate. This is as much a security imperative as it is a competitive one. Organizational context, once exposed, cannot be unexposed.

Most enterprises are using AI to automate existing processes rather than questioning whether those processes should be redesigned entirely. The organizations extracting the most value are those willing to ask whether their current operating model, built before GenAI existed, is the one they would build today. That question is harder than any technology decision, and it is also the most consequential one.

From context to coordinated action

Context alone is not enough. When a delivery risk surfaces in project data, the talent function needs to respond. When a commercial signal changes in contract data, operations need to recalibrate. This kind of cross-functional coordination, driven by shared organizational intelligence rather than siloed data, is where the real value of enterprise AI shows up and where the absence of a shared context layer becomes most visible.

A global leader in digital payments and business services found its AI deployments across payroll, HR and risk compliance, each running in isolation, with no shared governance or common data foundation. Once the organization established a unified governance backbone connecting its operational data through a shared retrieval layer, business users could query across domains in plain language and new use cases across fraud analytics, forecasting and policy extraction became extensible without rebuilding infrastructure for each one. The shift was not in the models. It was in the shared foundation underneath them.

The leadership question behind the technology question

The enterprises pulling ahead in AI are not winning on model quality but on organizational memory. The ones that have done the hard work of structuring their institutional knowledge into a governed, secure Contextual AI Fabric are giving their AI something no competitor can replicate: the accumulated intelligence of how the business actually operates.

For CIOs, the question is no longer which model to deploy. It is whether the organization has built the foundation that would make any model worth deploying.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

Outsourcing worked – until it didn’t.

After Akirolabs achieved early market validation and onboarded its first enterprise customers, outsourcing began to create strategic limitations around scalability, intellectual property (IP) ownership, security and delivery execution.

The challenges started after the first enterprise customers confirmed product-market fit. At that point, delivery speed became directly tied to business growth. Product quality expectations increased. Infrastructure and security requirements became stricter. Investors started asking difficult but fair questions about IP ownership, operational dependencies and long-term scalability.

Most importantly, engineering execution was no longer just an operational function – it became part of the company’s strategic advantage. That was the moment when the founders decided the company needed dedicated technology leadership to address these challenges. This is how I joined the company at the beginning of 2023. As VP of Engineering and a bit later as CTO, I led the transformation (usually known as insourcing, repatriating or backsourcing) from an outsourced model to an internal engineering organization while maintaining product delivery continuity and preparing the company for the next growth stage. The process took roughly a year and involved not only technical migration, but also organizational design, hiring, process development, infrastructure modernization and cultural transformation – everything from the ground up.

Building an internal engineering organization while still delivering

One of the biggest misconceptions about insourcing is that it is primarily a technical project. It is a leadership and execution challenge.

When I joined the company, there was effectively no internal engineering structure, limited visibility into the existing system and no clear long-term technical strategy. My first months were dedicated to understanding reality and I began with a comprehensive assessment of the codebase, operational risks, documentation quality and knowledge dependencies to determine the most viable transition strategy.

Very early in the process, I faced a critical strategic decision: whether to gradually assume ownership of the existing platform or rebuild it internally. To make that decision, I evaluated four distinct transition models ranging from limited management insourcing to a complete internal rebuild.

After assessing the technical, operational and long-term business implications of each approach, I selected the most demanding option: rebuilding the product internally while maintaining uninterrupted delivery for existing customers. Although riskier in the short term, a full rebuild offered the clearest route to complete IP ownership, architectural flexibility and long-term scalability.

At the time, this decision ran counter to the approach typically taken by startups in similar situations. Most organizations gradually assume ownership of an existing codebase to minimize short-term risk and preserve delivery capacity. My assessment was that the accumulated architectural debt, fragmented knowledge distribution and long-term maintenance risks would ultimately make a phased takeover more expensive and less scalable than a controlled rebuild. The strategy required significantly higher execution discipline, but it allowed us to establish complete ownership of the platform, eliminate inherited constraints and create an architecture capable of supporting enterprise-scale growth.

The next challenge was hiring.

In Germany, hiring can easily take four to six months – mostly due to a typical 3-month notice period, which is incompatible with startup timelines. We solved this by building a hybrid organization structure early: a lean internal core team combined with carefully selected contractors. Instead of hiring only narrow specialists, we prioritized experienced generalists capable of operating across architecture, infrastructure, security and compliance discussions. Later, we evolved toward a product engineering model, where engineers owned broader product outcomes rather than narrowly defined technical functions.

During the first three months, we established a core engineering team of four senior engineers. Over the following nine months, the organization expanded to roughly fifteen engineers while I strategically designed and executed the transformation of the platform’s architecture to meet the rigorous deployment and compliance standards of our first enterprise clients, including Raiffeisen Bank International and Bertelsmann. This structural overhaul allowed the company to meet the deployment, security and compliance requirements of enterprise customers that had previously been inaccessible under the outsourced model. At that point, we had already achieved complete coverage across backend, frontend, DevOps, QA and security.

I also intentionally kept processes lightweight during the transition. Instead of introducing heavyweight frameworks, we focused on clarity of priorities, fast decision-making and execution discipline. We used Kanban over Scrum, eliminated unnecessary meetings, shortened the remaining ones and emphasized engineering culture over process overhead.

Another major challenge was project estimation. Because dual-track development was unavoidable until the in-house platform reached production readiness, estimation accuracy had a direct impact on budget efficiency. Despite all challenges, my initial estimate ultimately proved remarkably close to the final delivery date, differing by only about a week. Accurate forecasting under conditions of parallel development streams, ongoing customer commitments and active team formation became a critical leadership challenge. Maintaining this level of predictability throughout the transition helped align engineering execution with business planning, hiring decisions and investor expectations.

The engineering transformation enabled capabilities that contributed to Akirolabs being recognized as an IDC Innovator in Procurement in 2023, named amongst the Top 27 AI Startups in Germany in 2024, Sifted’s 100 Fastest-Growing Startups in DACH & CEE 2025 and inclusion in 2024-2026 in ProcureTech100 annual recognition of procurement technology providers shaping the future of digital procurement.

Managing risk without slowing down the business

The hardest part of insourcing is not writing code, selecting the technology stack, designing architecture or configuring infrastructure. It is avoiding disruption while the company is changing underneath the product. I successfully orchestrated the concurrent overhaul of product architecture, cross-functional engineering recruitment, infrastructure modernization and live customer operations under exceptionally tight margins.

To reduce delivery risk, we approached the transition in layers.

First, we focused on infrastructure reliability and operational readiness before feature expansion. Cloud architecture, recovery testing, permission segregation and incident management processes were implemented early, not after launch. We also introduced multiple testing stages and dedicated QA functions after learning the hard way that a “developers-only” quality control approach does not scale for complex web platforms and business domains.

Second, we established a structured knowledge-transfer process to rapidly onboard engineers and reduce external dependencies.

Third, we became extremely disciplined about scope management. One of the most common reasons insourcing initiatives fail is uncontrolled change during the rebuild phase. Every new feature request increases uncertainty non-linearly. We learned to separate strategic improvements from distractions and protect the core delivery roadmap aggressively. Throughout the transition, we successfully maintained uninterrupted customer operations by utilizing planned maintenance windows, achieved a near-zero-downtime migration and permanently doubled product velocity immediately following the migration.

Beyond the technical migration itself, the transition established a repeatable operating model for scaling technology organizations beyond the product-market-fit stage. The framework combined organizational redesign, controlled knowledge repatriation, architecture modernization and enterprise-grade operational practices while maintaining uninterrupted customer delivery throughout the transformation. While the implementation was specific to Akirolabs, the underlying principles are broadly applicable to organizations seeking to transition from outsourced development to internal product ownership without disrupting business operations.

By the time the new platform reached production readiness, I had established not only a functioning engineering organization, but also a stable operational model: internal ownership, production-grade infrastructure, security processes, scalable hiring practices and clear technology and product roadmaps.

A positive side effect of the transition was the creation of internal UI/UX and Data Science capabilities, which later became strategically important for AI product initiatives and created a foundation for the third version of the product, which we released in mid-2025.

My technical restructuring and migration to a secure proprietary platform reduced architectural risk, established full in-house ownership and helped strengthen investor confidence during the company’s successful €5M fundraising round in 2024.

The transition created a stronger foundation for scale and supported the company’s continued expansion among enterprise organizations operating at Fortune 500 scale, including Ahold Delhaize, Workday, IFF, Deutsche Bahn and others.

Lessons learned for CTOs considering insourcing

Looking back, several decisions made the transition successful, and several mistakes made it harder than necessary.

The first lesson is simple: decisiveness in strategic transition is paramount to maintaining business momentum. Rapidly evaluating insourcing frameworks and defining clear boundaries with the external partner allowed us to mitigate operational downtime and execute a highly efficient migration ahead of critical market deadlines.

Second, hire more senior people and do it as early as possible. Strong technical leaders multiply execution capacity far beyond their individual contribution. In our case, the quality of the first hires influenced architecture quality, hiring standards, delivery discipline and engineering culture for the entire organization.

Finally, culture matters more than frameworks. Processes can be added later. Ownership mentality cannot.

The biggest long-term advantage of bringing development in-house was not simply faster execution, not better code quality or operational cost optimization by over 30% after the transition which we also achieved. It was an alignment. Product strategy, engineering decisions, customer priorities and business goals became part of the same conversation instead of being separated by organizational boundaries. For technology companies operating in highly competitive markets, that alignment becomes a compounding advantage over time.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

In a single month, one enterprise reportedly spent half a billion dollars on AI. A consultant told Axios that the client had handed its workforce AI licenses, set no usage limits and let the meter run until finance noticed. The figure is spectacular, and it is the wrong thing to fear. That half-billion-dollar accident is only the visible part of a quieter, far larger failure. Worldwide AI spending is forecast to reach $2.52 trillion in 2026, more than any technology category in a generation, and by the most cited measure, roughly 95 percent of it returns nothing. Boards read that as proof that the technology does not work. The evidence points somewhere less comfortable, and it is not a technology problem at all. Most boards cannot see it because they are reading the wrong number: They track failure when the number that matters is allocation. The discipline that separates the winners is not technical. It is how they allocate capital across time, and how willing they are to stop. The hardest discipline in the AI era is not adopting faster. It is allocating honestly and refusing to judge a three-year bet on a six-month cycle.

The number everyone quotes, and no one acts on

The headline statistic is now familiar. MIT’s Project NANDA, in its 2025 study The GenAI Divide, found that about 95 percent of enterprise generative AI pilots produced no measurable impact on the P&L, while roughly 5 percent captured nearly all the value. S&P Global Market Intelligence found that the share of companies abandoning most of their AI initiatives jumped from 17 percent to 42 percent in a single year, with the average organization scrapping 46 percent of its proofs-of-concept before production. Gartner expects more than 40 percent of agentic AI projects to be canceled by the end of 2027, citing escalating costs, unclear business value and inadequate risk controls. And the pattern predates generative AI: RAND found that more than 80 percent of AI projects fail, roughly twice the rate of comparable work that does not involve AI.

Read as a technology story, these numbers say AI does not work. Read correctly, they say something more useful. MIT’s own authors located the cause not in model quality but in a learning and integration gap. The winners were not running better models. They picked one problem, executed and worked well together. Purchased solutions reached production about 67 percent of the time, while internal builds succeeded roughly a third as often. Gartner’s own spending forecast notes the same pivot, with CIOs scaling back ambitious internal builds in favor of commercial solutions that promise more predictable value. None of that is a verdict on the technology. It is a verdict on allocation: What gets funded, for how long and against which yardstick. The popular prescription, heard in every boardroom this year, is to measure harder and prove value sooner. That advice quietly repeats the mistake, because forcing a three-year bet to prove itself sooner is precisely how you kill it. The fix is not more measurement. It is measuring each bet against the right clock and subtracting the ones that miss.

The six-month cycle problem

Return to that 95 percent, because the way it is measured is the whole argument. Much of the reported failure is judged on a short clock, with a pilot counted as a failure if it has not shown a measurable financial return within roughly six months. The single most quoted number in enterprise AI is therefore a six-month yardstick applied to every initiative, including the bets designed to pay back in three years. The headline failure rate is not only a measure of AI. It is a measure of impatience.

The most expensive mistake in enterprise AI is a timing error. Enterprises have been spending heavily on AI for more than two years, and 2026 is the year boards are demanding returns. The multi-year bets funded during the 2024 and 2025 scale-up are only now far enough along to be judged. When a board reviews an initiative, it applies the yardstick it knows, which is quarterly return. That yardstick is correct for an efficiency project and ruinous for a capability bet. A workflow automation that should pay back in two quarters and a foundational data and agent capability that pays back in three years are not the same instrument, yet they are reviewed in the same meeting against the same metric.

This is the heart of the divide. The 5 percent did not simply pick better projects. They judged each project against its own horizon. McKinsey’s enduring Three Horizons model made this discipline standard in corporate strategy a generation ago: near-term, emerging and long-term bets are funded and measured differently. AI erased that discipline because the hype compressed every timeline into the current quarter. The result is two failure modes that appear opposite yet share a common root. Organizations kill three-year bets at month six because they miss a metric the bet was never designed to hit. And they keep funding six-month theater for years because it is visible, safe and never asked to prove a return. Both are allocation failures. Neither is a technology failure.

Subtraction is a strategy

There is a second discipline, the 5 percent share, and it is the one boards find hardest. They subtract. Every credible study of the failure rate describes the same chaotic pattern underneath it: Initiatives are abandoned late, without criteria, after the money is spent and the credibility is gone. Disciplined organizations do the opposite. They decide the conditions for stopping before they start, and they stop on schedule. Subtraction is not the absence of strategy. It is the strategy. Capital removed from a failing bet is capital available for a surviving one, and the survivors are where the entire return lives.

This reframes the 42 percent abandonment figure. Abandonment is not the problem. Undisciplined abandonment is. An organization that liquidates a position the moment it breaches a pre-agreed kill line is practicing portfolio hygiene. An organization that lets a doomed pilot run until someone loses patience is paying full price for a lesson it could have bought at a discount. The 5 percent who won were not smarter. They were patient in the right places and ruthless in the wrong ones.

The HALT framework: Horizon, Allocation, Liquidation, Tracking

Treating AI as a portfolio rather than a pile of pilots requires four disciplines, and the organizations that execute well put all four in place before the next funding cycle, not after the next failure. The name is deliberate. The discipline most enterprises lack is the willingness to halt the wrong bets in time to fund the right ones.

Component 1: Horizon. Classify every AI initiative by its true payoff horizon before it is funded. Horizon 1 covers efficiency plays that should return value within two quarters. Horizon 2 covers capability bets, data foundations, agent platforms and integration work that pays back in roughly 6 to 18 months. Horizon 3 covers transformation bets that take eighteen months to three years or longer. Each horizon carries its own success metric, set at funding time. A Horizon 1 yardstick never judges a Horizon 3 bet. This single rule prevents the most common and most expensive error in the portfolio.

Component 2: Allocation. Decide the split across horizons deliberately, as a board-level capital decision, not as the accidental sum of whatever pilots happened to win approval. A practical reference point, borrowed from decades of innovation-portfolio practice, is roughly 70% to near-term value, 20% to capability, and 10% to transformation. The exact ratio is yours; the discipline is to choose and defend it. The failure mode is an unmanaged portfolio: 90 percent scattered across disconnected Horizon 1 experiments, with nothing compounding into the Horizon 2 capability that the buy-and-integrate winners actually built.

Component 3: Liquidation. Attach a kill line to every initiative at the moment it is funded: A named milestone, a date and an owner empowered to stop it. If a bet misses its horizon-appropriate milestone, it is liquidated, and capital is reallocated on schedule without debate over sunk costs. The absence of a pre-agreed kill line is not patience. It is an unpriced liability that the board has almost certainly not been shown.

Component 4: Tracking. Report the portfolio to the board on a fixed cadence using a single instrument: The AI Portfolio Scorecard. Not a deck of project updates, but a single view of allocation by horizon, burn against milestone, liquidation decisions taken and capital reallocated to survivors. The cadence is the control. A portfolio reviewed once a year is a portfolio managed by hope.

THE AI PORTFOLIO SCORECARD: SCORE EVERY INITIATIVE BEFORE IT IS FUNDED

Score each criterion: 0 = not present, 1 = partially documented, 2 = fully verified. Total out of 12. Bands: 0 to 4 = DO NOT FUND  |  5 to 8 = CONDITIONAL  |  9 to 12 = FUND.

THE LIQUIDATION GATE: RUN AT EVERY BOARD REVIEW BEFORE CONTINUING FUNDING

Any unresolved FAIL = stop funding, liquidate the position, reallocate the capital to a survivor and record the decision on the scorecard.

The cost of the timing error

The financial case follows the pattern and is consistent. Consider two organizations that funded the same class of Horizon 3 bet: A domain-specific agent platform meant to compound over three years. The first review was conducted at month six against a quarterly return test, found no payback and killed it, booking the write-off as a lesson about AI being overhyped. Its competitor classified the same work as Horizon 3, set an 18-month capability milestone, protected funding through two review cycles and shipped to production within the window the work actually required. One organization spent its money to learn that it lacks allocation discipline. The other spent comparable money and now owns a capability its rival has abandoned and cannot quickly rebuild. The dollars on the two income statements are similar. The competitive positions are not.

The governance return the board has been waiting for

Allocation discipline does two things at once. It stops the bleed by liquidating failures on a schedule rather than at the point of exhaustion. And it concentrates capital where the entire return lives, in the small number of bets that survive their horizon. The 5 percent figure is not a ceiling imposed by the technology. It is the current yield of an industry allocated by hype. An organization that classifies by horizon, allocates on purpose, liquidates on a line and tracks on a cadence is not trying to beat the technology. It is trying to beat its own indiscipline, and that is a far more winnable contest.

The board conversation about AI returns is coming for every organization, and it arrives the moment the spending outpaces the story. When it does, the CIO will be asked a simple question: Where did the money go? The leaders who can answer will not show a pile of pilots. They will show a portfolio: What was funded, against which horizon, what was liquidated and when, and what the survivors are now worth. Subtraction is a strategy. The only question is whether you are practicing it on purpose or about to learn it by accident.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

Military strategists know that asymmetric wars are lost not at the point of attack but at the seams between defensive units, where no single commander owns the territory and information moves slower than the threat. In January 2024, a finance employee at Arup’s Hong Kong office learned this lesson for $25 million, joining a video call with what appeared to be the engineering firm’s chief financial officer and several colleagues, receiving instructions to wire funds to a designated account, and complying. Every face on the screen was a deepfake, cloned from publicly available footage of the actual executives. The attackers conducted the entire meeting in real time and vanished before anyone in the organization realized the CFO had never logged on.

The incident would be remarkable enough as a one-off, but it represents a pattern accelerating well beyond isolated cases. Global payment fraud reached $33.4 billion in 2024 according to the Nilson Report, and the US absorbed a disproportionate 42% of those losses despite processing only 25% of global card transactions. The latest FBI Internet Crime report identifies more than one million complaints and nearly $21 billion in cyber-enabled crime losses in 2025 (up from $16 million in 2023), while Deloitte projects AI-enabled fraud in the US will hit $40 billion by 2027. This increasingly includes crypto-related fraud, not just credit card or traditional banking fraud.

For anyone who oversees financial operations, risk or payment technology infrastructure, these numbers are not forecasts of a future “regional conflict.” Instead, they are the current cost of a war most institutions have not yet recognized they are fighting.

Reconnaissance at scale: How AI redraws the attacker’s map

The conventional narrative around AI-powered fraud emphasizes speed: Faster phishing, faster credential stuffing, faster social engineering. Jason Kikta, CTO of Automox, sees the shift differently. “The main threat from AI misuse isn’t faster execution, as automation has been leveraged for years,” Kikta says. “The true dangers are lower barriers to entry and faster adaptation, giving attackers the ability to pivot techniques in near real-time.”

The distinction means that execution is a quantitative improvement, the kind existing defenses can absorb by scaling up. Lower barriers to entry and real-time adaptation are qualitative: A force multiplier that turns every amateur into an equipped operator with a coach that learns from each failed attempt. Deepfake-as-a-service platforms now produce voice clones from three seconds of audio. AI-driven vulnerability scanning maps an institution’s unpatched endpoints while the security team is still scheduling the review meeting. In 2024, 269 million stolen credit card records appeared on dark web platforms, giving AI-equipped attackers what military intelligence analysts would call an order of battle: A detailed map of the defender’s exposed positions, ready to be mined for patterns, tested against live systems and exploited at machine speed.

The result is a combined arms threat, one that operates across domains simultaneously the way a competent military force coordinates air, ground and intelligence rather than running them as independent campaigns. The same AI that crafts a convincing business email compromise can probe unpatched point-of-sale systems to install digital skimmers. The same synthetic identity that opens a fraudulent credit card account can exploit a payment authorization vulnerability discovered through automated scanning. Card-not-present fraud now accounts for 71% of all US card fraud losses, and the attack surface keeps expanding as digital wallets and e-commerce push more transactions into channels where physical card verification is impossible.

Attackers treat endpoint management gaps and transaction monitoring gaps as a single attack surface, while most defenders continue to patrol them as separate territories.

Fragmented command: The structural vulnerability AI exploits

Consider how most financial institutions, crypto platforms and digital asset intermediaries actually organize their defenses: A cybersecurity team focused on identity compromise, endpoint protection and infrastructure threats; a fraud team focused on account takeover, mule networks and scam typologies; an AML or financial crimes team focused on wallet screening, sanctions exposure and suspicious activity reporting; and an AI risk or digital trust team, if one exists at all, focused on synthetic media, model abuse and impersonation. Each function has its own tooling, budget, reporting line and intelligence feeds. In crypto markets, where value can move irreversibly across wallets, chains, mixers, exchanges and OTC brokers in minutes, those silos create exploitable gaps between detection, attribution, interdiction and recovery.

A pig-butchering scam that begins on a dating app, migrates to WhatsApp, directs a victim to a fake crypto investment platform, and then launders proceeds through nested services and cross-chain bridges is not just a fraud event. It is also a cybersecurity event, a financial crimes event, an identity event, a platform abuse event and, increasingly, an AI-enabled social engineering event. Chainalysis reported that high-yield investment scams and pig-butchering schemes were among the most successful crypto scam types in 2024, while also noting growing use of AI in fraud and scams.

Research published by the University of California, Davis found that these schemes follow a staged lifecycle: Trust-building, fabricated investment returns, escalating deposits, withdrawal obstruction and re-targeting of victims after the initial loss. When each part of that lifecycle is monitored by a different team, the institution sees fragments of the attack rather than the economic system of the crime.

“Fraud no longer happens in isolated channels,” observes Jeff Li, Global Product & Designer Lead at Binance. “AI-powered scams move seamlessly across platforms, and payment systems, making fragmented defenses increasingly ineffective.” He believes that the future of security depends on unified intelligence — combining AI, real-time monitoring, secure infrastructure and cross-functional response mechanisms into a single coordinated defense system.

“We’ve invested heavily in AI-driven risk detection, real-time scam warnings and infrastructure to stay ahead of evolving threats, continues Li, claiming that from Q1 2025 to Q1 2026, these efforts helped Binance prevent over $10 billion in potential user losses and protected more than 5 million users globally. As AI continues to reshape both fraud and fraud prevention, the focus remains on building systems that can protect users, not just at scale, but in real time.

Unified command: From org chart to battle plan

Kikta’s assessment contains a contrarian detail worth teasing apart: “The good news is that a strong compliance program prioritizing depth of coverage and speed of enforcement will hold up against AI-enabled fraud,” he says. In a landscape saturated with predictions that existing defenses are obsolete, Kikta argues that the fundamentals of patch management, endpoint hygiene and compliance rigor still hold, provided the clock speed at which those fundamentals execute keeps pace with the adversary.

That clock speed is the operational link between cybersecurity and card fraud prevention. An unpatched point-of-sale terminal or payment gateway exposed for 30 days represents 30 days of reconnaissance opportunity for an AI scanner probing for places to install a digital skimmer or intercept card data in transit. A compliance gap in identity verification is an open invitation for synthetic identities to open accounts and run fraudulent transactions. Endpoint management data and transaction monitoring data describe the same attack surface from different angles, and fusing those streams into a single operational picture, the financial equivalent of a military intelligence fusion center, gives defenders something the current siloed structure cannot: Visibility into an attack developing across domains before it reaches the payment layer.

The value of that convergence extends beyond defense. A unified data layer across cyber, fraud and payments creates consolidated threat intelligence that can inform underwriting decisions, merchant risk scoring and product design. Organizations that treat converged security data as a business intelligence asset (not merely an operational feed) will find they have built something with commercial utility well beyond the security operations center.

Mascaro frames the prescription in terms that belong in a boardroom, not a SOC. “The real competitive advantage in fraud isn’t your AI stack,” he says. “It’s leadership’s clarity to unify risk disciplines that everyone else keeps in separate departments.”

Field manual: What winning institutions do differently

The institutions gaining ground in this new form of asymmetric conflict share a common operational posture: They treat endpoint management as card fraud prevention rather than IT maintenance, and they feed cyber, fraud and payments intelligence into a single picture rather than three separate briefings. The defensive AI advantage, such as it is, comes from that integration, not from any single model’s sophistication.

Adversaries have already unified their operations. Yet, payment processors and financial institutions that keep running separate campaigns on separate fronts, with separate intelligence, will keep conducting after-action reviews of battles they have already lost.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

For diversified enterprises, few operating model questions are as persistent or polarizing as centralization versus decentralization. Decentralization promises speed, ownership, and local responsiveness. Centralization promises efficiency, standardization, and leverage. Both can be right. Both can be wrong. The challenge is that many organizations end up with both models operating at once, without enough clarity about why.

The result of fragmented systems, duplicated capabilities, inconsistent data, rising IT spend, and a complexity tax that compounds over time is familiar to many CIOs. What starts as autonomy can become architectural sprawl. What starts as enterprise leverage can become bureaucracy. And as companies modernize core platforms, integrate data, and scale capabilities like AI, the tension becomes harder to ignore.

Paul Krebs has lived that tension from multiple vantage points. Most recently as CIO and chief transformation officer at Koch Industries, and previously a technology and transformation leader at The Coca-Cola Company, he’s worked in environments where business units value autonomy, enterprise scale matters, and the wrong operating model can slow progress just as easily as the wrong technology architecture.

His conclusion isn’t that CIOs should pick a side, but they need a more intentional form of centralization, one that starts with business architecture, clarifies decision rights, and continually revisits where capabilities should sit as the organization matures.

Centralization: a design choice, not a doctrine

In diversified organizations, decentralization often starts as the default because it aligns with how the business creates value. Local businesses understand their customers, markets, regulatory environments, and operating realities, and giving them decision rights can increase speed and accountability.

In Krebs’ experience, the default model often leaned toward decentralization, he says, with the belief that optimizing for customers and markets would allow different businesses to be as responsive as possible to the specific customers and markets they served. But that logic isn’t complete. Leaders also need to ask whether there’s a compelling case where a more centralized approach can generate additional value, accelerate progress, or optimize investments.

Digital transformation created one of those moments. Krebs recalls around 2016 when Koch challenged its businesses to build multi-year digital transformation roadmaps. The ambition was there, but the capabilities to execute at the necessary pace weren’t evenly distributed. In response, the organization invested more aggressively from the center, building shared services and centers of expertise in areas such as business transformation, enterprise applications, and data and analytics.

The purpose was acceleration, not control. Centralizing those capabilities helped accelerate learnings, capability building, and their ability to deploy new solutions at scale. But the move wasn’t treated as permanent. “There was always a belief that the centralization push should be re-looked at on a regular basis, not thought of as a forever decision,” he says.

Know what belongs at the center

Over time, Krebs learned that  the capabilities most likely to remain centralized were those where scale, consistency, and risk management mattered more than local differentiation. Infrastructure, collaboration platforms, cybersecurity, cloud management, FinOps, and the help desk were natural candidates to remain shared services.

Other areas were more nuanced. Some application capabilities moved back into the businesses as local maturity increased. Many data and insights capabilities also moved closer to the business once teams had built enough muscle to own them. Meanwhile, certain emerging capabilities such as spatial technologies like AR/VR remained centralized because it didn’t yet make sense for each business to build them independently. Many companies have lived this journey as well, for example, with gen AI, which often started with a center of excellence, and then evolved into a more decentralized approach, enabling teams across the business to innovate quickly.

That distinction avoids the trap of treating the enterprise as one uniform operating model. “Both models can be successful, and both have advantages,” he says. “That’s what makes the balance so difficult.”

Centralization provides a clearer path to execution at scale and cleaner decision rights, but it requires change management and careful attention to bureaucracy. Decentralization provides ownership and speed, but it can also over index toward preference versus real differentiation, he adds, while making architecture harder to scale later.

Don’t confuse standardization with centralization

One of the most important distinctions Krebs makes is between centralization and standardization. Many organizations treat them as interchangeable, but they’re not.

“You can have a centralized team that can manage the nuances of different requirements,” Krebs says. “You can also have a centralized standard platform that can be used in a decentralized manner.”

That distinction opens up more operating model choices. A company may centralize a platform but decentralize how business teams configure or use it. It may standardize process patterns while keeping execution close to the region or business unit. It may also centralize architectural governance while allowing local teams to move quickly within defined guardrails.

This is especially important in global organizations, where regional needs are real but not always unique. Krebs advises leaders to examine whether local requirements can be made more generic and reusable. The risk is solving each local requirement as a one-off, so the better path is to understand the underlying requirement, build it in a way that can scale, and still allow local teams to execute within the standard model.

Let business architecture lead technology architecture

Few topics expose the centralization tension more clearly than ERP consolidation. Many diversified companies, particularly those shaped by acquisition, end up with dozens or hundreds of ERP instances. Some leaders push for massive consolidation. Others prefer to build integration layers on top of the existing environment.

Krebs’s starting point is neither technology nor cost. It’s business architecture. “The easiest and most effective path is when the IT or systems architecture follows and aligns to the business architecture,” he says.

If the business is truly going to operate processes separately, separate systems may be appropriate. But if the organization has numerous teams, processes, and tools, leaders need to ask whether there’s enough differentiation and value to justify that complexity.

The same logic applies to M&A. Companies can get into trouble when integration synergies are held hostage by ERP migration timelines. Instead, Krebs advises starting with the business integration strategy. Understand where the synergies are, how the business architecture should come together, and then decide whether the IT architecture needs to be fully integrated, or whether a data layer, reporting platform, or other integration approach can deliver value faster.

Make the cost of complexity visible

CIOs in decentralized companies often face a frustrating dynamic. The business wants autonomy and speed, but the same leadership team still questions why IT spend is high relative to benchmarks. Krebs says the answer starts with cost alignment and visibility.

In environments with a mix of centralized and decentralized services, Krebs saw centralized capabilities like infrastructure, help desk, and security perform well on benchmarks. More decentralized areas, such as BI, reporting, and commercial applications, often had more redundancy and higher cost.

The point isn’t to blame the business but make the economics of complexity visible. CIOs need to show how flexibility in one area may require multiple systems, data stores, or teams elsewhere. “I understand we want flexibility here,” Krebs says. “But leaders must see when that flexibility may cost the company money, and be clear on whether the value justifies it.”

That shifts the conversation from IT cost to business service economics. A single aggregate IT spend number is rarely useful in a decentralized environment. More helpful is a capability-based view that shows which areas are scaled efficiently, which are fragmented, and where the business architecture is driving the technology cost structure.

Revisit the model as maturity changes

For a new CIO entering a decentralized environment, Krebs cautions against immediately declaring that too many things need to be centralized. The better starting point is curiosity. “I would begin with just trying to understand why they’ve made the decisions they have,” he says.

From there, CIOs can engage leaders in a conversation about the target operating model, connecting business architecture to technology, data, and organizational capabilities. Once the direction is clear, he advises CIOs to work with the willing. Find the parts of the organization that already see the need for change, prove the model there, and scale from demonstrated success.

Regardless of execution, though, the right model changes over time. A low-maturity capability may benefit from centralization because the organization needs to build talent, avoid reinventing the wheel, and accelerate learning. As maturity grows, decentralization may make more sense because business teams need flexibility to adapt quickly. Once maturity is high and patterns stabilize, the organization may be ready to centralize again to leverage scale.

“Once I’ve decided I’m going to start with centralized or decentralized, you don’t necessarily need to stay in that model,” Krebs says. “You need to be continually revisiting the operating model as your organization matures and evolves.”

That may be the heart of smart centralization. It rejects the false permanence of operating model decisions, and recognizes that autonomy and scale are both valuable, but in different places, at different times, for different reasons.

Somewhere in the last eighteen months, “AI agent” stopped being a useful term. CIOs may even be afraid to ask what “agent” truly means, as it now seems to describe everything from a chatbot that answers HR questions to an autonomous research system that plans its own week of work. When a single phrase carries that much weight, well, it stops carrying any.

I’ve spent the last three years inside hundreds of enterprise AI deployments, and the factor that separates the programs scaling elegantly from the ones still shuffling is often the CIO’s architectural fluency: The ability to look at business problems across the organization and recognize, on sight, what kind of AI architecture is the right fit. In my experience there are six archetypes, each with their own nuances, that CIOs should internalize to make well-informed decisions going forward.

1. The conversational assistant

The first, and the one most enterprises meet first, is the conversational assistant: The chat-based partner that an employee or customer opens when they want to think out loud. Deloitte found that 38% of organizations report AI is already strengthening their client or customer relationships. This is the architecture people fall in love with: A well-designed assistant with constantly updated information, persistent user-level memory, tools that can act on behalf of users, and citations on every factual claim becomes a useful problem-solver that’s available at any hour of the day.

A global law firm I work with deployed an internal assistant that gives every attorney instant access to the firm’s accumulated precedent, memos and prior matter work. Associates who used to spend the first hour of a research task hunting through document management systems now start with a grounded, citation-backed answer and refine from there. This helped the firm’s institutional knowledge, previously locked in the heads of senior partners, become queryable by anyone with a deadline at 11 p.m., or later.

A second example: A mid-market wealth management firm built a client-facing assistant that handles portfolio questions, statement explanations and routine servicing requests. The assistant draws from each client’s actual holdings, recent activity and the firm’s published market commentary, with citations linking back to source documents. Advisors stopped being interrupted for the questions that didn’t require an advisor, and clients got answers on a Sunday.

2. The triggered workflow

Another pattern producing the value across the enterprises I work with is something that runs silently: An email arrives, a ticket is created, a file lands in a folder and the agent executes a process utilizing both reasoning and determinism. These agents don’t even require user adoption, because they’re invisible to the end user. They produce measurable outcomes, but fit cleanly into the audit and change-control processes IT teams have run for decades.

A commercial insurer I advise built a triggered workflow for inbound submissions. Every broker email that arrives at the underwriting inbox is classified by line of business, the attachments are parsed, key risk fields are extracted into the policy administration system, and a draft acknowledgment is queued for the underwriter’s review. Seemingly overnight, the inbox began arriving pre-sorted, and submission throughput rose meaningfully without any change to headcount.

Another example, this time from a private equity firm: Every inbound confidential information memorandum (CIM) that hits the deal team’s shared inbox triggers a workflow that extracts the financial summary, screens it against the firm’s investment criteria, drafts a preliminary memo and posts the result into the deal-tracking system. Associates still make the call on what to pursue, but the first three hours of manual work on each opportunity now happen before anyone even opens the file.

3. The autonomous agent — with sub-agents

Here we have the architecture that gets the most conference attention: The autonomous agent, given a task and left to plan its own steps by utilizing its own sub-agents. Autonomous agents are not one-size-fits-all, but they do meet a specific need: Multi-source research, complex cross-system lookups, deep-dive investigations. All of these are processes where the path isn’t usually specified in advance, but the tools are. With the right design discipline, an autonomous agent feels like having a self-sufficient teammate who can call in the right resources and specialists if needed.

A global consulting firm I work with uses an autonomous research agent for early-stage engagement scoping. Given a target company and a strategic question, the agent decides for itself which sub-agents to consult (choosing from internal proprietary databases, prior engagement archives, licensed market data, public filings) and produces a structured briefing with its reasoning chain attached.

Another large technology company I know of deployed an autonomous agent for cross-system incident investigation. When a production alert fires, the agent forms a hypothesis, queries the necessary sub-agents with relevant monitoring tools, log stores and deployment systems, and follows the trail until it reaches a defensible root-cause summary to surface to an engineer.

4. The multi-agent team

The fourth pattern is where the next wave of enterprise quality gains is going to come from. According to Databricks, usage of multi-agent systems grew 327% in just four months as enterprises moved beyond single chatbots. Several specialized agents, each with its own role and toolset, coordinate through a shared protocol: A researcher and a writer, a planner and a set of executors, a proposer and a critic. The proposer-critic feedback loop is one of the smartest techniques in agent design today. One model produces an answer; a second, with a different prompt and often a different provider, evaluates it against explicit criteria. For compliance review, contract analysis, high-stakes classification and any output that will be audited, this second pass is extremely helpful and mirrors how human teams work.

A global bank I work with uses a multi-agent system for marketing and communications review. One agent drafts client-facing copy, a second checks it against the firm’s regulatory and brand guidelines and a third checks it against jurisdiction-specific disclosure rules. Disagreements among the agents are surfaced to a human reviewer with the specific clauses flagged. The compliance team stopped being the bottleneck on every routine piece of copy and started focusing on the high-judgment cases instead.

The next example: A pharmaceutical company built a multi-agent workflow for medical literature summarization. A retriever agent gathers candidate studies, a reader agent extracts study design and findings, a critic agent challenges the reader’s claims against the source text, and a synthesizer agent composes the final brief. The proposer-critic loop in the middle is the reason the medical affairs team trusts the output enough to act on it.

5. The human-in-the-loop (HITL) agent

The fifth pattern is the one I think we’ll see increasingly more of in the future. While many see “full automation” as the goal, the right target is actually to let the agent handle the 80% of a task that is mechanical, while preserving human judgment at the most critical moments. This is achievable via human-in-the-loop (HITL) agents. According to Moody’s, 42% of compliance professionals believe that human oversight is mandatory, and I agree: AI should run right, by getting approval and review before any sensitive business action is taken. HITL is the architecture that can help turn a skeptical team into an enthusiastic one.

A regional health system I worked with uses a HITL agent for prior-authorization letters. The agent assembles the clinical evidence, drafts the letter against the relevant payer’s criteria, and routes it to a nurse case manager for review inside the existing workflow tool. The nurse approves, edits or rejects in seconds rather than minutes, and every edit helps make the next draft better.

A property management company uses a HITL agent to run its maintenance work orders. When a tenant emails about a problem (an HVAC unit that died overnight, say), the agent pulls the structured details (tenant, unit, issue type, urgency), matches the job to the right vendor from the directory, and drafts the work order. A team member approves it in Slack before anything goes out. From there the agent emails the vendor with the full order, confirms with the tenant that someone is on the way and updates Airtable, closing the loop completely.

6. The scheduled agent

On a set schedule or against a batch of inputs, this agent runs the same defined task: Produce a report, refresh a dataset, monitor a set of sources or summarize a period of activity. Under this archetype, unsexy work gets done consistently, integrated into existing operational rhythms like the Monday morning meeting, the daily standup and the monthly board deck, without asking anyone to change their behavior. This is the architecture that shifts AI from feeling like even more work, to a seamless teammate that just works.

A private equity firm I work with runs a scheduled agent every Monday at 6 a.m. that monitors news, filings and earnings activity across every portfolio company and produces a single PDF that lands in the deal partners’ inboxes before the weekly investment meeting. No one logs into a dashboard. The agent shows up, on time, with the same format every week, and the meeting now starts from a shared baseline rather than from whatever each partner happened to read over the weekend.

A second example: A global manufacturer runs a nightly batch agent that ingests the day’s quality-control reports across plants, summarizes anomalies against a rolling baseline, and produces an end-of-shift handoff document for each site lead’s morning. The agent doesn’t flag emergencies, but it ensures that the slow-moving patterns no human would catch reading one shift’s data in isolation get surfaced.

Bringing it together

None of these six archetypes is more advanced than the others or inherently better. But CIOs can have an edge by choosing the one that the operational problem actually calls for.

Before you scope a single deployment, you should be able to look at a business problem and name its shape: Is this a question someone needs answered in the moment, or a process that should run the instant a trigger fires? Does the path need to be discovered, or is it known in advance and just waiting to be executed? Where, exactly, does human judgment have to stay in the loop, and where is it just friction?

Going forward, CIOs should start treating the architecture decision as the first design choice. Everything downstream — adoption, governance, trust — only gets easier if the architecture is the right fit.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

Microsoft addressed 722 CVEs this month once the 427 Chromium upstream relays are set aside — roughly three times a normal cycle and one of the largest single months in recent memory. Two vulnerabilities arrive under active exploitation: an elevation of privilege in Active Directory Federation Services (CVE-2026-56155), and an elevation of privilege in SharePoint Server (CVE-2026-56164). A third, a BitLocker security feature bypass (CVE-2026-50661) is publicly disclosed but not yet exploited.

The July 2026 Patch Tuesday earns Patch Now recommendations for Windows, Office, Exchange, and SQL Server. SharePoint has two critical RCEs on top of its exploited zero-day, and Exchange Server returns with a critical on-premises spoofing flaw. Adding to our (dear) administrator’s efforts, SharePoint Server 2016/2019 and SQL Server 2016 all reach end of support today. The Readiness team has provided a handy infographic of the expected risk profile of this month’s Patch Tuesday updates.

Known issues

The July release note flags known issues against the following updates:

• BitLocker recovery prompt on first restart – the PCR7 recovery condition tracked since April remains live on the platforms that did not receive the Boot Manager servicing fix (Windows Server 2022 and Windows 10 22H2). Devices with BitLocker on the OS drive, the Group Policy “Configure TPM platform validation profile for native UEFI firmware configurations” set with PCR7 included, and Secure Boot State PCR7 Binding reported as “Not Possible” may be prompted for the recovery key on the first restart after installing this update. This month’s publicly disclosed BitLocker security feature bypass (CVE-2026-50661) keeps the component in focus.

• WSUS synchronization error details suppressed (Windows Server 2025 and 2022) – WSUS no longer displays synchronization error details in its error reporting, a deliberate change made to address the Remote Code Execution Vulnerability CVE-2025-59287. Sync still works, but administrators triaging a failed synchronization lose the detail pane and must fall back to the SoftwareDistribution logs.

Windows Update can still replace manually installed graphics drivers with older OEM versions from the catalogue (the four-part Hardware ID ranking issue acknowledged on the Hardware Dev Center). The two-part HWID pilot runs to September 2026.

Major revisions and mitigations

Between the June and July Patch Tuesdays, MSRC Security Update Guide notices updated 651 reported CVEs across six notification dates (15, 19, 26 June and 3, 8, 11 July), 532 of them routine Chromium upstream re-publications. Of the roughly 30 Microsoft revisions, almost all were cross-platform Office catch-up with no bearing on a Windows enterprise estate. No further action required for IT administrators for this Windows update cycle.

Windows lifecycle and enforcement updates

This is the deadline cycle June pointed at. The July end-of-support wave lands today, and it collides with the month’s heaviest patching. SharePoint and SQL Server take some of their most active security updates ever on platforms receiving their last.

• SharePoint Server 2016 and 2019, Project Server 2016 and 2019, SQL Server 2016 and InfoPath 2013 have all reached end of support. SQL Server 2014 ESU Year 2 reaches end of support today. SharePoint 2016/2019 take an actively exploited zero-day and two RCEs this cycle, and SQL Server 2016 takes a critical RCE, all as their final security update. Now is the time to get moving on updating these platforms.

The 2011 Secure Boot certificate expiries have now passed; devices that never took the Windows UEFI CA 2023 key updates under CVE-2023-24932 can no longer receive updated boot components, with the Windows Production PCA for the boot manager still ahead on 19 October 2026. Kerberos RC4 hardening (CVE-2026-20833) has been in enforcement since April 2026; the July 2026 update removes the RC4DefaultDisablementPhase rollback control that let administrators defer it, making enforcement final.

Microsoft’s July 2026 Patch Tuesday is a security-only release: 180 test-guidance entries, 14 of them high risk (June had one). Printing and graphics are the centre of gravity: win32kfull.sys, the kernel-mode window manager, is the most-patched binary (14 entries), and seven high-risk flags sit alongside it – the Print Spooler, four win32k entries, and two GDI+ metafile entries. NTFS is the second theme, with 10 entries, two high risk. Every entry reports no functional changes – it’s pure regression validation. The packages span Windows 11 26H1 back to Server 2012 ESU.

Printing and graphics (high risk)

The Print Spooler flag centres on shared printers, whose queue status must track jobs accurately; the win32k flags cover 32-bit application printing, font rendering in printed and exported output, on-screen rendering, and window management; the GDI+ flags cover metafiles.

• Share a printer from a print server, print from a separate client in varied sizes and formats, and cancel a job, confirming the queue reflects every state change
• Print from your 32-bit applications, and print text-heavy, graphics-heavy, and multi-page documents to physical and virtual (PDF or XPS) printers, repeating after orientation, scaling, and resolution changes
• Export documents with varied fonts to PDF and confirm fonts and layout survive; render EMF+ files that apply effects to very large images, and convert EMF files to WMF
• Open and close windows rapidly, drive common dialogs by mouse and keyboard, and close parents with children open – no orphaned windows

Storage and file systems (high risk)

Both NTFS high-risk flags target integrity – extended attributes, and volume recovery after an unexpected shutdown. File History carries its own high-risk flag on clients. A Windows Server 2025-only bundle across boot, BitLocker, and ReFS demands the full Secure Boot/BitLocker matrix. Eight entries hit Server 2025 alone, including WSL, GPU partitioning, and a scripted Windows Server Backup pass repeating recovery after rolling the date 90 days forward.

• Exercise NTFS extended attributes – older-system EAs, backup workflows that preserve them, concurrent same-file operations where supported – with antivirus, encryption, or storage filters active
• Simulate an unexpected shutdown during file activity, verify the volume mounts intact, run chkdsk, and confirm indexing, shadow copies, and backup still work
• Run a full File History pass: back up, modify and back up again, exclude folders, change frequency, move the destination
• On Server 2025, boot all four Secure Boot/BitLocker combinations, in standard and confidential VMs where supported

Devices, input and networking (high risk)

Three further high-risk flags land here: HID input (hidparse.sys with win32k) – touch, keyboard, mouse, touchpad, through disconnects and restarts; the WinSock bundle (afd.sys plus Bluetooth and multicast drivers); and IrDA. The heaviest ask is not high risk at all: the NetAdapterCx driver (24H2/25H2, Server 2025) wants 500-plus adapter enable-disable cycles under Driver Verifier.

• Run the connectivity suite: browsing, large downloads, mapped drives, an RDP session idle 30+ minutes, a Teams call, an hour of streaming, and localhost apps such as Docker or WSL
• Stress Bluetooth: pairing, 10+ minutes of audio, input after idle, and reconnection after sleep
• Where infrared hardware exists, transfer a file and run at least 100 connect-disconnect cycles
• Sweep the rest: DNS Server (zone data must stay under its configured database directory), the client resolver (five entries), DHCP Server (five entries), SMB, NFS, Message Queuing (five entries), RRAS administration, client VPN, and WinHTTP/WinINet consumers

Other windows components

Windows Installer itself is patched: testing should include application install, uninstall, repair, and force a rollback. Hyper-V wants virtual-switch traffic as part of its testing exercises with Virtual Filtering Platform policies enforced. Sixteen media-related security entries cover playback, HEVC and MPEG-TS, USB audio, and MIDI 2.0.

Shell hardening and LSA isolation

These two entries are a little different from the rest of the cycle: they ask you to confirm a security behaviour actively works, not just that nothing regressed. A pass here means the protection fired, so treat them as functional checks rather than box-ticking.

• Shortcut handling (windows.storage.dll; Windows 11 23H2 and earlier, plus Server 2022): drop a shortcut file carrying the Mark of the Web into a folder and confirm the system refuses to extract its icon and leaks no NTLM credential hash – include the zero-click paths, where the icon would otherwise render without you opening anything
• LSA isolation and KeyGuard (24H2/25H2, Server 2025): run the supplied PowerShell validation script, which turns on Virtualization-based Security if it isn’t already, exercises KeyGuard key operations in both required and best-effort isolation modes, and reports pass or fail – it needs TPM 2.0, UEFI with Secure Boot disabled, and PowerShell 7
• Run that script on a dedicated test machine, never a shared one: it enables test signing, disables automatic updates, and reboots without asking

Office & SharePoint

July’s Office wave is security-only; everything landed on 14 July, and nothing critical or non-security shipped in the 7 July preview. It’s an MSI-only cycle, so Click-to-Run estates can sit this one out.

• On MSI Office 2016, apply the client updates – Excel (KB5002886), Word (KB5002890), PowerPoint (KB5002867), and five further Office 2016 security updates (KB5002273, KB5002887, KB5002748, KB5002857, KB5002830) – then exercise macros, external data, embedded objects, and any line-of-business add-ins
• On SharePoint Server, patch 2016 (KB5002891, plus the KB5002892 language pack) and Subscription Edition (KB5002882), then check browser-based editing; the guidance lists SharePoint 2019 with a baseline but ships no 2019 package, so there is nothing to install there

Mind the rollback rules before you schedule the window: most client updates can be uninstalled, but the server updates cannot and always require a reboot.

Developer tools & databases

The developer estate gets a broad but low-drama sweep this month. Both .NET and SQL Server patch widely, but the ask is representative-application validation rather than anything exotic – install on the matching branch and confirm normal behaviour.

• .NET: install the SDK updates (8.0.423, 9.0.316, 10.0.302, x64 and x86) and the Framework rollups spanning 3.5 through 4.8.1 – which reach from Windows Server 2012 up to Windows 11 26H1 and Server 2025 – then run a representative set of applications and confirm they function normally
• SQL Server: the GDR updates span 2016 SP3 through 2025 – install each on its matching branch and test that each removes cleanly
• Check an encrypted client connection through the separately patched Windows SQL client (dbnetlib.dll), which ships outside the server branches

The Readiness team recommends the following priorities for your larger enterprise deployments:

• Start with printing and graphics: half the high-risk flags sit in the Print Spooler, win32k, and GDI+, so regress shared printers, 32-bit printing, PDF export, metafiles, and window management before anything else
• Take NTFS next – extended attributes and crash recovery both touch data integrity – and add a client File History backup-and-restore pass
• Give Server 2025 its wider matrix – the Secure Boot/BitLocker combinations, WSL, GPU partitioning, and the scripted backup pass – and work through the stress suites
• Run the scripted KeyGuard validation on any VBS estate, preferably on a dedicated machine.

Each month, we break down the update cycle into product families (as defined by Microsoft) with the following basic groupings:

• Browsers (Microsoft IE and Edge)
• Microsoft Windows (both desktop and server)
• Microsoft Office
• Microsoft Exchange and SQL Server
• Microsoft Developer Tools (Visual Studio and .NET)
• Adobe (if you get this far)

Browsers

Edge has had a busier month than usual. Microsoft addressed 46 Microsoft Edge (Chromium-based) CVEs this cycle. None critical, but heavily weighted to remote code execution (21 entries) and spoofing (13), led by CVE-2026-58289, a remote code execution flaw. A run of further RCEs (CVE-2026-57981, CVE-2026-56645, CVE-2026-57974) follows.

• Microsoft Edge – the Edge-specific fixes ship in the Edge stable channel (version 150.0.4078.65, released 9 July). The concentration of RCE and spoofing this month is worth a look for managed Edge estates rather than a routine wave-through.
• Chromium upstream – 427 CVEs relayed through MSRC this cycle, spanning the weekly Chrome release cadence since the June report: use-after-free, out-of-bounds read/write, type confusion, and inappropriate-implementation flaws across V8, Dawn, ANGLE, Skia, and Tint. The same fixes ship in the Chrome Stable channel; see the Chrome releases blog for the upstream notes.

The Chromium volume looks (quite) alarming but is routine plumbing: it flows to Edge through its own auto-update channel. Add these browser (Edge) updates to your standard release schedule for your managed environments.

Microsoft Windows

Windows carries the bulk of this month’s updates: 406 CVEs, 31 rated critical and 374 important. Elevation of privilege dominates by volume (226 entries), followed by remote code execution (70), information disclosure (70), denial of service (23), and a scatter of security-feature-bypass, tampering, and spoofing entries across the following feature groupings:

• DHCP – the standout network cluster: DHCP Server remote code execution (CVE-2026-50518, “Exploitation More Likely,” and CVE-2026-56159), with further critical DHCP Server and DHCP Client RCEs behind them (CVE-2026-48564, CVE-2026-50370, CVE-2026-54128). DHCP servers are the deployment priority.
• VMSwitch and Hyper-V – the Windows VMSwitch elevation of privilege (CVE-2026-57092) is one of the month’s highest-severity flaws, joined by two critical Hyper-V elevation-of-privilege entries (CVE-2026-50680, CVE-2026-54127), guest-to-host risk on virtualisation hosts.
• Network stack RCE – a Windows Server Network driver RCE (CVE-2026-56188, “Exploitation More Likely”), plus TCP/IP (CVE-2026-54999), the Reliable Multicast Transport Driver (CVE-2026-54982), and SSTP (CVE-2026-50694).
• Graphics – Windows GDI+ remote code execution (CVE-2026-50380) and a DirectX Graphics Kernel RCE (CVE-2026-50382), both reachable through document-rendering paths.
• Windows Media – a large cluster: three critical Media Foundation RCEs (CVE-2026-57090, CVE-2026-57094, CVE-2026-57087) lead 14 Windows Media and seven Media Foundation entries overall.
• Identity infrastructure – beyond the exploited ADFS flaw, Active Directory Domain Services takes a critical RCE (CVE-2026-49164) and Active Directory Certificate Services a critical elevation of privilege (CVE-2026-54121). Domain controllers take priority again.
• Print Spooler, WSUS, and MSMQ – critical RCE/EoP in the Print Spooler (CVE-2026-58608), Windows Server Update Services (CVE-2026-50444), and Message Queuing (CVE-2026-54992, “Exploitation More Likely”), all server-role attack surface.

The Windows Kernel is the most-patched component (28 CVEs, seven “More Likely”), followed by NTFS (21), Windows Runtime (17), Windows Media (14), ReFS (12), and Win32k (15 across its two entries). Add this Windows update to your Patch Now deployment schedule.

Microsoft Office

Microsoft released 96 Office CVEs this month: 19 critical, 76 important. Remote code execution leads (53 entries), ahead of information disclosure (27) and spoofing (10). SharePoint is the centre of gravity: it touches 39 of the 96 CVEs and supplies the family’s one actively exploited flaw.

• SharePoint Server: has been exploited (who would have guessed) and reaches end of support today. CVE-2026-56164, an elevation of privilege, is under active exploitation. Above it sit two critical remote code execution flaws, both “Exploitation More Likely” (CVE-2026-50522, CVE-2026-58644) and a critical security feature bypass (CVE-2026-55040). SharePoint Server 2016 and 2019 reach end of support on 14 July, so this exploited, critical-heavy set is the final security update those on-premises farms will receive.
• Office has experienced a long run of critical remote code execution entries across Office, Word, and PowerPoint (among them CVE-2026-55033 and CVE-2026-55127 in Word, CVE-2026-55043 in PowerPoint, and CVE-2026-55018 in Office), topped by CVE-2026-55045.

With an exploited zero-day, two RCEs, and an end-of-support deadline all landing on SharePoint in the same cycle, SharePoint environments are the priority. Add the July Office and SharePoint updates to your Patch Now schedule.

Microsoft Exchange and SQL Server

Both Exchange and SQL Server carry critical-rated security vulnerabilities this month. Exchange Server returns with an on-premises security update for Exchange Server Subscription Edition, the only on-premises release still supported after Exchange Server 2016 and 2019 reached end of support in October 2025; SQL Server takes two critical remote code execution flaws, one of them against SQL Server 2016, which reaches end of support on the same day.

• Exchange Server (on-premises) – CVE-2026-55008, a spoofing vulnerability rated critical and “Exploitation More Likely,” is the headline. Behind it, a remote code execution entry (CVE-2026-55005) and two elevation-of-privilege flaws (CVE-2026-55006, CVE-2026-55009) round out the on-premises set. A separate Exchange Online elevation of privilege (CVE-2026-54998, critical) is fixed service-side with no customer action.
• SQL Server – two critical remote code execution flaws: CVE-2026-54117 (SQL Server 2025) and CVE-2026-54118 (which reaches back to SQL Server 2016 SP3), with five further important elevation-of-privilege and information-disclosure entries behind them. The 2016 exposure matters because SQL Server 2016 reaches end of support on 14 July: a critical RCE on a platform taking its final update.

Both belong on the Patch Now schedule this month: the Exchange on-premises update for its critical spoofing flaw, and the SQL Server update for the two critical RCEs.

Microsoft developer tools

Microsoft released 24 CVEs across its developer tooling this month, all rated important. The weighting shifts from last month’s Visual Studio Code concentration toward .NET and ASP.NET Core, where a run of denial-of-service entries dominates the volume:

• ASP.NET Core and .NET – the two highest-severity entries are ASP.NET Core elevation-of-privilege entries (CVE-2026-47300, CVE-2026-47303), ahead of a .NET security feature bypass (CVE-2026-50528) and two .NET / .NET Framework remote code execution flaws (CVE-2026-50646, CVE-2026-50649).
• Visual Studio and VS Code – a GitHub Copilot / Visual Studio Code security feature bypass (CVE-2026-41109) and a second VS Code security feature bypass (CVE-2026-57102) lead here, with a VS Code remote code execution entry behind them (CVE-2026-50520) and a Visual Studio RCE (CVE-2026-47305).

Add these Microsoft updates to your standard developer update release schedule.

Adobe (and third-party updates)

Outside Microsoft’s own catalogue, July is quiet. Adobe issued no Acrobat or Reader security updates. So, the month belongs to Microsoft, and it is a heavy one: 722 CVEs, roughly three times a normal cycle and one of the largest on record. Worth noting that this lands in the same season Microsoft has been talking up AI-assisted vulnerability management, and the AI stack it is selling as the answer, Copilot and Azure OpenAI among them, sits in the centre of this patch cycle’s own critical-rated updates. The (AI) tooling may be getting smarter, but the patch pile is (definitely) not getting smaller. This may be the beginning of an accelerating curve of ever larger patch cycles. My feeling is that we are in the middle of the beginning of this coming patch surge.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

DC Studio | shutterstock.com

KI-Agenten und die Large Language Models (LLMs), auf denen sie basieren, haben ein eher kurzlebiges „Gedächtnis“. Das ist so gewollt, schließlich kann nur eine begrenzte Menge an Konversationsinhalten in Token kodiert und vom LLM zuverlässig abgerufen werden. Um KI-Agenten und Sprachmodelle mit „Hirnschmalz“ auszustatten, das über ihre Kontextfenster hinausreicht, lässt sich Retrieval Augmented Generation (RAG) einsetzen. Erfolgsentscheidend ist dabei, wie dieser Mechanismus (oder ein anderer, um Gesprächsdaten vorzuhalten) konkret zur Anwendung kommt.

Ein anderer Weg, sowohl KI-Agenten als auch LLMs mit erweiterten Speicherfähigkeiten auszustatten, führt über Software-Tools von Drittanbietern. Diese können die KI mit einer Session-übergreifenden, persistenten Memory ausstatten. Auch hier variiert jedoch die Art und Weise, wie das technisch umgesetzt wird. Die folgenden vier Projekte sind besonders empfehlenswert, wenn es darum geht, KI-Agenten und Sprachmodelle smarter zu machen.    

1. Graphiti

Graphiti wird als „das Open-Source-Framework für temporale Knowledge-Graphen“ beworben. Das Projekt ist auf GitHub verfügbar – oder auch im Rahmen des Memory-Service Zep, für den es die Grundlage liefert. „Temporal“ bedeutet in diesem Zusammenhang, dass die in Graphiti gespeicherten Informationen im Laufe der Zeit reevaluiert werden, um den Kontext korrekt einzubetten. Der Begriff „Graph-Framework“ ist hingegen darauf zurückzuführen, dass die Daten dabei als eine Reihe von Graphen gespeichert werden. Dieses Feature spielt auch bei den anderen in diesem Artikel vorgestellten Lösungen eine Rolle – im Fall von Graphiti steht es allerdings im Fokus.

Out of the Box unterstützt das KI-Memory-Projekt eine ganze Reihe gängiger LLMs, etwa von Anthropic, OpenAI, Google oder X. Auch sämtliche Ollama- und OpenAI-kompatiblen APIs funktionieren mit Graphiti – es kann also auch mit lokal gehosteten LLMs genutzt werden. Daten aus Quellen wie GitHub, Gmail und OneDrive sowie aus Anwendungen wie Notion lassen sich über Konnektoren einbinden.

Um Graphiti lokal nutzen zu können, ist es allerdings nötig, eine Graphdatenbank einzurichten oder eine Verbindung zu einer solchen herzustellen. Die Standardlösung dafür (mit dem breitesten Support) ist Neo4j. Davon abgesehen, funktionieren auch Amazon Neptune, FalkorDB und KuzuDB. Postgres mit pgvector ist (derzeit) hingegen keine Option bei Graphiti.

2. Hindsight

Das KI-Memory-Projekt Hindsight als Cloud Service verfügbar, kann jedoch auch lokal gehostet werden. Dieses Tool speichert Details zu Agenten-Sitzungen in vier verschiedenen Memory-Instanzen und wendet dabei vier unterschiedliche Storage- und Retrieval-Strategien an. Diese werden über drei programmatische Interfaces gehändelt:

• retain, um Inhalte (einzelne Fakten oder komplette Sessions) zu speichern,
• recall, um den Content abzurufen, und
• reflect, um einen Agenten-Loop über eine Abfrage zu initiieren, die zuvor gespeicherte Daten nutzt.

In Sachen Integrationen hat Hindsight eine breite Palette von First- und Third-Party-Optionen zu bieten. Wenn Sie beispielsweise die „Continue“-Erweiterung mit Visual Studio Code einsetzen, um mit einem lokal gehosteten LLM zu kommunizieren, können Sie die entsprechende First-Party-Integration nutzen. In diesem Fall verwenden Sie einfach das Keyword @hindsight in der Query, um den Agenten-Kontext um relevante Memory zu erweitern. Um sich die Arbeit zu erleichtern, respektive diese zu automatisieren, könnten Sie außerdem auch auf (anpassbare) Auto-Injection-Regeln zurückgreifen.

3. Mem0

Wie Hindsight nutzt auch Mem0 vier grundlegende Memory-Typen – allerdings sind diese anders benannt und organisiert. Beispielsweise kommt im Fall von Mem0 die sogenannte „Organizational Memory“ zum Einsatz, um Daten zu speichern, die zwischen verschiedenen KI-Agenten(-Teams) geteilt werden sollen.

Jede Form von Memory, die über Mem0 hinzugefügt wird, durchläuft einen „Destillationsprozess“ und wird auf unterschiedliche Art und Weise (Vektor-, Graph- oder SQL-Datenbank) gespeichert. Ältere Daten werden bei Mem0 nicht gelöscht, sondern als veraltet markiert – eine Strategie, um einen umfassenderen, längerfristigen Kontext zu erzeugen.

Das Projekt unterstützt im Vergleich – etwa zu Hindsight – weniger LLMs, die wichtigen Anbieter (Anthropic, Google, OpenAI) sind jedoch vertreten. Dazu kommen Self-Hosting-Optionen über LangChain, LiteLLM, LM Studio und Ollama. Falls Sie Mem0 lokal statt als Service nutzen möchten, ist es nötig, eine Python-Instanz und eine eigene Vektordatenbank bereitzustellen. Für Letzteres ist Postgres mit der pgvector-Erweiterung eine gängige und simple Option, die sogar innerhalb einer virtuellen Python-Umgebung installiert werden kann.

4. Supermemory

Supermemory erfasst Daten aus vielen gängigen Quellen und unterstützt dabei unter anderem Plaintext, strukturierte Daten, PDF- und Office-Dokumente sowie Video-, Audio- und Bilddateien. Aus diesen Informationen erstellt das Tool einen Kontextgraphen, der anschließend als Grundlage für Chatbot-Konversationen fungiert. PR-mäßig setzt dieses Projekt den Fokus vor allem auf seine Context-Extraktions-Tools.

Supermemory ist entweder als Cloud-Dienst oder als quelloffene, lokal ausführbare Software verfügbar. Die Open-Source-Version lässt zwar die Scaling Services und Drittanbieter-Konnektoren der Enterprise-Version vermissen – hat jedoch einen entscheidenden Vorteil: Sie besteht aus einer einzelnen Self-Contained-Binary. So lässt sie sich auch auf der eigenen Hardware mit sehr überschaubarem Aufwand bereitstellen.

Da für dieses Projekt zudem keine externen Datenbanken aufgesetzt werden müssen, eignet es sich in besonderem Maße für (agile) Experimente. (fm)

Dieser Artikel ist im Original bei unserer Schwesterpublikation Infoworld.com erschienen.

Google DeepMind CEO Demis Hassabis is pushing for the US AI industry to self-regulate, with the support of government, as a starting point for an international creating shared international standards. In a blog post, he called for a focus on artificial general intelligence (AGI) and national security. 

But it is precisely that focus on national security that may make the results of such an effort, assuming it happens, less than palatable outside of the US.

“The rapid progress we’re seeing in AI requires a new approach to testing frontier AI model capabilities that is dynamic, adaptable, and rigorous,” Hassabis wrote. “The US is well positioned, given its economic and technical standing, to take the first step in developing such a framework. It could establish a new Standards Body modelled on a federally overseen public-private partnership or self-regulatory organization, much like the Financial Industry Regulatory Authority (FINRA), with a board that includes independent leading technical experts and open-source representatives.”

He noted, however, that the funding would need to be substantial, and would most likely come from industry, to allow the new body to attract world-class technical talent and obtain the necessary compute resources for large-scale testing.

Hassabis proposed that the organization “be responsible for developing assessment protocols and working with appropriate federal agencies and the US National Labs to conduct testing in areas relevant to national security,” and that AI vendor participants be encouraged to adopt best practices such as publishing model cards with technical details, maintaining strong internal cybersecurity, vetting key personnel, and providing sufficient resourcing for safety and security research.

This is not the first time Hassabis has expressed worries about AGI. 

DeepMind was involved in an earlier US government initiative evaluating AI safety, alongside Microsoft and xAI (now SpaceXAI) working with the Center for AI Standards and Innovation (CAISI), a division of the US Department of Commerce. It allowed CAISI to conduct pre-deployment evaluations and targeted research to “better assess frontier AI capabilities and advance the state of AI security.”  

The rest of the world may have concerns

Analysts and consultants were mixed about the move, with most expressing concerns about whether an industry-focused group would prioritize the public’s best interests.

“Self-regulation is not viable because it implies everyone is able to regulate themselves and will do so in line with the best interests of the public. Most tech vendors don’t have the capacity to self-regulate. They would just prefer a set of rules within which they can operate,” said Gartner VP analyst Nader Henein. “For-profit organizations are required to do what is best for their shareholders, and external regulation ensures that those organizations are never in a conflict of interest where they have to choose between what is good for their shareholders and what is good for the public.”

And, said Sanchit Vir Gogia, chief analyst at Greyhound Research, given the international nature of AI models, an effort coordinated by the US government might alienate other countries. 

“National security is the proposal’s accelerator in Washington and its poison pill abroad: the framing that opens the only gate available at home invites foreign capitals to read the institution as an instrument of American strategy,” he pointed out.

“The map is already plural,” he said. “Brussels switches on enforcement powers over general-purpose models [starting in August 2026], London runs the AI Security Institute, and Beijing licenses on its own terms. California and New York have legislated for frontier models at home. The durable route is shared technical evidence with sovereign enforcement, sealed through mutual recognition rather than deference, with India and the other major non-Western markets holding authorship rather than seats.”

Gogia added that the rules enacted by even such a group may not address all of the key concerns of enterprise IT. A US government effort along the lines that Hassabis is proposing would result in testing that “sits close to intelligence and industrial policy, and those functions will not stay neatly separated. A model can pass every catastrophic-risk test and still fail the enterprise on privacy, reliability, and liability,” he noted.

Walmart’s former director of cybersecurity Steven Eric Fisher, who is now an independent cybersecurity consultant, said he found the proposal “well-intentioned, but it addresses a highly polarized topic at a time when commercial interests carry unprecedented political influence, which is not always applied benevolently.”

He added, “an exclusive US standard that is not globally respected or enforceable would likely fail to achieve its core purpose and would place US companies at a competitive disadvantage.”

Aman Mahapatra, chief strategy officer for Tribeca Softtech, a New York City-based technology consulting firm, said that a deep dive into how FINRA operates today is illustrative of what IT leaders can expect from this effort, assuming the industry adopts that model.

“When the CEOs of the five companies that would be regulated are also the primary drafters of the standards, the standards will reflect those companies’ interests. FINRA has an independent board, but the operational reality is that member firm perspectives dominate the working groups that write the actual rules,” he said. “There is no reason to expect an AI equivalent to work differently, and every reason to expect it to work worse, because AI standardization is happening faster than any industry has ever attempted to standardize itself, and speed is the enemy of independent oversight.”

Carmi Levy, an independent technology analyst, was even more emphatically opposed to the Hassabis proposal.

“Asking Big Tech companies to self-police is analogous to allowing foxes to guard the henhouse. It hasn’t worked to date, and it won’t work going forward. Expecting these organizations to somehow change their ways at this point in time represents the height of naïve thinking,” Levy said. “The framework proposed by Demis Hassabis is a self-serving roadmap for an industry bent on racing to the AI horizon regardless of the harms caused along the way. It is impossible to quantify the dangers to broader society should frameworks allowing self-regulation become the norm.”

Some love the proposal

An almost completely opposite stance came from Yuri Goryunov, CIO of consulting firm Acceligence, who applauded the proposed move.

“This is one of the rare setups where industry self-regulation has a real shot, and enterprise IT should be enthusiastically rooting for it,” he said. “It fails when harms are externalized, such as in social media content moderation. Or when the overseer outsources judgment to the overseen, such as the FAA’s delegation to Boeing before the 737 MAX. It works when everyone in the industry shares the catastrophic downside.”

He suggested, however, that the best precedent here isn’t FINRA, it’s INPO, the Institute of Nuclear Power Operations, which the nuclear industry created within months of the 1979 Three Mile Island partial reactor meltdown “on the logic that an accident anywhere is an accident everywhere. INPO peer-reviews every US plant, its evaluations move insurance premiums, and it sits on top of the NRC’s statutory floor. That is a public-private stack very close to what Hassabis is describing. Frontier AI has the same structure: one lab’s catastrophic failure brings regulation down on all of them.”

For enterprise CIOs and other IT executives, Goryunov said, that model has the potential for being a big win.

“Today, every enterprise duplicates the same AI diligence of red-teaming, eval suites, governance committees and each does so with less information than any certifying body would have,” Goryunov said. “A credible standards regime does for AI what UL did for electrical equipment and SOC2 did for cloud: it converts an unknowable risk into a procurable product and gives boards a defensible standard of care. That’s not red tape. That’s peace of mind with an audit trail.”

However, Mahapatra said, “the countervailing view is that the alternative to industry-led standards is probably not thoughtful legislation. It is probably no standards, or state-by-state fragmentation, or the current pattern of ex-post enforcement actions where regulators surface concerns years after harm has already occurred.”

Thus, he noted, “Hassabis is making the reasonable argument that imperfect fast standards are better than perfect slow ones, and there is genuine merit to that view for topics like agent identity, evaluation methodology, and interoperability, which are exactly the areas OpenClaw is also targeting.”

Google DeepMind CEO Demis Hassabis is pushing for the US AI industry to self-regulate, with the support of government, as a starting point for an international creating shared international standards. In a blog post, he called for a focus on artificial general intelligence (AGI) and national security. 

But it is precisely that focus on national security that may make the results of such an effort, assuming it happens, less than palatable outside of the US.

“The rapid progress we’re seeing in AI requires a new approach to testing frontier AI model capabilities that is dynamic, adaptable, and rigorous,” Hassabis wrote. “The US is well positioned, given its economic and technical standing, to take the first step in developing such a framework. It could establish a new Standards Body modelled on a federally overseen public-private partnership or self-regulatory organization, much like the Financial Industry Regulatory Authority (FINRA), with a board that includes independent leading technical experts and open-source representatives.”

He noted, however, that the funding would need to be substantial, and would most likely come from industry, to allow the new body to attract world-class technical talent and obtain the necessary compute resources for large-scale testing.

Hassabis proposed that the organization “be responsible for developing assessment protocols and working with appropriate federal agencies and the US National Labs to conduct testing in areas relevant to national security,” and that AI vendor participants be encouraged to adopt best practices such as publishing model cards with technical details, maintaining strong internal cybersecurity, vetting key personnel, and providing sufficient resourcing for safety and security research.

This is not the first time Hassabis has expressed worries about AGI. 

DeepMind was involved in an earlier US government initiative evaluating AI safety, alongside Microsoft and xAI (now SpaceXAI) working with the Center for AI Standards and Innovation (CAISI), a division of the US Department of Commerce. It allowed CAISI to conduct pre-deployment evaluations and targeted research to “better assess frontier AI capabilities and advance the state of AI security.”  

The rest of the world may have concerns

Analysts and consultants were mixed about the move, with most expressing concerns about whether an industry-focused group would prioritize the public’s best interests.

“Self-regulation is not viable because it implies everyone is able to regulate themselves and will do so in line with the best interests of the public. Most tech vendors don’t have the capacity to self-regulate. They would just prefer a set of rules within which they can operate,” said Gartner VP analyst Nader Henein. “For-profit organizations are required to do what is best for their shareholders, and external regulation ensures that those organizations are never in a conflict of interest where they have to choose between what is good for their shareholders and what is good for the public.”

And, said Sanchit Vir Gogia, chief analyst at Greyhound Research, given the international nature of AI models, an effort coordinated by the US government might alienate other countries. 

“National security is the proposal’s accelerator in Washington and its poison pill abroad: the framing that opens the only gate available at home invites foreign capitals to read the institution as an instrument of American strategy,” he pointed out.

“The map is already plural,” he said. “Brussels switches on enforcement powers over general-purpose models [starting in August 2026], London runs the AI Security Institute, and Beijing licenses on its own terms. California and New York have legislated for frontier models at home. The durable route is shared technical evidence with sovereign enforcement, sealed through mutual recognition rather than deference, with India and the other major non-Western markets holding authorship rather than seats.”

Gogia added that the rules enacted by even such a group may not address all of the key concerns of enterprise IT. A US government effort along the lines that Hassabis is proposing would result in testing that “sits close to intelligence and industrial policy, and those functions will not stay neatly separated. A model can pass every catastrophic-risk test and still fail the enterprise on privacy, reliability, and liability,” he noted.

Walmart’s former director of cybersecurity Steven Eric Fisher, who is now an independent cybersecurity consultant, said he found the proposal “well-intentioned, but it addresses a highly polarized topic at a time when commercial interests carry unprecedented political influence, which is not always applied benevolently.”

He added, “an exclusive US standard that is not globally respected or enforceable would likely fail to achieve its core purpose and would place US companies at a competitive disadvantage.”

Aman Mahapatra, chief strategy officer for Tribeca Softtech, a New York City-based technology consulting firm, said that a deep dive into how FINRA operates today is illustrative of what IT leaders can expect from this effort, assuming the industry adopts that model.

“When the CEOs of the five companies that would be regulated are also the primary drafters of the standards, the standards will reflect those companies’ interests. FINRA has an independent board, but the operational reality is that member firm perspectives dominate the working groups that write the actual rules,” he said. “There is no reason to expect an AI equivalent to work differently, and every reason to expect it to work worse, because AI standardization is happening faster than any industry has ever attempted to standardize itself, and speed is the enemy of independent oversight.”

Carmi Levy, an independent technology analyst, was even more emphatically opposed to the Hassabis proposal.

“Asking Big Tech companies to self-police is analogous to allowing foxes to guard the henhouse. It hasn’t worked to date, and it won’t work going forward. Expecting these organizations to somehow change their ways at this point in time represents the height of naïve thinking,” Levy said. “The framework proposed by Demis Hassabis is a self-serving roadmap for an industry bent on racing to the AI horizon regardless of the harms caused along the way. It is impossible to quantify the dangers to broader society should frameworks allowing self-regulation become the norm.”

Some love the proposal

An almost completely opposite stance came from Yuri Goryunov, CIO of consulting firm Acceligence, who applauded the proposed move.

“This is one of the rare setups where industry self-regulation has a real shot, and enterprise IT should be enthusiastically rooting for it,” he said. “It fails when harms are externalized, such as in social media content moderation. Or when the overseer outsources judgment to the overseen, such as the FAA’s delegation to Boeing before the 737 MAX. It works when everyone in the industry shares the catastrophic downside.”

He suggested, however, that the best precedent here isn’t FINRA, it’s INPO, the Institute of Nuclear Power Operations, which the nuclear industry created within months of the 1979 Three Mile Island partial reactor meltdown “on the logic that an accident anywhere is an accident everywhere. INPO peer-reviews every US plant, its evaluations move insurance premiums, and it sits on top of the NRC’s statutory floor. That is a public-private stack very close to what Hassabis is describing. Frontier AI has the same structure: one lab’s catastrophic failure brings regulation down on all of them.”

For enterprise CIOs and other IT executives, Goryunov said, that model has the potential for being a big win.

“Today, every enterprise duplicates the same AI diligence of red-teaming, eval suites, governance committees and each does so with less information than any certifying body would have,” Goryunov said. “A credible standards regime does for AI what UL did for electrical equipment and SOC2 did for cloud: it converts an unknowable risk into a procurable product and gives boards a defensible standard of care. That’s not red tape. That’s peace of mind with an audit trail.”

However, Mahapatra said, “the countervailing view is that the alternative to industry-led standards is probably not thoughtful legislation. It is probably no standards, or state-by-state fragmentation, or the current pattern of ex-post enforcement actions where regulators surface concerns years after harm has already occurred.”

Thus, he noted, “Hassabis is making the reasonable argument that imperfect fast standards are better than perfect slow ones, and there is genuine merit to that view for topics like agent identity, evaluation methodology, and interoperability, which are exactly the areas OpenClaw is also targeting.”

This article first appeared on CIO.

Google DeepMind CEO Demis Hassabis on Tuesday reiterated his push for an AI industry self-regulation effort, led by the US government, that is particularly focused on artificial general intelligence (AGI) and national security. 

But it is precisely that focus on national security that may make the results of such an effort, assuming it happens, less than palatable outside of the US.

“The rapid progress we’re seeing in AI requires a new approach to testing frontier AI model capabilities that is dynamic, adaptable, and rigorous,” Hassabis wrote. “The US is well positioned, given its economic and technical standing, to take the first step in developing such a framework. It could establish a new Standards Body modelled on a federally overseen public-private partnership or self-regulatory organization, much like the Financial Industry Regulatory Authority (FINRA), with a board that includes independent leading technical experts and open-source representatives.”

He noted, however, that the funding would need to be substantial, and would most likely come from industry, to allow the new body to attract world-class technical talent and obtain the necessary compute resources for large-scale testing.

Hassabis said he would propose that the organization “be responsible for developing assessment protocols and working with appropriate federal agencies and the US National Labs to conduct testing in areas relevant to national security,” and that AI vendor participants would be encouraged to adopt best practices, such as publishing model cards with technical details, maintaining strong internal cybersecurity, vetting key personnel, and providing sufficient resourcing for safety and security research.

This is not the first time Hassabis has expressed worries about AGI. He has already worked on a US government initiative evaluating AI safety, which involved DeepMind, Microsoft and xAI (now SpaceXAI) working with the Center for AI Standards and Innovation (CAISI), a division of the US Department of Commerce. It allowed CAISI to conduct pre-deployment evaluations and targeted research to “better assess frontier AI capabilities and advance the state of AI security.”  

The rest of the world may have concerns

Analysts and consultants were mixed about the move, with most expressing concerns about whether an industry-focused group would prioritize the public’s best interests.

“Self-regulation is not viable because it implies everyone is able to regulate themselves and will do so in line with the best interests of the public. Most tech vendors don’t have the capacity to self-regulate. They would just prefer a set of rules within which they can operate,” said Gartner VP analyst Nader Henein. “For-profit organizations are required to do what is best for their shareholders, and external regulation ensures that those organizations are never in a conflict of interest where they have to choose between what is good for their shareholders and what is good for the public.”

And, said Sanchit Vir Gogia, chief analyst at Greyhound Research, given the international nature of AI models, an effort coordinated by the US government might alienate other countries. 

“National security is the proposal’s accelerator in Washington and its poison pill abroad: the framing that opens the only gate available at home invites foreign capitals to read the institution as an instrument of American strategy,” he pointed out.

“The map is already plural,” he said. “Brussels switches on enforcement powers over general-purpose models [starting in August 2026], London runs the AI Security Institute, and Beijing licenses on its own terms. California and New York have legislated for frontier models at home. The durable route is shared technical evidence with sovereign enforcement, sealed through mutual recognition rather than deference, with India and the other major non-Western markets holding authorship rather than seats.”

Gogia added that the rules enacted by even such a group may not address all of the key concerns of enterprise IT. A US government effort along the lines that Hassabis is proposing would result in testing that “sits close to intelligence and industrial policy, and those functions will not stay neatly separated. A model can pass every catastrophic-risk test and still fail the enterprise on privacy, reliability, and liability,” he noted.

Walmart’s former director of cybersecurity Steven Eric Fisher, who is now an independent cybersecurity consultant, said he found the proposal “well-intentioned, but it addresses a highly polarized topic at a time when commercial interests carry unprecedented political influence, which is not always applied benevolently.”

He added, “an exclusive US standard that is not globally respected or enforceable would likely fail to achieve its core purpose and would place US companies at a competitive disadvantage.”

Aman Mahapatra, chief strategy officer for Tribeca Softtech, a New York City-based technology consulting firm, said that a deep dive into how FINRA operates today is illustrative of what IT leaders can expect from this effort, assuming the industry adopts that model.

“When the CEOs of the five companies that would be regulated are also the primary drafters of the standards, the standards will reflect those companies’ interests. FINRA has an independent board, but the operational reality is that member firm perspectives dominate the working groups that write the actual rules,” he said. “There is no reason to expect an AI equivalent to work differently, and every reason to expect it to work worse, because AI standardization is happening faster than any industry has ever attempted to standardize itself, and speed is the enemy of independent oversight.”

Carmi Levy, an independent technology analyst, was even more emphatically opposed to the Hassabis proposal.

“Asking Big Tech companies to self-police is analogous to allowing foxes to guard the henhouse. It hasn’t worked to date, and it won’t work going forward. Expecting these organizations to somehow change their ways at this point in time represents the height of naïve thinking,” Levy said. “The framework proposed by Demis Hassabis is a self-serving roadmap for an industry bent on racing to the AI horizon regardless of the harms caused along the way. It is impossible to quantify the dangers to broader society should frameworks allowing self-regulation become the norm.”

Some love the proposal

An almost completely opposite stance came from Yuri Goryunov, CIO of consulting firm Acceligence, who applauded the proposed move.

“This is one of the rare setups where industry self-regulation has a real shot, and enterprise IT should be enthusiastically rooting for it,” he said. “It fails when harms are externalized, such as in social media content moderation. Or when the overseer outsources judgment to the overseen, such as the FAA’s delegation to Boeing before the 737 MAX. It works when everyone in the industry shares the catastrophic downside.”

He suggested, however, that the best precedent here isn’t FINRA, it’s INPO, the Institute of Nuclear Power Operations, which the nuclear industry created within months of the 1979 Three Mile Island partial reactor meltdown “on the logic that an accident anywhere is an accident everywhere. INPO peer-reviews every US plant, its evaluations move insurance premiums, and it sits on top of the NRC’s statutory floor. That is a public-private stack very close to what Hassabis is describing. Frontier AI has the same structure: one lab’s catastrophic failure brings regulation down on all of them.”

For enterprise CIOs and other IT executives, Goryunov said, that model has the potential for being a big win.

“Today, every enterprise duplicates the same AI diligence of red-teaming, eval suites, governance committees and each does so with less information than any certifying body would have,” Goryunov said. “A credible standards regime does for AI what UL did for electrical equipment and SOC2 did for cloud: it converts an unknowable risk into a procurable product and gives boards a defensible standard of care. That’s not red tape. That’s peace of mind with an audit trail.”

However, Mahapatra said, “the countervailing view is that the alternative to industry-led standards is probably not thoughtful legislation. It is probably no standards, or state-by-state fragmentation, or the current pattern of ex-post enforcement actions where regulators surface concerns years after harm has already occurred.”

Thus, he noted, “Hassabis is making the reasonable argument that imperfect fast standards are better than perfect slow ones, and there is genuine merit to that view for topics like agent identity, evaluation methodology, and interoperability, which are exactly the areas OpenClaw is also targeting.”

Google DeepMind CEO Demis Hassabis on Tuesday reiterated his push for an AI industry self-regulation effort, led by the US government, that is particularly focused on artificial general intelligence (AGI) and national security. 

But it is precisely that focus on national security that may make the results of such an effort, assuming it happens, less than palatable outside of the US.

“The rapid progress we’re seeing in AI requires a new approach to testing frontier AI model capabilities that is dynamic, adaptable, and rigorous,” Hassabis wrote. “The US is well positioned, given its economic and technical standing, to take the first step in developing such a framework. It could establish a new Standards Body modelled on a federally overseen public-private partnership or self-regulatory organization, much like the Financial Industry Regulatory Authority (FINRA), with a board that includes independent leading technical experts and open-source representatives.”

He noted, however, that the funding would need to be substantial, and would most likely come from industry, to allow the new body to attract world-class technical talent and obtain the necessary compute resources for large-scale testing.

Hassabis said he would propose that the organization “be responsible for developing assessment protocols and working with appropriate federal agencies and the US National Labs to conduct testing in areas relevant to national security,” and that AI vendor participants would be encouraged to adopt best practices, such as publishing model cards with technical details, maintaining strong internal cybersecurity, vetting key personnel, and providing sufficient resourcing for safety and security research.

This is not the first time Hassabis has expressed worries about AGI. He has already worked on a US government initiative evaluating AI safety, which involved DeepMind, Microsoft and xAI (now SpaceXAI) working with the Center for AI Standards and Innovation (CAISI), a division of the US Department of Commerce. It allowed CAISI to conduct pre-deployment evaluations and targeted research to “better assess frontier AI capabilities and advance the state of AI security.”  

The rest of the world may have concerns

Analysts and consultants were mixed about the move, with most expressing concerns about whether an industry-focused group would prioritize the public’s best interests.

“Self-regulation is not viable because it implies everyone is able to regulate themselves and will do so in line with the best interests of the public. Most tech vendors don’t have the capacity to self-regulate. They would just prefer a set of rules within which they can operate,” said Gartner VP analyst Nader Henein. “For-profit organizations are required to do what is best for their shareholders, and external regulation ensures that those organizations are never in a conflict of interest where they have to choose between what is good for their shareholders and what is good for the public.”

And, said Sanchit Vir Gogia, chief analyst at Greyhound Research, given the international nature of AI models, an effort coordinated by the US government might alienate other countries. 

“National security is the proposal’s accelerator in Washington and its poison pill abroad: the framing that opens the only gate available at home invites foreign capitals to read the institution as an instrument of American strategy,” he pointed out.

“The map is already plural,” he said. “Brussels switches on enforcement powers over general-purpose models [starting in August 2026], London runs the AI Security Institute, and Beijing licenses on its own terms. California and New York have legislated for frontier models at home. The durable route is shared technical evidence with sovereign enforcement, sealed through mutual recognition rather than deference, with India and the other major non-Western markets holding authorship rather than seats.”

Gogia added that the rules enacted by even such a group may not address all of the key concerns of enterprise IT. A US government effort along the lines that Hassabis is proposing would result in testing that “sits close to intelligence and industrial policy, and those functions will not stay neatly separated. A model can pass every catastrophic-risk test and still fail the enterprise on privacy, reliability, and liability,” he noted.

Walmart’s former director of cybersecurity Steven Eric Fisher, who is now an independent cybersecurity consultant, said he found the proposal “well-intentioned, but it addresses a highly polarized topic at a time when commercial interests carry unprecedented political influence, which is not always applied benevolently.”

He added, “an exclusive US standard that is not globally respected or enforceable would likely fail to achieve its core purpose and would place US companies at a competitive disadvantage.”

Aman Mahapatra, chief strategy officer for Tribeca Softtech, a New York City-based technology consulting firm, said that a deep dive into how FINRA operates today is illustrative of what IT leaders can expect from this effort, assuming the industry adopts that model.

“When the CEOs of the five companies that would be regulated are also the primary drafters of the standards, the standards will reflect those companies’ interests. FINRA has an independent board, but the operational reality is that member firm perspectives dominate the working groups that write the actual rules,” he said. “There is no reason to expect an AI equivalent to work differently, and every reason to expect it to work worse, because AI standardization is happening faster than any industry has ever attempted to standardize itself, and speed is the enemy of independent oversight.”

Carmi Levy, an independent technology analyst, was even more emphatically opposed to the Hassabis proposal.

“Asking Big Tech companies to self-police is analogous to allowing foxes to guard the henhouse. It hasn’t worked to date, and it won’t work going forward. Expecting these organizations to somehow change their ways at this point in time represents the height of naïve thinking,” Levy said. “The framework proposed by Demis Hassabis is a self-serving roadmap for an industry bent on racing to the AI horizon regardless of the harms caused along the way. It is impossible to quantify the dangers to broader society should frameworks allowing self-regulation become the norm.”

Some love the proposal

An almost completely opposite stance came from Yuri Goryunov, CIO of consulting firm Acceligence, who applauded the proposed move.

“This is one of the rare setups where industry self-regulation has a real shot, and enterprise IT should be enthusiastically rooting for it,” he said. “It fails when harms are externalized, such as in social media content moderation. Or when the overseer outsources judgment to the overseen, such as the FAA’s delegation to Boeing before the 737 MAX. It works when everyone in the industry shares the catastrophic downside.”

He suggested, however, that the best precedent here isn’t FINRA, it’s INPO, the Institute of Nuclear Power Operations, which the nuclear industry created within months of the 1979 Three Mile Island partial reactor meltdown “on the logic that an accident anywhere is an accident everywhere. INPO peer-reviews every US plant, its evaluations move insurance premiums, and it sits on top of the NRC’s statutory floor. That is a public-private stack very close to what Hassabis is describing. Frontier AI has the same structure: one lab’s catastrophic failure brings regulation down on all of them.”

For enterprise CIOs and other IT executives, Goryunov said, that model has the potential for being a big win.

“Today, every enterprise duplicates the same AI diligence of red-teaming, eval suites, governance committees and each does so with less information than any certifying body would have,” Goryunov said. “A credible standards regime does for AI what UL did for electrical equipment and SOC2 did for cloud: it converts an unknowable risk into a procurable product and gives boards a defensible standard of care. That’s not red tape. That’s peace of mind with an audit trail.”

However, Mahapatra said, “the countervailing view is that the alternative to industry-led standards is probably not thoughtful legislation. It is probably no standards, or state-by-state fragmentation, or the current pattern of ex-post enforcement actions where regulators surface concerns years after harm has already occurred.”

Thus, he noted, “Hassabis is making the reasonable argument that imperfect fast standards are better than perfect slow ones, and there is genuine merit to that view for topics like agent identity, evaluation methodology, and interoperability, which are exactly the areas OpenClaw is also targeting.”

This article originally appeared on CIO.com.

Enterprises are facing two simultaneous challenges with AI: The risks associated with it are evolving faster than governance frameworks, while the business benefits are often difficult to measure.

This is one of the key findings of The Value of AI, a study commissioned by SAP from Oxford Economics. Now in its second year, the study surveyed 2,600 executives from 13 countries worldwide.

High expectations, limited preparation

On average, the enterprises surveyed plan to spend around $28 million on AI (up from $26.7 million last year), and expect a 21% ROI (from 16% last year). Expectations for AI agents are particularly high, with ROI expected to reach 17% this year, up from 10% last year. Furthermore, 83% of respondents worldwide said agentic AI has the potential to fundamentally transform their organization. On the other hand, only 3% of respondents said their enterprises were fully prepared for the deployment of AI agents.

There are gaps, particularly when it comes to governance:

• Only 12% of respondents said their skills or processes were able to govern AI effectively,
• 38% do not have human-in-the-loop processes in place for oversight of AI agents, and
• only 63% have established permissions and access controls for agents.

Other concerns include weaknesses in the organization of AI deployment, poor data quality, insufficient employee training, and the widespread use of shadow AI.

Governance is the bigger challenge

In an interview, Sean Kask, Chief AI Strategy Officer at SAP, commented on the study’s key findings.

Mr. Kask, in the study’s foreword, you write that companies are currently facing two challenges simultaneously: The risks associated with AI are evolving faster than governance, while the business benefits are often difficult to measure. Which of these poses the greater problem for companies?

Sean Kask: Measuring the business value of IT investments has never been easy. The same applies to AI. That’s why I currently consider the governance issue to be the greater challenge. While traditional governance principles and best practices for secure software development remain important even in the age of large language models and agent-based AI, entirely new risks are emerging at the same time.

For example, as soon as companies roll out AI on a broad scale, they suddenly discover hundreds or even thousands of so-called shadow agents that employees are using without central oversight. Or they find that a significant portion of the workforce is copying content into private ChatGPT accounts. Such risks often only become apparent once AI is already being used productively.

According to your study, German companies invest an average of nearly $40 million in AI, more than companies in all other countries surveyed. Why is that?

Kask: I was less surprised by the amount of investment than by the fact that, overall, the level of investment and the return on investment achieved have developed very similarly across the various countries. There’s no clear answer as to why Germany invests more. In part, it’s likely simply because costs here are higher than in India, for example.

However, we’re also seeing a high level of AI adoption among German companies. SAP has a dashboard that allows us to track how our customers are using AI features. Germany is among the countries with particularly high usage. Added to this are the strong industrial base and the political impetus from Europe, which are driving the use of AI. Accordingly, companies there are making targeted investments in building the necessary expertise.

According to the study, 47% of German companies are satisfied with the return on investment from their AI investments. At the same time, 77% say they are still far from realizing AI’s full potential. Isn’t that a contradiction?

Kask: No, we see this pattern worldwide. Companies initially invest in a few AI use cases and realize: This works; we’re creating added value. Accordingly, they’re satisfied with their investment.

But this is precisely what leads them to identify further use cases. They explore AI agents and want to utilize them as well. However, it is exactly at this point that many encounter new challenges in implementation and scaling.

The study therefore primarily highlights a learning curve: The more experience companies gain with AI, the greater their awareness of its previously untapped potential becomes.

According to the study, only 33% of companies surveyed have KPIs at the executive board level that are directly linked to the implementation of AI. In your view, which metrics should supervisory boards and CEOs definitely be tracking?

Kask: For us, a key indicator is employee enablement. How many employees have already successfully completed training or upskilling programs related to AI? Without the appropriate skills, AI adoption will fall short of its potential.

Transparency is equally important. Companies should know which AI agents are actually in use within their landscape. SAP offers the SAP AI Agent Hub for this purpose, which automatically discovers and inventories agents from SAP and third-party environments. Customers have already been able to identify thousands of agents this way, which highlights the need for centralized governance and transparency.

In addition, companies should have a complete overview of all AI use cases. A robust business case should be in place for each use case. We often see two extremes: Either the executive board is under pressure to implement AI as quickly as possible and allocates a lump-sum budget for this purpose. Or management initially takes a wait-and-see approach. This leads to independent pilot projects springing up throughout the company, with individual departments procuring their own tools and entering into their own contracts.

At SAP, we therefore follow a clearly structured selection process. Each idea first undergoes an assessment of its expected business value. We then examine technical feasibility, data availability, and ethical and governance aspects. From management’s perspective, it is crucial to maintain transparency regarding all ongoing AI projects at all times and to consistently prioritize them based on their business value.

Agents, too, need a ‘hire-to-retire’ lifecycle

Even with the introduction of dozens or even hundreds of AI agents, governance becomes increasingly complex. What capabilities do enterprise platforms need to manage AI agents securely and in a controlled manner at scale?

Kask: We make a conscious effort not to anthropomorphize AI too much. Nevertheless, the analogy is helpful: Agents require a complete hire-to-retire lifecycle. This begins with the detection and registration of an agent. It is then integrated into the enterprise environment, granted the necessary permissions, and given access to the data sources it needs to perform its tasks.

Observability is just as important. Companies must be able to track what an agent is actually doing in the system at all times. In addition, they should track key performance indicators: Is the agent achieving the desired results? How efficiently is it working? How many tokens does it consume? How many processing steps does it require for a task?

Ultimately, this involves several key components: a complete inventory of all agents, appropriate governance, risk, and compliance (GRC) mechanisms, transparency regarding agent behavior, and continuous monitoring. This is the only way to ensure that AI agents consistently operate within defined parameters and deliver the desired business value.

In your estimation, which business processes will companies actually delegate entirely to AI agents over the next two to three years?

Kask: Currently, such agents work particularly well in clearly defined use cases. SAP will release more than 50 (currently 34) specialized AI agents.

One example is periodic financial reporting. In this context, journal entries must be made based on numerous rules stored in documents, emails, or previous transactions. The agent analyzes these various sources of information, derives a recommendation from them, and suggests the appropriate journal entry to the user.

Based on what we’ve heard from customer projects, employees at medium-sized companies currently spend about twelve hours per month on these tasks. With the help of an AI agent, this effort can be reduced to two to three hours.

Another area of application is production planning. If delivery dates change or new orders come in at short notice, the entire production plan must be adjusted. It is precisely these kinds of complex optimization tasks that are ideally suited for AI agents.

In principle, there are virtually no limits to the narrowly defined business processes in which agents can be deployed. However, they will not operate completely autonomously at first.

Trust in AI begins with a stable foundation

Many companies still struggle to trust AI agents. After all, large language models operate probabilistically and can produce false information. This is particularly problematic in financial processes. How do you build trust?

Kask: Trust begins with a stable foundation. ERP systems remain the reliable system of record. They operate deterministically, contain the business logic, and hold the relevant company data. AI agents build upon this foundation. They do not replace it.

Equally important is the human-in-the-loop principle. Employees must be able to understand what the agent is doing, verify its results, and intervene if necessary. That’s why employee training also plays a crucial role. They must understand how generative AI works and where its limitations lie.

Of course, language models can hallucinate. At the same time, we must not forget that humans are not infallible either. The key lies in the collaboration between humans and AI. This allows us to improve both the efficiency and the quality of many business processes.

Another important component is transparency. Our global AI ethics policy, for example, stipulates that users must always be able to recognize when AI is involved. In Joule, it’s possible to trace which data sources the agent used and which steps it went through in reaching its decision. This traceability is an essential prerequisite for trust.

What distinguishes an SAP agent from a general AI agent that merely accesses an ERP system?

Kask: The key difference is that Joule and the SAP agents are directly embedded in the ERP system. There, for example, we’ve built a knowledge graph that describes the semantic relationships between all tables, business objects, and data fields.

To put this into perspective: The SAP S/4HANA Knowledge Graph is based on approximately 452,000 ABAP tables, 7.3 million data fields, and thousands of analytical views. The semantic relationships between these artifacts are modeled in the Knowledge Graph and made available for AI applications.

For example, if a user wants to view all open purchase orders, the agent does not first have to laboriously search for the relevant information. It immediately knows which tables and objects are relevant and also understands the relationships between a purchase order, a purchase requisition, the responsible approvers, and other business objects. As a result, the agent not only works much more precisely but also requires significantly fewer tokens because it can greatly narrow down the search space.

If, instead, one attempts to simply overlay AI onto an existing system or extract data from a relational ERP system, many of these relationships are lost. In a sense, this destroys the semantic context that is crucial for precise answers.

That is why we view the ERP system as an enormous strategic advantage. It has been the system of record for decades and contains roughly 50 years of codified business and process knowledge. This knowledge forms the foundation for what we call the autonomous enterprise. The agents build upon this knowledge and continue to develop it.

In the future, SAP agents will also communicate bidirectionally with agents from other providers via standards such as Agent-to-Agent (A2A).

According to your study, AI currently creates the greatest added value in decision-making, customer interaction, and gaining new insights, rather than in traditional productivity gains. Will this change the way companies justify AI investments in the future?

Kask: In our study, productivity was simply rated slightly lower than, for example, gaining new insights. In the long term, however, productivity remains the ultimate goal. Europe, in particular, has been suffering from comparatively weak productivity growth for years.

At SAP, we therefore first evaluate every new AI feature based on its specific business value. For all agents and AI features that we include in our AI Feature Catalog, we first conduct a value analysis. We ask: What benefit does the feature offer the user? Does it contribute to higher revenue? Does it increase productivity? Only then is it developed further.

At the moment, the greatest added value often still lies in consolidating information from structured and unstructured data sources and making it accessible via natural language. The next step, however, is to translate these insights directly into more efficient business processes. That is precisely where the greatest productivity gains will be realized in the future.

If you could give CIOs just one or two pieces of advice for the transition from generative AI to AI agents, what would they be?

Kask: In my view, the biggest mistake would be to try to transform the entire company all at once or to attempt to perfectly prepare all the data right from the start.

Instead, you should consider what kind of agent can create significant added value, and then implement it. Of course, this agent needs access to consistent and context-rich enterprise data. That’s exactly what we’re working on at SAP with technologies like the knowledge graph, which maps the semantic relationships within enterprise data.

In addition, with data products and the SAP Business Data Cloud, we provide tools that make data from various sources usable for AI agents. Thanks to zero-copy and data fabric approaches, information from legacy systems, Snowflake, or ERP systems can be consolidated without first having to extensively replicate the data. For a procurement agent, this makes it possible to provide exactly the relevant data for the specific use case.

The key point is this: Companies do not have to wait until they have fully migrated to the cloud or consolidated their entire data landscape. With the technologies available today, data can already be made usable for specific AI agents, managed in a controlled manner, and used to quickly generate initial business value. On the other hand, those who wait for the perfect starting point run the risk of falling behind.

This article is adapted from one first published by Computerwoche.

OpenClaw’s announcement that it has become a nonprofit foundation is generating IT excitement because of the potential for governance and development consistency that the popular platform has thus far lacked. Still, some worry about the risks created by the move. 

“Our ambition is for OpenClaw to be the Switzerland of AI. Neutral ground where every model and every lab can plug into the technology and collaborate on standards in the era of agents,” OpenClaw said in a post. “That work is already underway in Foundation-convened councils on agent identity, agent profiles, evals, and enterprise deployment.”

The statement, co-authored by OpenClaw creator Peter Steinberger, pointed out, “the great open source projects of our time — Linux, Apache, Mozilla — endure because a neutral steward stands behind them. That is the role we are taking on to keep OpenClaw MIT licensed, open, and independent so that everyone building on it can trust it will be here for the long term.”

But it reassured users that the original OpenClaw leadership is still in charge.

“Peter built this thing and Peter keeps making the calls, especially the technical ones. Since joining OpenAI earlier this year, he has continued to steward OpenClaw as an open and independent project, and OpenAI has made a commitment to keep it that way,” the post said. “The foundation is here to serve: good governance, stable funding, and paying the people who keep the claws alive.”

However, some analysts and consultants were skeptical about how much true independence Steinberger would have, given his salaried role with OpenAI. 

Neutrality claim in question

“The Switzerland of AI neutrality claim collapses under its own announcement,” said Noah Kenney, principal consultant at Digital 520. “OpenAI runs a team [at OpenAI] called Claw Labs that Peter leads and OpenAI is a major donor to OpenClaw. The ‘neutral steward’s’ chief technical decision maker is employed by one of the competing labs it is supposed to be neutral with.” To OpenAI, he said, OpenClaw is closer to a tax-exempt nonprofit subsidiary than it is to a neutral ‘Switzerland of AI.’

He pointed out that, in addition, Microsoft is shipping the enterprise version of OpenClaw, and Nvidia is shipping the hardware bundle. “This is being called the Switzerland of AI, but Switzerland does not have its central bank run by France,” he observed.

Kenney said that what the new OpenClaw has actually built is “a shared dependency that several competitors fund, staff, and steer, wrapped in a nonprofit structure. Enterprise IT should understand that structure, because treating OpenClaw as neutral is a mistake,” adding that CIOs need to look at this development devoid of the emotional component. 

“There is a strategic irony here that CIOs should sit with,” Kenney said. “If OpenClaw succeeds at becoming the universal agent substrate, then every model plugs into the same identity layer, the same profiles, and the same deployment plumbing. The thing every vendor is racing to own becomes a commodity that nobody owns.” He pointed out that, in the short term, that is genuinely good news for buyers because it means less lock-in and more portability.

“But,” he said, “when the connective tissue is free and natural, the only labs that benefit are the ones with the best models and the deepest distribution. Commoditize the layer below you and you compete on the layer where you are already strongest. The foundation is not a charity. It is the biggest players agreeing to stop fighting over the plumbing so they can fight over the water, and the enterprise is the one paying the water bill either way.”

Good news, bad news

Jason Andersen, principal analyst at Moor Insights & Strategy, liked the potential consistency that could emerge from the structural change, given the complexity of agent development today. 

“We are seeing a lot of OpenClaw variants hit the market, such as those from Nvidia as well as competing products from cloud and SaaS vendors. A common base helps solidify the common parts,” Andersen noted. “That said, a common challenge is the sustainability of these open source foundations over time. In addition to releasing code, these foundations need funding to evolve and grow. And that funding needs to come from continued momentum to incentivize existing members to increase investment and recruit new members to join.”

Andersen stressed that IT buyers need to keep an eye on the roadmap for any OpenClaw variant they choose to deploy, “as that will directly impact the foundation, and the momentum of the foundation and common base. If the common base loses momentum, it can lead to forks, or just a loss of innovation. When that happens, members tend to back away, which puts customers in limbo.”

But not everyone sees the promised structure as entirely good for IT.

Ishraq Khan, CEO at coding productivity tool vendor Kodezi, said, “most CIOs do not want to bet their future entirely on a single model vendor. They want Claude for some workloads, GPT for others, open models for sensitive environments, and potentially internally fine-tuned systems for specific use cases. The problem is that every vendor currently brings its own identity system, tool interfaces, permissions model, and operational assumptions. That fragmentation does not scale.”

He said, “the risk if standards fail is straightforward: every vendor builds its own closed ecosystem, enterprises become locked into individual stacks, and security becomes dramatically harder. The opportunity if OpenClaw succeeds is equally significant: enterprises get portable agents, common identity standards, interoperable tooling, and a healthier competitive market around models rather than ecosystems.”

Will it remain a nonprofit?

However, said Justin Greis, CEO of consulting firm Acceligence, one of the key details that IT executives will want to keep in mind is that OpenAI also began as a nonprofit, but it was quickly seen as not adhering to nonprofit objectives. 

“OpenAI’s transition from a nonprofit research organization into a more complex structure highlighted the challenge of maintaining mission alignment while scaling technology, capital, partnerships, and commercial operations,” Greis said. “OpenClaw has the opportunity to address some of those governance questions earlier by establishing clear principles around neutrality, transparency, and decision-making before the ecosystem becomes even larger and more valuable.”

He noted, “we have seen this pattern before with technologies like Linux and Kubernetes. The strongest open ecosystems succeeded because they created trusted foundations that enterprises could build upon. The technology was important, but the governance model that underpinned it was equally critical.”

Risks are ‘squarely in IT’s lap’

Consultant Brian Levine, executive director of FormerGov, echoed Greis’ concerns. 

“CIOs shouldn’t assume that this nonprofit will always be a nonprofit, or confuse being a nonprofit with actually being neutral or unbiased,” he said. “The risks are squarely in IT’s lap: autonomous agents ‘with their own identity’ acting on a user’s behalf blow straight through traditional IAM assumptions. Issues, such as agent identity, auditability, secret handling. Identity boundaries have not yet been reliably solved. Until they are, enterprises should treat OpenClaw agents like privileged service accounts, not like a browser plugin.”

Independent cybersecurity and risk advisor Steven Eric Fisher pointed to another IT exposure that might come from this OpenClaw transition: Cost.

“OpenClaw currently has a very high token burn rate in usage, which presents a significant cost consideration for large-scale enterprise adoption,” he said. “The skills marketplace introduces a new supply chain threat that enterprises will need to manage. Threat management, and specifically handling external marketplace elements, can be highly challenging for open-source operations. Ultimately, at scale, enterprise adoption could become a difficult balancing act between managing high operational costs and securing an expanded security surface.”

This article originally appeared on Computerworld.

Gen AI spending is moving beyond the familiar software model of seats, licenses, and pilots. As AI shifts from copilots to embedded workflows and autonomous agents, one user request can trigger multiple model calls, retrieval steps, retries, orchestration layers, and infrastructure events. A tool that looks affordable in pilot may behave very differently once connected to production systems or allowed to act with less human supervision.

According to Michael Corrigan, CIO of World Insurance Associates, AI introduces a fundamentally different cost model — one that’s usage driven, non-linear, and tightly coupled to business activity. “Success requires shifting from traditional IT budgeting to FinOps-style discipline where consumption, value, and governance are actively managed in real time,” he says.

Here are five ways CIOs can build that discipline before AI costs spiral.

Forecast AI by workflow, not by user

At World, a top 25 insurance broker with about 3,000 employees across roughly 300 locations, AI use falls into three broad categories, Corrigan says. One is broad tools, such as copilots. Another is embedded AI inside SaaS platforms. And the third is bespoke AI built around specific workflows and manual processes.

“The bespoke is the area that’s growing the most right now,” he says. “And that’s where the model, from a cost perspective, has really been shifting from a license seat cost to a token consumption or token burn cost, or even a hybrid.”

Seat-based pricing is relatively easy to forecast whereas consumption-based AI isn’t. Costs may depend on prompt complexity, output length, model choice, workflow design, and whether the system calls a model once or many times in the background.

World tries to manage that uncertainty by defining the business problem, success criteria, and expected operational improvement upfront. Pilots help estimate consumption before scaling, but Corrigan says they don’t remove the ambiguity.

“We’ll try our best in the pilot to understand what the consumption rate is, what the token burn rate is,” he says. But once a consumption-based workflow goes into production, he adds, an estimate is put into place. That estimate is informed, but still rough.

Elmer Morales, founder and CEO of koder.com, an agentic AI coding startup, says CIOs should think less about headcount and more about workflow mechanics. Agentic AI costs are driven by the number of decisions an agent makes, how often it retrieves external data, how much context it carries, and how many systems it touches.

“CIOs should start by mapping workflows, not necessarily users,” he says. “The relevant variable isn’t going to be the headcount but how many decisions an agent makes per task.”

Model the failure path, not just the happy path

Pilots can mislead because they often test the cleanest version of an AI workflow. Morales says many enterprises model agentic AI costs around the happy path: the user gives a clear prompt, the system understands the request, the agent completes the task, and the process ends. Production is messier.

“They generally don’t model for situations where the agent is going to need to go back and check its work and redo things,” Morales says. “A lot of times, agents are wrong, either because they hallucinate or they understood the problem incorrectly.”

In an agentic workflow, the system may check its work, call another tool, retrieve more data, or redo a step. While that may improve quality, it also adds cost.

The difference between copilots and agents is central. A copilot interaction is often one prompt and one response. An agentic workflow may involve agents moving through a decision tree, executing tasks in sequence or in parallel, and calling sub-agents or external systems along the way. “By the time it’s achieved the original goal, the agent might have made 50 or 100 model calls, compared with a single call for a traditional copilot prompt,” Morales says.

That’s why CIOs should require teams to model the failure path before production, like how many retries are allowed, how much context is resent, which tools can be called, when a human should intervene, and what happens when the agent can’t complete the task.

Build cost controls into the architecture

Traditional FinOps practices still matter, but AI requires more than retrospective dashboards and chargebacks.

According to Pavan Madduri, senior cloud platform engineer at industrial supply company Graigner, looking backward at usage data, as traditional FinOps often does, can be too late. Costs are shaped by prompt design, model selection, agent behavior, orchestration choices, and runtime loops.

“Dashboards or chargebacks, those are historical accounting,” he says. “The money’s already gone.” For AI, he argues, cost controls need to be embedded into the architecture. That includes hard token caps, retry-depth limits, maximum runtime limits, workload prioritization, background-job throttling, and cluster-level controls that prevent runaway consumption.

“The real FinOps means you need to have the cost constraints embedded into your architecture framework,” Madduri says.

Those controls also extend to infrastructure. Expensive GPUs may sit warm between jobs because systems need capacity available when inference demand arrives. Teams may pass huge schemas, databases, or thousands of lines of code into frontier models when a smaller or more focused prompt would do.

Enterprises should also adopt event-driven autoscaling, Madduri says. “Use tools like KEDA to scale GPU nodes down to zero the moment inference demand drops, so teams only pay for the windows when the silicon is actively crunching tokens.”

Corrigan says World uses rate limits, spend limits, alerts, and approval gateways for consumption-based tools. When users approach token consumption limits, automated alerts allow IT and the business to review whether the continued spend is justified.

“If it’s not meeting the success criteria we expected, you have to have the control in place to say we’re going to move on or kill that process,” Corrigan says.

Route work to the right model

CIOs can also reduce AI bill shock by avoiding a default assumption that every task requires the most powerful model available. While some tasks need advanced reasoning, many others don’t. A simple support ticket, log-parsing task, or structured database transaction may be handled by a smaller or cheaper model. A complex architecture decision, legal analysis, or multi-step reasoning task may justify a more powerful one.

“Choosing the right model for the right prompt and right question — that’s where you leverage the maximum from that model, and you can decrease the costing,” Madduri says. “If you default every single call to a frontier model, that’s architectural laziness.”

Morales makes a similar point. Not every step in an agentic workflow requires a top-of-the-line model. Model routing, he says, is the discipline of determining the best model for the task, and providing the relevant context when the model needs it.

According to Jim Olsen, CTO of enterprise software company ModelOp, CIOs should use the least expensive model that can accomplish the business goal. Using the biggest model for everything is easier, but expensive. “It’s like hiring the most expensive engineer to change a few colors in a website’s CSS, or visual styling,” he says. “You wouldn’t do that. You use the appropriate tools for the task.”

Tie consumption to business value

For Olsen, the deeper enterprise problem is AI value shock, not just bill shock. Spending $200,000 in a quarter on AI is justified if it produces $2 million in business value. The problem is spending heavily on use cases that don’t generate a meaningful return.

“Are you actually getting that return on investment, or are you just blowing tokens for something that’s not delivering the value to your business?” Olsen asks. Tracking token usage by user or department may show who consumed AI, but not whether the consumption mattered.

For most enterprise AI systems, Olsen says costs should be tied back to business use cases. A model may be used for HR document search, customer support, code review, problem resolution, or other functions. Each use case may draw on the same underlying models or agents, but the business value can be very different.

That’s why he argues that companies need an AI inventory, a record of which business workflows use which models, agents, providers, workflows, and systems. Without that inventory, enterprises can’t connect consumption to value.

Corrigan takes a similar approach from a governance perspective. At World, new AI ideas go through an intake process. Business users propose improvements, and IT, finance, operations, sales, and business stakeholders evaluate, prioritize, and monitor them from pilot through production.

That may be where the next stage of AI FinOps is heading, toward a clearer understanding of which AI consumption deserves to scale, not just to lower bills. So the question, as Olsen puts it, isn’t whether someone used a million tokens. It’s what are they using them for.

When people hear the term artificial intelligence, they usually think of chatbots or data analysis. But at BMW’s Spartanburg plant in the US, AI is now getting hands, legs, and eyes. Under the term physical AI, the automaker is integrating the new humanoid AI robt Figure 03 into its production logistics.

The move comes as no surprise: For almost a year, BMW had the predecessor (Figure 02) welding body parts for more than 30,000 vehicles. The conclusion of this practical test: The machines can precisely perform monotonous, heavy tasks. Now the technology is leaving the testing phase and moving to where things get highly complex: logistics.

The task: Transform chaos into order

While its predecessor simply lifted sheets of metal, the further enhanced Figure 03 has to solve cognitive and tactile tasks. In logistics, it picks unsorted components from large boxes and sorts them into carts in the exact required order. Automated transport systems then take over, carrying them to the assembly line.

To achieve this, the manufacturer has upgraded Figure AI. The new robot has:

• Cameras and tactile sensors directly in the palms of the hands for greater sensitivity
• Audio functions for true speech-to-speech communication in the factory hall
• Wireless charging for continuous, autonomous operation
• Softer components to increase safety for human colleagues

At first glance, a humanoid robot might seem like a project solely for the production manager. That’s a misconception. This use case is relevant for everyone, and is highly relevant for CIOs. Figure 03 is ultimately nothing other than a highly complex, mobile edge client that has to process large amounts of data (video, audio, sensor data) locally and in real-time.

BMW AG

BMW is demonstrating in Spartanburg that such a robot works, but only in a fully digitized ecosystem like an automotive plant. This means that the IT department is the enabler for the production environment of the future.

1. Virtual twins: Even before the first robot touches a box, BMW simulates Hall 52 and all movement sequences in a 3D “Virtual Factory.” IT provides the planning basis.
2. AI Quality Control (AIQX): Error detection is performed using cameras and microphones along the production line. The algorithms perform visual and audible checks and send the feedback directly to the smart devices of human colleagues.
3. Infrastructure scaling: When robots communicate via voice, charge wirelessly, and interact with autonomous transporters, the WLAN, 5G, and network backbone in the factory must have low latency and be fail-safe.

On the one hand, the humanoid robot relieves BMW factory workers of physically demanding work; on the other hand, it forces the IT department to merge traditional IT infrastructure and factory technology (OT). “Physical AI” has thus arrived in everyday industrial practice.

OpenClaw’s announcement that it has become a nonprofit foundation is generating IT excitement because of the potential for governance and development consistency that the popular platform has thus far lacked. Still, some worry about the risks created by the move. 

“Our ambition is for OpenClaw to be the Switzerland of AI. Neutral ground where every model and every lab can plug into the technology and collaborate on standards in the era of agents,” OpenClaw said in a post. “That work is already underway in Foundation-convened councils on agent identity, agent profiles, evals, and enterprise deployment.”

The statement, co-authored by OpenClaw creator Peter Steinberger, pointed out, “the great open source projects of our time — Linux, Apache, Mozilla — endure because a neutral steward stands behind them. That is the role we are taking on to keep OpenClaw MIT licensed, open, and independent so that everyone building on it can trust it will be here for the long term.”

But it reassured users that the original OpenClaw leadership is still in charge.

“Peter built this thing and Peter keeps making the calls, especially the technical ones. Since joining OpenAI earlier this year, he has continued to steward OpenClaw as an open and independent project, and OpenAI has made a commitment to keep it that way,” the post said. “The foundation is here to serve: good governance, stable funding, and paying the people who keep the claws alive.”

However, some analysts and consultants were skeptical about how much true independence Steinberger would have, given his salaried role with OpenAI. 

Neutrality claim in question

“The Switzerland of AI neutrality claim collapses under its own announcement,” said Noah Kenney, principal consultant at Digital 520. “OpenAI runs a team [at OpenAI] called Claw Labs that Peter leads and OpenAI is a major donor to OpenClaw. The ‘neutral steward’s’ chief technical decision maker is employed by one of the competing labs it is supposed to be neutral with.” To OpenAI, he said, OpenClaw is closer to a tax-exempt nonprofit subsidiary than it is to a neutral ‘Switzerland of AI.’

He pointed out that, in addition, Microsoft is shipping the enterprise version of OpenClaw, and Nvidia is shipping the hardware bundle. “This is being called the Switzerland of AI, but Switzerland does not have its central bank run by France,” he observed.

Kenney said that what the new OpenClaw has actually built is “a shared dependency that several competitors fund, staff, and steer, wrapped in a nonprofit structure. Enterprise IT should understand that structure, because treating OpenClaw as neutral is a mistake,” adding that CIOs need to look at this development devoid of the emotional component. 

“There is a strategic irony here that CIOs should sit with,” Kenney said. “If OpenClaw succeeds at becoming the universal agent substrate, then every model plugs into the same identity layer, the same profiles, and the same deployment plumbing. The thing every vendor is racing to own becomes a commodity that nobody owns.” He pointed out that, in the short term, that is genuinely good news for buyers because it means less lock-in and more portability.

“But,” he said, “when the connective tissue is free and natural, the only labs that benefit are the ones with the best models and the deepest distribution. Commoditize the layer below you and you compete on the layer where you are already strongest. The foundation is not a charity. It is the biggest players agreeing to stop fighting over the plumbing so they can fight over the water, and the enterprise is the one paying the water bill either way.”

Good news, bad news

Jason Andersen, principal analyst at Moor Insights & Strategy, liked the potential consistency that could emerge from the structural change, given the complexity of agent development today. 

“We are seeing a lot of OpenClaw variants hit the market, such as those from Nvidia as well as competing products from cloud and SaaS vendors. A common base helps solidify the common parts,” Andersen noted. “That said, a common challenge is the sustainability of these open source foundations over time. In addition to releasing code, these foundations need funding to evolve and grow. And that funding needs to come from continued momentum to incentivize existing members to increase investment and recruit new members to join.”

Andersen stressed that IT buyers need to keep an eye on the roadmap for any OpenClaw variant they choose to deploy, “as that will directly impact the foundation, and the momentum of the foundation and common base. If the common base loses momentum, it can lead to forks, or just a loss of innovation. When that happens, members tend to back away, which puts customers in limbo.”

But not everyone sees the promised structure as entirely good for IT.

Ishraq Khan, CEO at coding productivity tool vendor Kodezi, said, “most CIOs do not want to bet their future entirely on a single model vendor. They want Claude for some workloads, GPT for others, open models for sensitive environments, and potentially internally fine-tuned systems for specific use cases. The problem is that every vendor currently brings its own identity system, tool interfaces, permissions model, and operational assumptions. That fragmentation does not scale.”

He said, “the risk if standards fail is straightforward: every vendor builds its own closed ecosystem, enterprises become locked into individual stacks, and security becomes dramatically harder. The opportunity if OpenClaw succeeds is equally significant: enterprises get portable agents, common identity standards, interoperable tooling, and a healthier competitive market around models rather than ecosystems.”

Will it remain a nonprofit?

However, said Justin Greis, CEO of consulting firm Acceligence, one of the key details that IT executives will want to keep in mind is that OpenAI also began as a nonprofit, but it was quickly seen as not adhering to nonprofit objectives. 

“OpenAI’s transition from a nonprofit research organization into a more complex structure highlighted the challenge of maintaining mission alignment while scaling technology, capital, partnerships, and commercial operations,” Greis said. “OpenClaw has the opportunity to address some of those governance questions earlier by establishing clear principles around neutrality, transparency, and decision-making before the ecosystem becomes even larger and more valuable.”

He noted, “we have seen this pattern before with technologies like Linux and Kubernetes. The strongest open ecosystems succeeded because they created trusted foundations that enterprises could build upon. The technology was important, but the governance model that underpinned it was equally critical.”

Risks are ‘squarely in IT’s lap’

Consultant Brian Levine, executive director of FormerGov, echoed Greis’ concerns. 

“CIOs shouldn’t assume that this nonprofit will always be a nonprofit, or confuse being a nonprofit with actually being neutral or unbiased,” he said. “The risks are squarely in IT’s lap: autonomous agents ‘with their own identity’ acting on a user’s behalf blow straight through traditional IAM assumptions. Issues, such as agent identity, auditability, secret handling. Identity boundaries have not yet been reliably solved. Until they are, enterprises should treat OpenClaw agents like privileged service accounts, not like a browser plugin.”

Independent cybersecurity and risk advisor Steven Eric Fisher pointed to another IT exposure that might come from this OpenClaw transition: Cost.

“OpenClaw currently has a very high token burn rate in usage, which presents a significant cost consideration for large-scale enterprise adoption,” he said. “The skills marketplace introduces a new supply chain threat that enterprises will need to manage. Threat management, and specifically handling external marketplace elements, can be highly challenging for open-source operations. Ultimately, at scale, enterprise adoption could become a difficult balancing act between managing high operational costs and securing an expanded security surface.”

A portmanteau of “development” and “operations,” devops emerged as a way of bringing together two previously separate groups responsible for the building and deploying of software.

In the old world, developers (devs) typically wrote code before throwing it over to the system administrators (operations, or ops) to deploy and integrate that code. But as the industry shifted towards agile development and cloud-native computing, many organizations reoriented around modern, cloud-native practices in the pursuit of faster, better releases.

This required a new way to perform these key functions in a more streamlined, efficient, and cohesive way, one where the old frustrations of disconnected dev and ops functions would be eliminated. With two groups working together, developers can rapidly roll out small code enhancements via continuous integration and delivery rather than spending years on “big bang” product releases.

Devops was born at cloud-native companies like Facebook, Netflix, Spotify, and Amazon; but it’s become one of the defining technology industry trends of the past decade, primarily because it bridges so many of the changes that have shaped modern software development.

As agile development and cloud-native computing have become ubiquitous, devops has enabled the entire industry to speed up its software development cycles. Thus, devops has now thoroughly infiltrated the enterprise, especially in organizations that rely on software to run their business, such as banks, airlines, and retailers. And it’s spawned a host of other “ops” practices, some of which we’ll touch on here.[JF1] 

Devops practices

Devops requires a shift in mindset from both sides of the dev and ops divide. Development teams should focus on learning and adopting agile processes, standardizing platforms, and helping drive operational efficiencies. Operations teams must now focus on improving stability and velocity, while also reducing costs by working hand in hand with the developer team.

Broadly speaking, these teams need to all speak a common language and there needs to be a shared goal and understanding of each other’s key skills for devops to thrive.

More specifically, engineers Damon Edwards and John Willis created the CALMS model to bring together what are commonly understood to be the key principles of devops:

• Culture: One that embraces agile methodologies and is open to change, constant improvement, and accountability for the end-to-end quality of software.
• Automation: Automating away toil is a key goal for any devops team.
• Lean: Ensuring the smooth flow of software through key steps as quickly as possible.
• Measurement: You can’t improve what you don’t measure. Devops pushes for a culture of constant measurement and feedback that can be used to improve and pivot as required, on the fly.
• Sharing: Knowledge sharing across an organization is a key tenet of devops.

“Who could go back to the old way of trying to figure out how to get your laptop environment looking the same as the production environment? All these things make it so clear that there’s a better way to work. I think it’s very tough to turn back once you’ve done things like continuous integration, like continuous delivery. Once you’ve experienced it, it’s really tough to go back to the old way of doing things,” Kim told InfoWorld.

What is a devops engineer?

Naturally, the emergence of devops has spawned a whole new set of job titles, most prominent of which is the catch-all devops engineer.

Generally speaking, this role is the natural evolution of the system administrator — but in a world where developers and ops work in close tandem to deliver better software. This person should have a blend of programming and system administrator skills so that he or she can effectively bridge those two sides of the team.

That bridging of the two sides requires strong social skills more than technical. As Kim put it, “one of the most important skills, abilities, traits needed in these pioneering rebellions — using devops to overthrow the ancient powerful order, who are very happy to do things the way they have for 30 to 40 years — are the cross-functional skills to be able to reach across the table to their business counterparts and help solve problems.”

This person, or team of people, will also have to be a born optimizer, tasked with continually improving the speed and quality of software delivery from the team, be that through better practices, removing bottlenecks, or applying automation to smooth out software delivery.

The good news is that these skills are valuable to the enterprise. Salaries for this set of job titles have risen steadily over the years, with 95% of devops practitioners making more than $75,000 a year in salary in 2020 in the United States. In Europe and the UK, where salaries are lower across the board, 71% made more than $50,000 a year in 2020, up from 67% in 2019.

Key devops tools

While devops is at its heart a cultural shift, a set of tools has emerged to help organizations adopt devops practices.

This stack typically includes infrastructure as code, configuration management, collaboration, version control, continuous integration and delivery (CI/CD), deployment automation, testing, and monitoring tools.

Here are some of the tools/categories that are increasingly relevant in 2025, and what is changing:

• CI/CD and delivery automation: Traditional tools like Jenkins remain in many stacks, but newer orchestration tools and CLI-driven or GitOps-centric platforms are growing in importance (e.g. ArgoCD, Flux, Tekton). Also, platforms that integrate more tightly with monitoring, secrets management, drift detection, and policy enforcement are gaining traction.
• Security, compliance, and devsecops tooling: Security tools are increasingly integrated into devops pipelines. Expect to see more use of static analysis (SAST), dynamic testing (DAST), dependency and supply chain scanning (SCA), secret management, and policy as code. The push is toward embedding security earlier and bridging gaps between dev, security, and machine learning teams. (InfoWorld:)
• AI  and automation augmentation: AI-assisted tools are increasingly part of tooling stacks: auto-suggestions in CI/CD, anomaly detection, predictive scaling, intelligent test suite selection, and more. The hope is that these tools will reduce manual interventions and improve reliability. Tools that are “AI ready”—that is, they integrate well with AI or have mature built-in automation or assistance—increasingly stand out from the pack.

Devops challenges

Even as devops becomes more widely adopted, there remain real obstacles that can slow progress or limit impact. One major challenge is the persistent skills gap. The modern devops engineer (or team) is expected to master not just source control, CI/CD, and scripting, but also cloud architecture, infrastructure as code, security best practices, observability, and strong cross-team communication. In many organizations these capabilities are uneven: some teams excel, others lag behind. A 2024 survey showed that while 83% of developers report participating in devops activities, using multiple CI/CD tools was correlated with worse performance — a sign that complexity without deep expertise can backfire.

Toolchain fragmentation and complexity is a related issue. Devops toolchains have sprouted into a sometimes bewildering array of packages and techniques to master: version control, CI build/test, security scanning, artifact management, monitoring, observability, deployment, secret management, and more.

The more tools you have, the more difficult it becomes to integrate them cleanly, manage their versions, ensure compatibility, and avoid duplicated effort. Organizations often get stuck with “tool sprawl” — tools chosen by different teams, legacy systems, or overlapping functionalities — which introduce friction, maintenance burden, and sometimes vulnerabilities.

Finally, although devops has spread far and wide, there is still cultural resistance and alignment. Devops isn’t just about tools and processes; it’s about collaboration, shared responsibility, and continuous feedback. Teams rooted in traditional silos (dev vs ops, or security separate) may resist changes to roles and workflows. Leadership support, communication of shared goals, trust, and allowance for continuous learning are all necessary.

Many CIOs focus too much on tools or implementation first, rather than organizational culture and behaviors; but without addressing culture, even the best tools or processes may not yield the hoped-for velocity, quality, or reliability. Organizations that succeed here tend to have proactive strategies: dedicated training programs, mentorship, internal “guilds,” pairing junior and senior engineers, and making sure leadership supports ongoing learning rather than one-off bootcamps.

Why do devops?

Whoever you ask will tell you that devops is a major culture shift for organizations, so why go through that pain at all?

Devops aims to combine the formerly conflicting aims of developers and system administrators. Under its principles, all software development aims to meet business demands, add functionality, and improve the usability of applications while also ensuring those applications are stable, secure, and reliable. Done right, this improves the velocity and quality of your output, while also improving the lives of those working on these outcomes.

Does devops save money — or add cost?

Devops teams are recognizing that speed and agility are only part of success — unchecked cloud bills and waste undermine long-term sustainability. Waste in devops often comes in the form of “devops debt”— idle cloud capacity, dead code, or false-positive security alerts—which was called a “hidden tax on innovation” in recent Java-environment studies.

 Embedding finops practices can help fight these costs. Teams should shift left on cost: estimating costs when spinning up new environments, resizing instances, and scaling down unused resources before they become runaway expenses.

How to start with devops

There are lots of resources for help getting started with devops, including Kim’s own Devops Handbook, or you can enlist the help of external consultants. But you have to be methodical and focus on your people more than on the tools and technology you will eventually use if you want to ensure lasting buy-in across the business.

A proven route to achieving this is a “land and expand” strategy, where a small group starts by mapping key value streams and identifying a single product team or workload for trialing devops practices. If this team is successful in proving the value of the shift, you will likely start to get interest from other teams and from senior leadership.

If you are at the start of your devops journey, however, make sure you are prepared for the disruption a change like this can have on your organization, and keep your eye on the prize of building better, faster, stronger software.

More on devops:

• Devops debt: The hidden tax on innovation
• 10 big devops mistakes and how to avoid them
• Smarter devops: How to avoid deployment horrors

What is cloud native? Cloud native defined

The term “cloud-native computing” encompasses the modern approach to building and running software applications that exploit the flexibility, scalability, and resilience of cloud computing. The phrase is a catch-all that encompasses not just the specific architecture choices and environments used to build applications for the public cloud, but also the software engineering techniques and philosophies used by cloud developers.

The Cloud Native Computing Foundation (CNCF) is an open source organization that hosts many important cloud-related projects and helps set the tone for the world of cloud development. The CNCF offers its own definition of cloud native:

Cloud native practices empower organizations to develop, build, and deploy workloads in computing environments (public, private, hybrid cloud) to meet their organizational needs at scale in a programmatic and repeatable manner. It is characterized by loosely coupled systems that interoperate in a manner that is secure, resilient, manageable, sustainable, and observable.

Cloud native technologies and architectures typically consist of some combination of containers, service meshes, multi-tenancy, microservices, immutable infrastructure, serverless, and declarative APIs — this list is not exhaustive.

This definition is a good start, but as cloud infrastructure becomes ubiquitous, the cloud native world is beginning to spread behind the core of this definition. We’ll explore that evolution as well, and look into the near future of cloud-native computing.

Cloud native architectural principles

Let’s start by exploring the pillars of cloud-native architecture. Many of these technologies and techniques were considered innovative and even revolutionary when they hit the market over the past few decades, but now have become widely accepted across the software development landscape.

Microservices. One of the huge cultural shifts that made cloud-native computing possible was the move from huge, monolithic applications to microservices: small, loosely coupled, and independently deployable components that work together to form a cloud-native application. These microservices can be scaled across cloud environments, though (as we’ll see in a moment) this makes systems more complex.

Containers and orchestration. In could-native architectures, individual microservices are executed inside containers — lightweight, portable virtual execution environments that can run on a variety of servers and cloud platforms. Containers insulate the developers from having to worry about the underlying machines on which their code will execute. That is, all they have to do is write to the container environment. 

Getting the containers to run properly and communicate with one another is where the complexity of cloud native computing starts to emerge. Initially, containers were created and managed by relatively simple platforms, the most common of which was Docker. But as cloud-native applications got more complex, container orchestration platforms that augmented Docker’s functionality emerged, such as Kubernetes, which allows you to deploy and manage multi-container applications at scale. Kubernetes is critical to cloud native computing as we know it — it’s worth noting that the CNCF was set up as a spinoff of the Linux Foundation on the same day that Kubernetes 1.0 was announced — and adhering to Kubernetes best practices is an important key to cloud native success. 

Open standards and APIs. The fact that containers and cloud platforms are largely defined by open standards and open source technologies is the secret sauce that makes all this modularity and orchestration possible, and standardized and documented APIs offer the means of communication between distributed components of a larger application. In theory, anyway, this standardization means that every component should be able to communicate with other components of an application without knowing about their inner workings, or about the inner workings of the various platform layers on which everything operates.

DevOps, agile methodologies, and infrastructure as code. Because cloud-native applications exist as a series of small, discrete units of functionality, cloud-native teams can build and update them using agile philosophies like DevOps, which promotes rapid, iterative CI/CD development. This enables teams to deliver business value more quickly and more reliably.

The virtualized nature of cloud environments also make them great candidates for infrastructure as code (IaC), a practice in which teams use tools like Terraform, Pulumi, and AWS CloudFormation, to manage infrastructure declaratively and version those declarations just like application code. IaC boosts automation, repeatability, and resilience across environments—all big advantages in the cloud world. IaC also goes hand-in-hand with the concept of immutable infrastructure—the idea that, once deployed, infastructure-level entities like virtual machines, containers, or network appliances don’t change, which makes them easier to manage and secure. IaC stores declarative configuration code in version control, which creates an audit log of any changes.

Foundry

How the cloud-native stack is expanding

As cloud-native development becomes the norm, the cloud-native ecosystem is expanding; the CNCF maintains a graphical representation of what it calls the  cloud native landscape that hammers home to expansive and bewildering variety of products, services, and open source projects that contribute to (and seek to profit from) to cloud-native computing. And there are a number of areas where new and developing tools are complicating the picture sketched out by the pillars we discussed above.   

An expanding Kubernetes ecosystem. Kubernetes is complex, and teams now rely on an entire ecosystem of projects to get the most out of it: Helm for packaging, ArgoCD for GitOps-style deployments, and Kustomize for configuration management. And just as Kubernetes augmented Docker for enterprise-scale deployments. Kubernetes itself has been augmented and expanded by service mesh offerings like Istio and Linkerd, which offer fine-grained traffic control and improved security

Observability needs. The complex and distributed world of cloud-native computing requires in-depth observability to ensure that developers and admins have a handle on what’s happening with their applications. Cloud-native observability uses distributed tracing and aggregated logs to provide deep insight into performance and reliability. Tools like Prometheus, Grafana, Jaeger, and OpenTelemetry support comprehensive, real-time observability across the stack.

Serverless computing.  Serverless computing, particularly in its function-as-a-service guise, offers to strip needed compute resources down to their bare minimum, with functions running on service provider clouds using exactly as much as they need and no more. Because these services can be exposed as endpoints via APIs, they are increasingly integrated into distributed applications, operating side-by-side with functionality provided by containerized microservices. Watch out, though: the big FaaS providers (Amazon, Microsoft, and Google) would love to lock you in to their ecosystems.  

FinOps. Cloud computing was initially billed as a way to cut costs — no need to pay for an in-house data center that you barely use — but in practice it replaces capex with opex, and sometimes you can run up truly shocking cloud service bills if you aren’t careful. Serverless computing is one way to cut down on those costs, but financial operations, or FinOps, is a more systematic discipline that aims to aligns engineering, finance, and product to optimize cloud spending. FinOps best practices make use of those observability tools to best determine what departments and applications are eating up resources.

How cloud-native architecture is adapting to AI workloads

Enterprises deploy larger AI models and make use of more and more real-time inference services. That’s putting demands on cloud-native systems and forcing them to adapt to remain scalable and reliable.

For instance, organizations are re-engineering cloud environments around GPU-accelerated clusters, low-latency networking, and predictable orchestration. These needs align with established cloud-native patterns: containers package AI services consistently, while Kubernetes provides resilient scheduling and horizontal scale for inference workloads that can spike without warning.

Kubernetes itself is changing to better support AI inference, adding hardware-aware scheduling for GPUs, model-specific autoscaling behavior, and deeper observability into inference pipelines. These enhancements make Kubernetes a more natural platform for serving generative AI workloads.

AI’s resource demands are amplifying traditional cloud-native challenges. Observability becomes more complex as inference paths span GPUs, CPUs, vector databases, and distributed storage. FinOps teams contend with cost volatility from training and inference bursts. And security teams must track new risks around model provenance, data access, and supply-chain integrity.

Application frameworks for building distributed cloud-native apps

Microsoft’s Aspire is one of the most visible examples of a shift towards application frameworks to simplify how teams build distributed systems. Opinionated frameworks like Aspire provide structure, observability, and integration out of the box so developer don’t need to stitch together containers, microservices, and orchestration tooling by hand.

Aspire in particular is a prescriptive framework for cloud-native applications, bundling containerized services, environment configuration, health checks, and observability into a unified development model. Aspire provides defaults for service-to-service communication, configuration, and deployment, along with a built-in dashboard for visibility across distributed components.

While Aspire was originally aligned with Microsoft’s .NET platform,Redmond now sees it as having a  polyglot future. This positions Aspire as part of a broader trend: frameworks that help teams build cloud-native, service-oriented systems without being locked into a single language ecosystem. Several other frameworks are gaining traction: Dapr provides a portable runtime that abstracts many of the plumbing tasks in cloud-native distributed applications, and Orleans offers an actor-model-based framework for large-scale systems in the .NET world, and Akka gives JVM teams a mature, reactive toolkit for elastic, resilient services.

Frameworks and tools in the expanding cloud-native ecosystem

While frameworks like Aspire simplify how developers compose and structure distributed applications, most cloud-native systems still depend on a broader ecosystem of platforms and operational tooling. This deeper layer is where much of the complexity—and innovation—of cloud-native computing lives, particularly as Kubernetes continues to serve as the industry’s control plane for modern infrastructure.

Kubernetes provides the core abstractions for deploying and orchestrating containerized workloads at scale. Managed distributions such as Google Kubernetes Engine (GKE), Amazon EKS, Azure AKS, and Red Hat OpenShift build on these primitives with security, lifecycle automation, and enterprise support. Platform vendors are increasingly automating cluster operations—upgrades, scaling, remediation—to reduce the operational burden on engineering teams.

Surrounding Kubernetes is a rapidly expanding ecosystem of complementary frameworks and tools. Service meshes like Istio and Linkerd provide fine-grained traffic management, policy enforcement, and mTLS-based security across microservices. GitOps platforms such as Argo CD and Flux bring declarative, version-controlled deployments to cloud-native environments. Meanwhile, projects like Crossplane turn Kubernetes into a universal control plane for cloud infrastructure, letting teams provision databases, queues, and storage through familiar Kubernetes APIs. These tools illustrate how cloud-native development now spans multiple layers: developer-focused application frameworks like Aspire at the top, and a powerful, evolving Kubernetes ecosystem underneath that keeps modern distributed applications running.

Advantages and challenges for cloud-native development

Cloud native has become so ubiquitous that its advantages are almost taken for granted at this point, but it’s worth reflecting on the beneficial shift the cloud native paradigm represents. Huge, monolithic codebases that saw updates rolled out once every couple of years have been replaced by microservice-based applications that can be improved continuously. Cloud-based deployments, when managed correctly, make better use of compute resources and allow companies to offer their products as SaaS or PaaS services. 

But cloud-native deployments come with a number of challenges, too:

• Complexity and operational overhead: You’ll have noticed by now that many of the cloud-native tools we’ve discussed, like service meshes and observability tools, are needed to deal with the complexity of cloud-native applications and environments. Individual microservices are deceptively simple, but coordinating them all in a distributed environment is a big lift.
• Security: More services executing on more machines, communicating by open APIs, all adds up to a bigger attack surface for hackers. Containers and APIs each have their own special security needs, and a policy engine can be an important tool for imposing a security baseline on a sprawling cloud-native app. DevSecOps, which adds security to DevOps, has become an important cloud-native development practice to try to close these gaps.
• Vendor lock-in: This may come as a surprise, since cloud-native is based on open standards and open source. But there are differences in how the big cloud and serverless providers works, and once you’ve written code with one provider in mind, it can be hard to migrate elsewhere.
• A persistent skills gap: Cloud-native computing and development may have years under its belt at this point, but the number of developers who are truly skilled in this arena is a smaller portion of the workforce than you’d think. Companies face difficult choices in bridging this skills gap, whether that’s bidding up salaries, working to upskill current workers, or allowing remote work so they can cast a wide net. 

Cloud native in the real world

Cloud native computing is often associated with giants like Netflix, Spotify, Uber, and AirBNB, where many of its technologies were pioneered in the early ’10s. But the CNCF’s Case Studies page provides an in-depth look at how cloud native technologies are helping companies. Examples include the following:

• A UK-based payment technology company that can switch between data centers and clouds with zero downtime
• A software company whose product collects and analyzes data from IoT devices — and can scale up as the number of gadgets grows
• A Czech web service company that managed to improve performance while reducing costs by migrating to the cloud

Cloud-native infrastructure’s capability to quickly scale up to large workloads also make it an attractive platform for developing AI/ML applications: another one of those CNCF case studies looks at how IBM uses Kubernetes to train its Watsonx assistant. The big three providers are putting a lot of effort into pitching their platforms as the place for you to develop your own generative AI tools, with offerings like Azure AI Foundry,Google Firebase Studio, and Amazon Bedrock. It seems clear that cloud native technology is ready for what comes next.

Learn more about related cloud-native technologies:

• Platform-as-a-service (PaaS) explained
• What is cloud computing
• Multicloud explained
• Agile methodology explained
• Agile development best practices
• Devops explained
• Devops best practices
• Microservices explained
• Microservices tutorial
• Docker and Linux containers explained
• Kubernetes tutorial
• CI/CD (continuous integration and continuous delivery) explained
• CI/CD best practices

Docker is a software platform for building applications based on containers—small and lightweight execution environments that make shared use of the operating system kernel but otherwise run in isolation from one another. While containers have been used in Linux and Unix systems for some time, Docker, an open source project launched in 2013, helped popularize the technology by making it easier than ever for developers to package their software to “build once and run anywhere.”

A brief history of Docker

Founded as DotCloud in 2008 by Solomon Hykes in Paris, what we now know as Docker started out as a platform as a service (PaaS) before pivoting in 2013 to focus on democratizing the underlying software containers its platform was running on.

Hykes first demoed Docker at PyCon in March 2013, explaining that Docker was created because developers kept asking for the underlying technology powering the DotCloud platform. “We did always think it would be cool to be able to say, ‘Yes, here is our low-level piece. Now you can do Linux containers with us and go do whatever you want, go build your platform.’ So that’s what we are doing.”

And so, Docker was born, with the open source project quickly picking up traction with developers and attracting the attention of high-profile technology providers like Microsoft, IBM, and Red Hat, as well as venture capitalists willing to pump millions of dollars into the innovative startup. The container revolution had begun.

What are containers?

As Hykes described it in his PyCon talk, containers are “self-contained units of software you can deliver from a server over there to a server over there, from your laptop to EC2 to a bare-metal giant server, and it will run in the same way because it is isolated at the process level and has its own file system.”

The components for doing this have long existed in operating systems like Linux. By simplifying their use and giving these bits a common interface, Docker quickly became close to a de facto industry standard for containers. Docker let developers deploy, replicate, move, and back up a workload in a single, streamlined way, using a set of reusable images to make workloads more portable and flexible than previously possible.

Also see: Why you should use Docker and OCI containers.

In the virtual machine (VM) world, something similar could be achieved by keeping applications separate while running on the same hardware. But each VM requires its own operating system, meaning VMs are typically large, slow to start up, difficult to move around, and cumbersome to maintain and upgrade.

Containers represent a defined shift from the VM era, in that they isolate execution environments while sharing the underlying OS kernel. As a result, they are speedier and far more lightweight than VMs.

Docker: The component parts

Docker took off with software developers as a novel way to package the tools required to build and launch a container. It was more streamlined and simplified than anything previously possible. Broken down into its component parts, Docker consists of the following:

• Dockerfile: Each Docker container starts with a Dockerfile. This text file provides a set of instructions to build a Docker image, including the operating system, languages, environmental variables, file locations, network ports, and any other components it needs to run. Provide someone with a Dockerfile and they can recreate the Docker image wherever they please, although the build process takes time and system resources.
• Docker image: Like a snapshot in the VM world, a Docker image is a portable, read-only executable file. It contains the instructions for creating a container and the specifications for which software components to run and how the container will run them. Docker images are far larger than Dockerfiles but require no build step: They can boot and run as-is.
• Docker run utility: Docker’s run utility is the command that launches a container. Each container is an instance of an image, and multiple instances of the same image can be run simultaneously.
• Docker Hub: Docker Hub is a repository where container images can be stored, shared, and managed. Think of it as Docker’s own version of GitHub, but specifically for containers.
• Docker Engine: Docker Engine is the core of Docker. It is the underlying client-server technology that creates and runs the containers. The Docker Engine includes a long-running daemon process called dockerd for managing containers, APIs that allow programs to communicate with the Docker daemon, and a command-line interface.
• Docker Compose: Docker Compose is a command-line tool that uses YAML files to define and run multicontainer Docker applications. It allows you to create, start, stop, and rebuild all the services from your configuration and view the status and log output of all running services.
• Docker Desktop: All of these component parts are wrapped in Docker’s Desktop application, providing a user-friendly way to build and share containerized applications and microservices.

Advantages of Docker

Docker containers provide a way to build applications that are easier to assemble, maintain, and move around than previous methods allowed. That provides several advantages to software developers:

• Docker containers are minimalistic and enable portability: Docker helps to keep applications and their environments clean and minimal by isolating them, which allows for more granular control and greater portability.
• Docker containers enable composability: Containers make it easier for developers to compose the building blocks of an application into a modular unit with easily interchangeable parts, which can speed up development cycles, feature releases, and bug fixes.
• Docker containers make orchestration and scaling easier: Because containers are lightweight, developers can launch many of them for better scaling of services, and each container instance launches many times faster than a VM. These clusters of containers do then need to be orchestrated, which is where a platform like Kubernetes typically comes in.

Also see: How to succeed with Kubernetes.

Drawbacks of Docker

Containers solve a great many problems, but they don’t solve them all. Common complaints about Docker include the following:

• Docker containers are not virtual machines: Unlike virtual machines, containers use controlled portions of the host operating system’s resources, which means elements aren’t as strictly isolated as they would be on a VM.
• Docker containers don’t provide bare-metal speed: Containers are significantly more lightweight and closer to the metal than virtual machines, but they do incur some performance overhead. If your workload requires bare-metal speed, a container will get you close but not all the way there.
• Docker containers are stateless and immutable: Containers boot and run from an image that describes their contents. That image is immutable by default—once created, it doesn’t change. But a container instance is transient. Once removed from system memory, it’s gone forever. If you want your containers to persist state across sessions, like a virtual machine, you need to design for that persistence.

Docker today

Container usage has continued to grow in tandem with cloud-native development, now the dominant model for building and running software. But these days, Docker is only a part of that puzzle.

Docker grew popular because it made it easy to move the code for an application and its dependencies from the developer’s laptop to a server. But the rise of containers led to a shift in the way applications were built—from monolithic stacks to networks of microservices. Soon, many users needed a way to orchestrate and manage groups of containers at scale.

Launched at Google, the Kubernetes open source project quickly emerged as the best way to orchestrate containers, superseding Docker’s own attempts to solve this problem with Docker Swarm (RIP). Amidst increasing funding trouble, Docker eventually sold its enterprise business to Mirantis in 2019, which has since absorbed Docker Enterprise into the Mirantis Kubernetes Engine.

The remains of Docker—which includes the original open source Docker Engine container runtime, Docker Hub image repository, and Docker Desktop application—live on under the leadership of company veteran Scott Johnston, who is looking to reorient the business around its core customer base of software developers.

The Docker Business subscription service, and the revised Docker Desktop product, both reflect those new goals: Docker Business offers tools for managing and rapidly deploying secure Docker instances, and Docker Desktop requires paid usage for organizations with more than $10 million in annual revenue and 250 or more employees. But there’s also the Docker Personal subscription tier, for individuals and companies that fall below those thresholds, so end users still have access to many of Docker’s offerings.

Docker has other offerings suited to the changing times. Docker Hardened Images, available in both free and enterprise tiers, provide application images with smaller attack surfaces and checked software components for better security. And, in step with the AI revolution, the Docker MCP Catalog and Toolkit provide Dockerized versions of tools that give AI applications broader functionality (such as by allowing access to the file system), making it easier to deploy AI apps with less risk to the surrounding environment.

Almost every company has a board or executive AI mandate. Vendors are rolling out agentic AI platforms. The pressure to move is intense.

But the reality on the ground looks different. Eighty-three percent of organizations say data quality is their top AI challenge, and 74% struggle to demonstrate ROI, according to Lopez Research. And only 21% report having a mature governance model for AI agents, per Deloitte’s 2026 State of Enterprise AI report.

“Agentic AI is real, and vendors’ offerings are very real, too,” says Boris Evelson, vice president and principal analyst at Forrester. “However, most enterprises are still not ready to adopt at scale.”

Dave Hilborn, who leads West Monroe’s Organization, People & Change practice, frames it as a race with three arrows moving forward — one representing AI and tech evolution, one representing organizations and people, and one representing data. “The AI arrow is far out ahead,” he says. “That delta is the readiness gap.”

The gap isn’t the technology. It’s the foundational work most organizations haven’t done: data readiness, operating models, governance, skills, and culture. The companies making progress aren’t waiting for vendors to solve these problems. They’re tackling the unglamorous work themselves.

AI doesn’t tolerate ambiguity

AI readiness can be framed across six levels — from data foundation at the base to reinvented business experiences at the top, says Afshean Talasaz, former CIO at Colonial Pipeline and now an executive advisor. One of the key areas that doesn’t always get the attention it needs is the operating model.

“The technology playbooks of the past don’t work in the AI world,” Talasaz says. “Those areas were able to tolerate more ambiguity between business and tech teams. AI doesn’t tolerate the same level of ambiguity. It needs clarity.”

That demands a different kind of partnership between IT and the business. AI systems learn from data — records and measurements of what’s actually happening in the business — and then operate within business processes. Unlike traditional software, which is built based on user requirements, AI is sandwiched between the business that produces the data and the business that consumes the outputs.

“AI is requiring IT and business teams to work more closely together, to be clearer about what AI will and will not do — that really close partnership is crucial,” Talasaz says. “It’s not something that will always naturally evolve. It requires a lot of intentionality about how teams need to work together to deliver outcomes.”

The AI questions CIOs must answer aren’t just technical. Do we have the right operating model? Have we balanced governance and standard operating procedures within the model? Have we organized teams appropriately? All this must be designed within the context of what the business actually needs.

Too many organizations are bolting AI onto existing processes without redefining roles or workflows, Forrester’s Evelson. “Organizations can either incrementally enhance existing workflows by augmenting capabilities with AI or pursue a more transformative approach by redesigning the process end-to-end.”

The companies getting value are doing the latter.

Data debt comes due

Data readiness remains the most common barrier to scaling AI. “We’ve never fixed this data quality problem in most organizations,” says Maribel Lopez, founder and principal analyst at Lopez Research, “and it comes back to haunt a company in spades as they move to AI.”

At Levi Strauss, the foundational work came first. “If you think about the Levi’s business, it’s quite complex — 100 countries, over 3,000 stores, multiple business models,” says Jason Gowans, the company’s chief digital and technology officer. “You can imagine the complexity of gathering all that data to understand how the business is performing. The idea of this single source of truth — that’s been the biggest thing.”

Levi’s now has more than 1,100 standard operating procedures that govern how work gets done on top of SAP. “That’s fertile material to feed to LLMs on how work gets done,” Gowans says.The results are tangible: partner onboarding that once took three to six months to set up EDI exchanges now takes days.

At contract manufacturing company Jabil, Chase Christensen, segment CIO, took a similar path. “We had to get everyone to understand where the source data resides, put tech in place so consumption is easier, and drive ownership around data and decision rights — so 140,000 employees don’t feel empowered to create their own data sources that fall out of line.”

The data challenge goes beyond quality, Evelson notes. Most organizations’ data isn’t AI-ready; it hasn’t been prepared for how AI systems consume and learn from information. “Data is siloed, poorly governed, and hard to discover, integrate, and trust,” he says.

Forrester research shows that 45% of data and analytics decision-makers were adopting vector databases in 2025, and 53% were adopting graph databases — investments that signal recognition of how much data architecture needs to evolve. The firm recommends a balanced approach: roughly 48% of AI spending on foundations such as data management and engineering, and 52% on consumption, including analytics, governance, and applications.

But even as organizations work to prepare existing data, AI is creating new challenges. Users leveraging AI tools are generating new forms of data and information that never make it into corporate databases, West Monroe’s Hilborn notes.

“There are explosions of new data, content, and insights being created on the periphery of these data lakes,” he says. “The challenge is how do you capture that and leverage it.”

Who’s sponsoring this?

Even when data is in order, many AI initiatives stall due to how they’re sponsored and funded.

“Enterprise data, analytics, and AI programs succeed when business CxOs sponsor them because they are accountable for business outcomes, not just technology delivery,” Forrester’s Evelson says. “IT-led initiatives often become siloed or tool-centric, whereas business sponsorship ensures alignment to enterprise strategy, prioritization of end-to-end use cases, and a focus on decisions and actions rather than insights alone.”

Too often, AI is still treated as a series of disconnected use cases rather than a sustained, multi-year investment. Evelson calls this the “use case trap” — organizations overindex on individual projects and miss the enterprise-wide compounding impact. That leads to fragmented priorities, inconsistent adoption, and difficulty demonstrating ROI.

Leadership readiness is a distinct layer of AI preparedness, Talasaz says. “Are leaders prepared to provide a vision of reinvented business experiences that become the north star?” he asks. “Leadership teams, at various levels of the organization, need to articulate what a reinvented business looks like so teams have the direction and support to build differentiating capabilities.”

Levi’s offers a counterexample. AI is a CEO priority there. At the last quarterly offsite, the execs were building agents. “When you’re committed to upskilling the workforce, you’re better served to answer how to rewire processes with AI at the core,” Gowans says. “It starts at the top. It has to be an exec priority.”

Fear, literacy, and two types of AI

Technical talent is only part of the equation. Organizations also need to address change management.

“We saw it with the AI boom — fear about jobs, not knowing what AI did,” says Jabil’s Christensen. “The key is demystifying AI. We doubled down and focused on AI literacy. We want everyone to understand how it was put together, and that removed a lot of that fear. That’s been the biggest hurdle.”

Different types of AI require different skills and governance, Talasaz says. “General use focuses on productivity on the desktop,” he says. “Integrated AI — industrial-capable AI embedded within core business processes — requires different skills, capabilities, and governance.”

For desktop AI, training and guardrails help employees be successful — what Talasaz calls “bumpers,” like in bowling. Organizations need to help employees through reskilling and guidance. “You have tools in a toolbox,” he says. “It’s important to know when to use a power tool versus when you need a screwdriver.”

But for integrated AI embedded in core processes, the stakes are higher. “Business leaders responsible for business outcomes based on AI-driven processes need to be fully aware of both the benefits and risks that come along with using these tools,” Talasaz says.

That distinction matters for governance, too. Lower-, medium-, and high-risk AI use cases may require different ways of working and different risk management approaches. “Deploying AI in potentially high-risk or high-cost areas of the business requires a higher level of rigor,” Talasaz says. “That’s different than building something that helps write my emails.”

From POC to production

Perhaps the biggest readiness gap is the transition from proof of concept to production. “It requires such a different approach,” Talasaz says. “A successful proof of concept can create a lot of excitement, but when teams are unprepared to build and scale, it can create the potential to over-promise and under-deliver.”

The operating model that works for experimentation doesn’t work for production at scale. Proofs of concept are designed to demonstrate the efficacy of ideas and the underlying technology. But building, scaling, and sustaining technology in the business requires operating models, standards, roles, and skills that many organizations haven’t developed. Intentionally designed operating models reduce the cost of learning, improve execution, and increase delivery velocity, says Talasaz.

But there’s no one-size-fits-all answer. “A business that needs to build capabilities in a marketplace moving very fast requires one kind of operating model,” Talasaz says. “A business that can take longer to develop business capabilities and adapt to market changes can choose a different operating model. It’s important to design ways of working tailored to what the business needs and the speed at which the business needs to leverage technology to be successful.”

Jabil is navigating this journey as part of its move to SAP’s cloud ERP through RISE, scaling from $29 billion to $34 billion in revenue while keeping selling, general, and administrative (SG&A) expenses relatively flat — in part by layering generative AI onto predictive analytics capabilities built over years.

“We started years ago with computer vision to drive product quality,” Christensen says. “As gen AI blew up, we took the predictive analytics we had built over the years and imbued them with gen AI. We’ve implemented the basics, and now we’re looking for complex scenarios.”

Governance built in, not bolted on

Governance is often treated as a policy document or committee. It should be embedded in the operating model itself, Talasaz argues.

“The operating model doesn’t always get the attention it needs,” he says. “Policies and committees are useful, but they should handle larger enterprise risks. Most of the governance should be embedded in the operating model to ensure you’re getting outcomes you want.”

That might mean peer review built into the development process, bias checks before deployment, or clear escalation paths for high-risk use cases. When governance is separate from the operating model, it tends to slow things down. When it’s integrated, it becomes how work naturally gets done, says Talasaz.

Governance at the agent level matters, too, Levi’s Gowans says. “Know what agents have been deployed, who authored them, and who’s responsible,” he says, noting that the company has established a registry to understand what agents it has operating within its networks.

The challenges of AI governance are unique, Lopez of Lopez Research says. “Very few people have the governance stack required to say they did the right things with AI,” she says. “Non-human identity and access control is totally different and, frankly, evolving so quickly that no one knows what to do.”

The challenge is ultimately a trade-off, Forrester’s Evelson says. “Push agentic AI capabilities too far, and you risk creating a governance and compliance nightmare,” he says. “Tighten controls too aggressively, and you stifle innovation. Best practices for striking the right balance are still being discovered.”

It takes a team

The AI readiness gap isn’t about technology — it’s about the work organizations have been deferring for years. Data quality. Operating models. Executive sponsorship. Skills and culture. Governance embedded in process.

“Once you progress from everyone using Copilot to putting agents in production, then you realize the need for business context,” Gowans of Levi Strauss says.

It’s a shared journey requiring all teams to understand what’s required, Talasaz says. “It involves helping people understand what it takes from all sides — the technology itself, the operating model, the skills and talents needed — but also working with business leaders on the art of the possible,” he says. “Helping them understand both the benefits and the responsibility of deploying this tech.”

A colleague of his calls AI “the ultimate executive team sport.”

“It requires people to do it well and manage it,” Talasaz says.

AI tools today enable faster processes, leaner operations and lower costs, making efficiency wins the new baseline. However, for many businesses, the strategy stops at those first wins.

This has created a growing leadership blind spot: Once you achieve AI ROI, how do you make the most of it? If there is no clear reinvestment strategy, AI gains burn out quickly and disappear into the business without meaningfully compounding their value.

For CIOs, the next challenge is not just proving AI can make the business more efficient but deciding how those gains can build a stronger company and sustain growth over the long term.

Start by investing in a crystal ball

One of the smartest ways to reinvest AI gains is to improve how the business evaluates what is worth building in the first place.

Leaders who chase “cool” use cases without defining the business impact or path to ROI upfront often end up with systems that drain funds without creating compounding returns. Instead, a clear reinvestment strategy uses AI to assess the strongest use cases before scaling up.

AI tools today can help teams move from idea to prototype to impact analysis much faster than before. That makes it easier to identify which projects have a credible path to ROI and which ones can be filed away. Access to these quick insights allows businesses to test whether a use case has real value before committing larger engineering or model costs.

This is especially crucial right now as AI is becoming more costly as businesses scale it. What looked inexpensive in early pilots can become far pricier once it is embedded in day-to-day work and as AI providers tokenize and meter its use. The more central AI becomes, the more intentional leaders need to be about where it is used, what it actually returns and how to reinvest those gains.

Not every workflow belongs in the same model. Not every task needs an agent. As AI vendors mature and monetization models evolve, the businesses that will win will be the ones that make those distinctions early, reinvest accordingly and keep building ahead of customer needs rather than reacting to them. Not every workflow belongs in the same model. Not every task needs an agent.

Cycle ROI gains back into tooling

Once AI activations start to show dividends, it’s time to reinvest in stronger tooling. This should include new AI tools that continue to advance the business, as well as continued investment in what has already worked. That compounding effect is ultimately what separates businesses that sustain AI-driven growth from those that plateau after early wins.

I’ve seen firsthand the benefits of investing in new tools that make AI more usable, repeatable and valuable in workflows. For example, automated product management tools enable rapid prototyping and product rationalization. Decision intelligence platforms can help teams simulate scenarios. Customer behavior modeling tools can help predict churn and shift customer demand patterns. These advanced solutions can help teams move from an idea to a working concept in days instead of months.

Smart reinvestment is about building the right technical mix for the outcomes the business needs, rather than funding more AI for its own sake. To maximize impact, start with tooling for governance and upskilling.

1. (Re)invest in governance

As AI usage spreads and matures across teams, products and functions, a strategic policy framework becomes all the more vital. CIOs should work to reinforce the governance foundations already in place so they can support broader adoption, rather than rebuilding new policy from scratch each time AI usage expands. This means reinvesting in shared standards, oversight mechanisms and supporting roles that make governance more durable and practical over time.

Without doubling down on governance, businesses risk creating siloed, disconnected pockets of experimentation. Those pockets quickly become expensive to monitor and difficult to secure, creating further risk to consistency, compliance and trust. The consequence is often wasted spend as experiments stall or overlap, or outcomes that are too fragmented to scale.

When businesses keep governance investment at the center of their reinvestment strategy, it becomes a force multiplier. It reduces duplication across teams, creates more commonality across products and makes it easier to expand AI use without increasing fragmentation or risk.

2. Empower employees to grow

Smart tools only create real value when people are equipped to use them well. That is why reinvestment should go beyond technology alone.

As AI tools become more powerful and accurate, the skills barrier to building something useful is dropping. Employees can get much closer to a viable concept much faster with AI, but that only works if businesses create learning pathways, academies and practical enablement that help teams use these tools well.

Smarter tooling can help product, operations and technology teams collaborate with fewer layers between idea and execution. As employees build new skills, they can stay closer to a single initiative from start to finish. That reduces handoffs, empowers employees to learn new skills and offers a more direct path from the original idea to the final result.

Let AI ROI fund your fight against siloes

Over the next few years, the businesses that pull ahead are not simply going to be the ones with the most AI pilots or the biggest efficiency gains. They will be the ones that invest AI ROI in bridging what has long been disconnected: systems, teams, workflows and ecosystems.

In telecom, for example, AI is already creating savings inside billing operations and other back-office work tied to the BSS layer. The smart move for telcos is not to stop at those savings, but to reinvest them in connecting their BSS and OSS, where fragmentation and siloes have long slowed telcos down.

Think about what that means in practice: instead of billing, service configuration and network operations functioning as separate systems with separate handoffs, AI can help orchestrate them. That makes it easier to move from order to activation to support with less internal friction, better visibility and fewer breakdowns between what was sold and what is actually delivered.

For the customer, that means a broadband outage, plan change or installation appointment is handled as one connected journey rather than a chain of handoffs. The outcome is a more connected operating model that makes the customer experience feel far less complex.

The same logic applies across industries. In banking, a customer with a mortgage, checking account and credit card at the same institution is often still treated as three separate relationships – because the underlying systems do not communicate. AI orchestration can change that, giving banks a unified view of the customer and employees the context to act on it.

Not using AI to do the same work faster, but using AI dividends to build a business that works better. That is what smart investment looks like.

ROI is just the start

AI can absolutely free up capital. That, however, is only the first chapter.

The bigger story is what leaders choose to do next: reinvest in better tooling, more consistent governance, smarter workforce enablement and operating models built to connect across silos. The payoff will be a more resilient, agile business ready for what’s next.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

OpenAI is sharpening its enterprise AI strategy with the launch of ChatGPT Work, a new agentic platform designed to automate workplace tasks, alongside the broader rollout of its GPT-5.6 models, which the company says deliver stronger performance at lower operating costs.

According to the company, ChatGPT Work can operate across applications and files, execute long-running tasks, coordinate multiple tools, and produce business documents, presentations, spreadsheets, and websites, allowing employees to delegate more complex workflows rather than interact through individual prompts.

GPT- 5.6 models, generally available weeks after a limited preview following US government restrictions on their broader rollout due to concerns about advanced cybersecurity and biology capabilities, can deliver stronger performance across coding, enterprise knowledge work, cybersecurity, and scientific research while lowering inference costs and token consumption, OpenAI said.

The launch marks a shift in OpenAI’s enterprise strategy. Rather than emphasizing benchmark leadership alone, the company is pitching GPT-5.6 around performance per dollar, arguing that enterprises deploying AI at scale increasingly care as much about operating costs as raw model capability.

“We trained GPT-5.6 to get more useful work from every token,” OpenAI said in a statement. “The result is stronger performance per dollar: more successful work for the same spend, or comparable results at a lower total cost.”

The models are now generally available through ChatGPT, Codex, and the OpenAI API. OpenAI has priced Sol at $5 per million input tokens and $30 per million output tokens, while Terra and Luna provide progressively lower-cost options for organizations scaling AI deployments, the statement added.

Enterprise AI shifts from experimentation to economics

ChatGPT Work combines GPT-5.6 with enterprise integrations and agentic capabilities that allow users to perform multi-step tasks across connected business applications instead of interacting with AI through isolated prompts. OpenAI said the platform is designed to help organizations automate knowledge work while maintaining enterprise-grade governance and security.

The launch comes as enterprises move beyond AI experimentation and begin deploying models across production workloads, making inference costs a growing concern for CIOs.

“The AI wave has brought productivity gains, but rising token consumption has also created bill shocks for enterprises,” said Neil Shah, vice president for research and partner at Counterpoint Research. “This is forcing organizations to adopt different models for different workloads, making performance per dollar the key metric.”

Faisal Kawoosa, co-founder and chief analyst at Techarc, said enterprises are now evaluating AI investments more pragmatically.

“The exploratory stage of AI is over,” he said. “Organizations can derive value from AI today, but performance per dollar will determine whether it becomes part of everyday business operations or remains an ad hoc tool.”

Tiered models for different workloads

GPT-5.6 Sol is OpenAI’s flagship model for complex reasoning, Terra targets mainstream enterprise applications, and Luna is designed for lower-cost, high-volume deployments.

According to OpenAI, GPT-5.6 Sol scored 53.6 on Agents’ Last Exam, a benchmark for long-running professional workflows, outperforming competing frontier models while requiring significantly lower compute costs.

The company also introduced two new reasoning modes. The max mode allocates additional compute for complex problems, while ultra coordinates four AI agents in parallel to accelerate demanding workflows.

“Ultra goes further by coordinating four agents in parallel by default, trading higher token use for stronger results and faster time-to-result on demanding tasks,” the statement added.

Shah said the architecture reflects how enterprises are increasingly orchestrating multiple AI models.

“GPT-5.6 gives enterprise architects flexibility to route workloads from Luna to Sol depending on whether they require automation, logic, or complex reasoning,” he said.

Kawoosa added that the tiered approach aligns with how enterprise software has traditionally been consumed.

“It gives enterprises of different sizes the flexibility to optimize technology consumption according to their requirements,” he said.

Coding, productivity, and security gains

OpenAI said GPT-5.6 Sol achieved a score of 80 on the Artificial Analysis Coding Agent Index while consuming fewer than half the output tokens of competing models. It also reported state-of-the-art results on Terminal-Bench 2.1 and DeepSWE, benchmarks that measure real-world software engineering tasks.

The company said the models also improve enterprise productivity through stronger document generation capabilities and integrations with Microsoft 365, Google Drive, Slack, and Notion.

On cybersecurity, GPT-5.6 Sol scored 73.5% on ExploitBench, up from 47.9% for GPT-5.5, and nearly doubled its predecessor’s performance on ExploitGym.

“GPT-5.6 supports important defensive tasks such as secure code review, patching, threat modeling, and blue teaming,” OpenAI said.

Security remains an enterprise focus

OpenAI said GPT-5.6 incorporates its “most robust safeguards to date,” combining model-level protections with real-time monitoring and extensive safety testing, including approximately 700,000 GPU hours of automated red-team evaluations.

Shah said layered guardrails and monitoring could become an important differentiator for enterprise deployments.

Kawoosa, however, said CIOs will continue demanding greater transparency before fully trusting frontier AI systems.

“Competition among LLM providers will continue, with vendors constantly testing and challenging each other’s guardrails,” he said.

The article originally appeared on InfoWorld.

OpenAI is sharpening its enterprise AI strategy with the launch of ChatGPT Work, a new agentic platform designed to automate workplace tasks, alongside the broader rollout of its GPT-5.6 models, which the company says deliver stronger performance at lower operating costs.

According to the company, ChatGPT Work can operate across applications and files, execute long-running tasks, coordinate multiple tools, and produce business documents, presentations, spreadsheets, and websites, allowing employees to delegate more complex workflows rather than interact through individual prompts.

GPT- 5.6 models, generally available weeks after a limited preview following US government restrictions on their broader rollout due to concerns about advanced cybersecurity and biology capabilities, can deliver stronger performance across coding, enterprise knowledge work, cybersecurity, and scientific research while lowering inference costs and token consumption, OpenAI said.

The launch marks a shift in OpenAI’s enterprise strategy. Rather than emphasizing benchmark leadership alone, the company is pitching GPT-5.6 around performance per dollar, arguing that enterprises deploying AI at scale increasingly care as much about operating costs as raw model capability.

“We trained GPT-5.6 to get more useful work from every token,” OpenAI said in a statement. “The result is stronger performance per dollar: more successful work for the same spend, or comparable results at a lower total cost.”

The models are now generally available through ChatGPT, Codex, and the OpenAI API. OpenAI has priced Sol at $5 per million input tokens and $30 per million output tokens, while Terra and Luna provide progressively lower-cost options for organizations scaling AI deployments, the statement added.

Enterprise AI shifts from experimentation to economics

ChatGPT Work combines GPT-5.6 with enterprise integrations and agentic capabilities that allow users to perform multi-step tasks across connected business applications instead of interacting with AI through isolated prompts. OpenAI said the platform is designed to help organizations automate knowledge work while maintaining enterprise-grade governance and security.

The launch comes as enterprises move beyond AI experimentation and begin deploying models across production workloads, making inference costs a growing concern for CIOs.

“The AI wave has brought productivity gains, but rising token consumption has also created bill shocks for enterprises,” said Neil Shah, vice president for research and partner at Counterpoint Research. “This is forcing organizations to adopt different models for different workloads, making performance per dollar the key metric.”

Faisal Kawoosa, co-founder and chief analyst at Techarc, said enterprises are now evaluating AI investments more pragmatically.

“The exploratory stage of AI is over,” he said. “Organizations can derive value from AI today, but performance per dollar will determine whether it becomes part of everyday business operations or remains an ad hoc tool.”

Tiered models for different workloads

GPT-5.6 Sol is OpenAI’s flagship model for complex reasoning, Terra targets mainstream enterprise applications, and Luna is designed for lower-cost, high-volume deployments.

According to OpenAI, GPT-5.6 Sol scored 53.6 on Agents’ Last Exam, a benchmark for long-running professional workflows, outperforming competing frontier models while requiring significantly lower compute costs.

The company also introduced two new reasoning modes. The max mode allocates additional compute for complex problems, while ultra coordinates four AI agents in parallel to accelerate demanding workflows.

“Ultra goes further by coordinating four agents in parallel by default, trading higher token use for stronger results and faster time-to-result on demanding tasks,” the statement added.

Shah said the architecture reflects how enterprises are increasingly orchestrating multiple AI models.

“GPT-5.6 gives enterprise architects flexibility to route workloads from Luna to Sol depending on whether they require automation, logic, or complex reasoning,” he said.

Kawoosa added that the tiered approach aligns with how enterprise software has traditionally been consumed.

“It gives enterprises of different sizes the flexibility to optimize technology consumption according to their requirements,” he said.

Coding, productivity, and security gains

OpenAI said GPT-5.6 Sol achieved a score of 80 on the Artificial Analysis Coding Agent Index while consuming fewer than half the output tokens of competing models. It also reported state-of-the-art results on Terminal-Bench 2.1 and DeepSWE, benchmarks that measure real-world software engineering tasks.

The company said the models also improve enterprise productivity through stronger document generation capabilities and integrations with Microsoft 365, Google Drive, Slack, and Notion.

On cybersecurity, GPT-5.6 Sol scored 73.5% on ExploitBench, up from 47.9% for GPT-5.5, and nearly doubled its predecessor’s performance on ExploitGym.

“GPT-5.6 supports important defensive tasks such as secure code review, patching, threat modeling, and blue teaming,” OpenAI said.

Security remains an enterprise focus

OpenAI said GPT-5.6 incorporates its “most robust safeguards to date,” combining model-level protections with real-time monitoring and extensive safety testing, including approximately 700,000 GPU hours of automated red-team evaluations.

Shah said layered guardrails and monitoring could become an important differentiator for enterprise deployments.

Kawoosa, however, said CIOs will continue demanding greater transparency before fully trusting frontier AI systems.

“Competition among LLM providers will continue, with vendors constantly testing and challenging each other’s guardrails,” he said.

In a client engagement last year, an LLM-based deployment agent with standing access to a production Kubernetes cluster triggered a four-hour outage through a malformed configuration push. In the IAM, the agent appeared as a service account with a long-lived API key, no MFA, no scoped revocation path. When the incident review team asked which human had authorized the agent’s last action, no one in the room could answer. I have watched a version of that question go unanswered in three engagements over the past year, in three different sectors, with three different vendor stacks.

Every CISO deck right now contains a slide about agentic AI. Far fewer contain a slide about who, in identity terms, these agents actually are. That gap is the more dangerous one. The first slide is a strategy question. The second is a control question — and it is the one your auditors, your incident responders and your board will eventually ask. Gartner’s Top Cybersecurity Trends 2026, published by Director Analyst Alex Michaels, names both halves of that gap — agentic AI oversight (Trend 1) and IAM adaptation to AI agents (Trend 4) — as the forces redefining cyber risk this year.

This piece sets out a six-stage maturity model for non-human and agent-based identities (NHIs), the six minimum requirements that have to be met before any production deployment is defensible and the single most consequential reporting decision in the access-and-identity dimension: refusing the arithmetic mean across human and non-human identity governance.

Why agent-based systems break the existing identity model

A conventional service account performs a narrow, predictable task: it fetches a backup, runs a scheduled report, signs a build artifact. Its scope is fixed at design time. The controls around it — rotation, vaulting, audit — are well-understood.

An agent-based system does not work this way. It receives an intent, decomposes it into steps, calls whichever tools or APIs it judges appropriate and produces an outcome that was not specified action-by-action in advance. KuppingerCole’s 2026 Leadership Compass on Non-Human Identity Management notes that NHIs now outnumber human users in many enterprise environments, in some cases by a factor of 25 to 50. The same compass, authored under Principal Analyst Martin Kuppinger, observes that the tooling built around joiner-mover-leaver lifecycles was never designed to discover, attribute or govern these identities at that scale.

The OWASP GenAI Security Project has catalogued the resulting attack surface in two iterations — the Agentic AI Threats & Mitigations taxonomy in February 2025 and the more operational OWASP Top 10 for Agentic Applications later that year, categories ASI01 through ASI10. The notable finding is that three of the four highest-rated risks are identity questions: tool misuse and exploitation (ASI02), identity and privilege abuse including delegated and inherited trust (ASI03) and rogue agents that act outside their intended behavior (ASI10). A fourth, agentic supply chain vulnerabilities (ASI04), is identity adjacent.

CISA’s first joint Five Eyes advisory on the topic — Careful Adoption of Agentic AI Services, published 1 May 2026 with NSA, the Australian Signals Directorate’s ACSC, the Canadian Centre for Cyber Security, NCSC-NZ and NCSC-UK — converges on the same conclusion. Privilege risk is named the foundational concern. The Center for Internet Security followed with its own report on prompt injection as the top compounding risk in April 2026, and NIST’s AI Agent Standards Initiative, launched February 2026, is now drafting the formal standards that will sit alongside this guidance.

In other words, the dominant risk class introduced by agentic AI is not novel cryptography or some new exploit primitive. It is the unbounded scope of an identity that the existing IAM model was never asked to govern.

Six minimum requirements before any agent goes to production

Before any maturity discussion is useful, there is a floor. The following six requirements mark the line below which an agent-based system is not responsibly deployable in an enterprise environment. They are derived from incidents and audit findings I have collected across pharma, energy, finance and manufacturing engagements, and they are technically feasible on modern IAM and PAM platforms — though rarely on the IAM stacks most enterprises actually have today.

• Each agent receives a uniquely attributable non-human identity. Shared service accounts across multiple agents, or shared between an agent and a human administrator, are not acceptable.
• Permissions are granted under an on-behalf-of model. The agent acts on the authority of a named human principal, inheriting that principal’s permissions, scoped to a defined purpose. It never acts from its own standing authority.
• No long-lived credentials. No API key valid for more than an hour. No embedded secrets in code. Short-lived, context-bound credentials only, revocable on anomaly.
• Complete audit trail through SIEM integration. Every agent action is logged with timestamp, executing identity, instructing human principal, input context and outcome.
• Continuous re-authentication. For long-running agents, identity is re-validated risk-based at regular intervals — not just at session start.
• Real-time revocation. The capability to disconnect an agent from systems within seconds is not optional. It is the only control that actually contains an agent-based incident in flight.

An organization that cannot meet all six does not have an agent governance problem. It has a deployment readiness problem. The model below assumes these are in place by Stage 3; anything earlier is the discovery phase.

The six-stage NHI maturity model

Most enterprise maturity scales measure the access-and-identity dimension against the yardstick of human identity: is there central IAM, is MFA enforced for privileged access, does the joiner-mover-leaver lifecycle work? These remain the right questions, but they stop short. An organization that scores Stage 4 on human identity governance and Stage 1 on agent governance does not have a mature identity practice. It has a well-lit half and a blind half.

The following six-stage scale is cumulative — each stage assumes everything below it. The threshold of responsibility sits at Stage 3. In my view, production deployment of agent-based systems below Stage 3 is not defensible to a board, a regulator or an incident review.

Stages 4 and 5 deserve unpacking because they are where the model departs from access control and begins to govern behavior. Bounded means the agent’s mandate has explicit limits it cannot act outside of. Reviewable means every action is logged with intent, execution and result. Reversible means an action can be rolled back before it produces irreversible effect — a hard constraint in any environment where actions touch physical processes, financial transactions or external commitments. Self-regulating means the system detects anomalies in agent behavior and intervenes before a human reasonably could.

The ‘human in the loop’ is not automatically governance

One misconception consistently overrates organizations’ agent governance. The presence of a human in the decision loop is widely treated as sufficient oversight. It is not. If a human is asked to approve hundreds or thousands of agent actions without the time to inspect each one, what exists is not control but an approval automation with a human signature on it. Human review does not scale to the action volume of an autonomous system.

A mature governance posture acknowledges this. It moves control from per-action approval to structural constraint: bound what the agent can do at all, monitor its behavior for anomaly and ensure that oversight is loyal to the principal, not to the executing system. An organization that rests its agent governance entirely on human per-action approvals does not reach Stage 4 of the model, regardless of how thoroughly those approvals are documented. Stage 4 requires structural bounding, not scaling handwork.

OWASP as an audit-ready evidence base

Maturity assessment risks drifting into subjective self-rating. The OWASP categories cited above can be operationalized into audit questions that anchor each stage in checkable evidence:

The column on the right matters. A common rating error is to grade an organization high because it has handled the easy requirements — unique identities, basic logging — without addressing the demanding ones. Tying the upper stages to the difficult criteria prevents that inflation.

Report human and non-human identity separately

The single most consequential reporting decision is to refuse the arithmetic mean. The access-and-identity dimension on a maturity radar should not collapse a Stage 4 human-identity practice and a Stage 1 agent-identity practice into a reassuring middle number. Both ratings belong on the same axis, but they belong reported separately.

A representative finding from current engagements: human identity governance at Stage 4 — central IAM, MFA, lifecycle managed — and agent governance at Stage 1, with agents recently inventoried but still authenticating via long-lived API keys against shared service accounts, without their own audit trail. The combined average would read Stage 2 to 3 and look acceptable. The separate reporting reveals that the unmanaged half is precisely the identity class with the largest and least predictable scope of action. That visibility is what triggers the prioritized roadmap action; an aggregated score buries it.

The named-accountable-owner test

If I run only one diagnostic in a new engagement, this is the one. For every production agent-based system in the environment, ask: who, by name, is accountable if this agent causes harm? An agent without a named accountable owner is the non-human counterpart of the workstation everyone uses, and no one owns. Stage 5 of the model formally requires a named accountable owner per deployed agent. The reason is operational, not bureaucratic: the question ‘who is responsible for this system?’ must be answered before the incident, not during it.

In practice, that accountability binds best to the role that already carries the operational risk of the affected process — typically the asset owner in the business function. Anchoring it there prevents agent-based systems from drifting into the organizational gray zone between IT, security and the business, which is exactly where unattributed action originates.

The maturity model in this article is a starting structure. The honest first step in adopting it is not to score well. It is to score truthfully, report human and non-human identity governance separately and treat the gap between them as the first item on the security roadmap for the agentic-AI period — before the next agent goes to production.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

The hardest thing to manage is change. I wrote that line more than a decade ago in an article about the “XPocalypse,” Microsoft’s end-of-life deadline for Windows XP. My argument then was that the real crisis was not obsolete software. It was the shortage of technically literate professionals capable of guiding organizations through inevitable transitions.

More than a decade later, the names have changed. The lesson has not.

Y2K defined the pattern. The risk was real, but disaster was avoided because skilled people did the work. When nothing happened at midnight (1999-2000), many assumed the threat had been exaggerated instead of recognizing that it had been managed. Windows XP became the next version of the same problem. The operating system stayed embedded in retail, banking, healthcare, energy, law enforcement and defense systems long after it should have been retired. The vulnerability was real, but the larger lesson was mostly missed: organizations let technical debt pile up until a deadline turns it into a crisis.

Is agentic AI actually breaking the enterprise SaaS business model?

Now we have the “SaaSpocalypse.” Headlines warn that agentic AI is breaking the SaaS business model, lowering software valuations and making entire categories of enterprise tools obsolete. Investors are reacting; analysts are talking about “FOBO,” Fear of Becoming Obsolete, and organizations are again asking whether they are ready for what comes next.

The disruption is real. AI agents can now automate workflows that once required dedicated software tools and teams of human operators. The per-seat pricing model that powered two decades of SaaS economics is under pressure. But the apocalyptic framing misdiagnoses the problem. SaaS is not dying. It is bifurcating.

Platforms requiring precision, auditability, complex state management and regulatory accountability, such as financial systems, healthcare records and compliance infrastructure, will remain essential. What is collapsing is the undifferentiated middle: horizontal tools that AI agents can replicate cheaply and at scale.

The organizations most exposed are not simply those using the wrong software. They are those who outsourced technical judgment along with technical execution. They bought SaaS as a substitute for internal capability, accumulated organizational debt and now lack the human capital to navigate a transition that is fundamentally about people and process.

The old taxonomy still applies: people, process and technology. Technology serves business functions. Processes create efficiency. Qualified people sustain both. But the pace of technological change continues to outrun the education system’s ability to produce experienced professionals with current skills.

AI has widened that gap. Data engineers now design orchestration infrastructure that determines whether AI produces value or liability. Security practitioners must govern autonomous agents acting on behalf of enterprises. Business leaders need enough technical fluency to make build-versus-buy decisions in a market changing in real time.

These are not narrow technical tasks. They are the applied outputs of serious STEM education grounded in a business context, professional standards and sustained practice. We are still not producing enough people who have those skills.

How is the growing STEM education gap threatening AI leadership?

The numbers are sobering. The United States now produces fewer than 820,000 STEM graduates annually, representing about 20% of all degrees awarded. China produces approximately 3.57 million STEM graduates each year, about 40% of its university degrees. At the doctoral level, the gap is sharper. In 2000, the United States awarded 17,830 STEM PhDs, compared with China’s 7,520. By 2022, China awarded more than 50,970 STEM doctorates, over 50% more than the 33,820 awarded in the United States.

This matters directly to AI leadership. Countries building the strongest STEM pipelines today are positioning themselves to define the architecture, governance and standards of AI systems tomorrow.

How can we solve the AI talent shortage and rebuild the IT profession?

More than a decade ago, I argued that IT must be treated as a profession, not merely a resource. Finance, medicine, law, engineering and accounting all have formal professional pathways, standards and institutional support. Information technology underpins nearly every critical function of modern society, yet still lacks equivalent professional frameworks.

The AI transition makes this more urgent. As AI absorbs routine execution, the humans left in the loop must be more capable, not fewer. Their role is shifting from implementation to governance, from configuration to architecture, from maintenance to judgment. That requires better preparation, stronger incentives and professional recognition.

The United States still leads in private AI investment, but it has not matched that commitment with investment in the human capital needed to sustain it. China has embedded AI degree programs across more than 500 universities and integrated corporations directly into research and workforce pipelines. India’s AI upskilling surge is driven heavily by corporate sponsorship, with employers treating workforce education as strategic investment. The European Union has committed significant public funding to AI talent development and cross-border STEM mobility.

The United States has examples worth scaling. North Carolina’s AI Academy at NC State, built with more than 100 corporate partners, combines university credentialing with applied workplace training. North Carolina A&T, the nation’s leading producer of Black engineers, is partnering with NVIDIA and the Office of Naval Research to expand AI and cybersecurity talent. Texas has committed heavily to doctoral research infrastructure through the Texas Institute for Electronics, linking universities, government and industry around semiconductor and defense technology priorities.

These models show what a national strategy should look like: public investment, corporate sponsorship, university research capacity and continuous pathways from undergraduate study through doctoral work. But they remain exceptions. Corporate PhD fellowships from leading technology companies are valuable, but they are filters, not pipelines.

The technology sector has long harvested talent from a pipeline it does not adequately fund, then wondered why the pipeline runs short. That model is no longer sustainable. Federal and state governments must create the policy environment, including tax incentives, credentialing reform, research funding and visa frameworks, that makes corporate STEM investment structurally attractive rather than reputationally optional.

The SaaSpocalypse will pass, as Y2K and the XPocalypse passed, because capable people will do the work. The headlines will move on. The underlying shortage will remain.

What I called for in 2014 still stands: STEM education, paired with business, information management and finance, must become a sustained national infrastructure. Not as a reaction to this disruption, but as preparation for the next one.

The hardest thing to manage is change. The next is learning from it.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

The first time I used Kubernetes in an enterprise setting, I understood the hype. It gives every team the same way to package, deploy and run their apps. No more custom scripts or unique deployment hacks, just one control plane to rule them all. And really, that’s why it’s so popular with big companies: Kubernetes is an open-source system for automating deployment, scaling and management of containerized applications. It says so right on the box, and that’s what people want. But here’s the truth: Kubernetes doesn’t erase operational headaches. It just moves them around.

When your Kubernetes install is small, it feels like rocket fuel for engineers. At enterprise scale, though, suddenly it’s about governance, not just engineering. The game is no longer “Can we get this container running?” It’s “How do hundreds of engineers roll out their stuff safely, consistently, securely and without breaking the bank or burning out the platform team?”

This is where the fun really starts.

YAML isn’t the enemy

Folks new to Kubernetes obsesses over manifests, Helm charts, namespaces, ingress rules, deployments, all that stuff. But they’re not the hardest part once you start scaling. The real beast is standardization.

Every big company I’ve seen ends up with teams going their own way. One group writes beautiful deployment templates. Someone else copies and pastes from a two-year-old manifest. Some folks set resource requirements properly. Others skip them entirely. One team sticks to a strong naming convention, and someone else throws together random namespaces and service accounts that make sense only to them. Individually, this more or less works. At scale, when the whole platform has to operate like one system, it’s a mess.

That’s why I’ll say it: you don’t just need a Kubernetes cluster. You need a paved road. This would involve ensuring that there are approved templates, good deployment patterns, observability, security controls as defaults, good issue escalation processes and accountability.

There is no need for developers to be Kubernetes experts just to release their services. The best enterprise Kubernetes setups work like real products. They let application teams self-serve but never let anyone veer off road without good reason.

RBAC: necessary, but never enough

Security is paramount. Kubernetes supports role-based access control (RBAC), so on paper you can control who does what. In practice, in a big company, RBAC gets confusing fast.

The issue isn’t that engineers ignore security. It’s that permissions grow over time. You need a quick fix during an incident, so you give a service account more access. Maybe a team needs cluster-wide rights for a migration. That “just for now” permission sticks around because no one cleans it up. Month by month, the gap widens between what a workload should do and what it’s actually allowed to do. The only thing that works long-term: treat RBAC as a living thing, not a one-time checklist. Review it. Test it. Stick to least privilege. Service accounts get only what they need. Cluster-admin rights? Rare. Expiring exceptions. Set permissions as code so changes aren’t invisible.

Same story with workload security. Kubernetes brings you Pod Security Standards. There is baseline, restricted and privileged profiles, so everyone speaks the same language. But simply setting a standard isn’t enough. We’d also need things like admission controls, image scanning, runtime monitoring and audit trails.

Honestly, the NSA/CISA Kubernetes Hardening Guidance is still gold. Scan containers and pods. Run workloads as locked down as possible. Use strong authentication. Separate networks. Set up solid logging. These ideas sound obvious until you see what happens when your organization scales without good ops.

Network policies: where “it should work” meets reality

Kubernetes networking can trip up even the best teams. Engineers often think different namespaces mean automatic isolation between apps. Not true.

Kubernetes network policies decide which pods can talk to which, but the policies only matter if your networking plugin actually enforces them. I’ve seen a lot of teams write network controls that look great in YAML but don’t work, because the underlying network just ignores them. Security validation beats documentation every time. If two namespaces shouldn’t talk, test it. If a workload only needs access to a specific backend, check it. If only specific ingress is allowed, make sure nothing else gets through.

At scale, your Kubernetes security has to prove itself. “We have a policy” means nothing unless the platform can show the policy actually works.

Resource management becomes all about money

One of the biggest challenge is resource allocation. Kubernetes lets you set CPU and memory limits, and sure, there are official docs. But getting these numbers right is tough.

Set them too low, and your workload might get throttled or evicted under load. Set them too high, and you’re paying for unused infrastructure. That barely registers on a small cluster, but when you’re running thousands of pods? That’s cloud bills gone wild.

This is where Kubernetes ops and FinOps meet. Platform teams have to know who’s burning through which resources, what’s over-provisioned or flying blind, and where the real money goes. ResourceQuota helps keep things in check, but quotas alone don’t hold people accountable.

The culture shift is moving from “the cluster has spare capacity” to “every service has an owner, a cost profile and a plan for staying lean.” Teams should understand their infrastructure bill. Platform teams need dashboards that point out waste. Engineering leaders need to care about efficiency, not just hear from finance when things go off the rails.

Autoscaling isn’t a magic trick

The Horizontal Pod Autoscaler is handy. It adjusts your workloads automatically to match demand. But don’t overestimate it. Most real-world services don’t scale simply by CPU or memory. Sometimes a service hits latency limits before CPU usage spikes. Workers chewing through queues? You care more about backlog size. Machine learning? Maybe it’s all about GPU use or loading time. Customer-facing apps? You want to be scaled up before traffic hits, not scramble after users start complaining.

So autoscaling isn’t just a box you check. It’s a feedback loop, and it only works if you use the right signals. Sometimes CPU is enough. Sometimes you need to scale on queue length, request rate, latency or something totally custom.

Then there’s node autoscaling to provision infrastructure in response to demand. On paper, it just works. In real life, it runs into startup delays, availability zones, quotas, cloud provider quirks and pod disruption budgets. Scale pods faster than nodes? Users still see delays.

Test autoscaling like you test your app. Load-test it, break it, see what happens after an incident. Otherwise, you’ll find the limits when it hurts most.

Observability doesn’t matter unless it answers questions

Kubernetes has mountains of data. Things like  logs, metrics, traces, events, audits, deployment history, container restarts, control plane noise, you name it. The real challenge isn’t collecting info, but actually it’s making sense of it. The CNCF and others have best practices for logging and telemetry, like centralizing logs and not leaking secrets. Those matter, but at the end of the day, engineers need answers, not just data. When something breaks, no one’s asking, “Is Kubernetes alive?” They want to know what changed. Did something roll out? Did a pod crash? Did autoscaling fire too late? Was a node unhealthy, a secret rotated, a network policy too tight, a downstream DB choking?

Observability should line up with real operational questions and not just ticking boxes for logs, or metrics. Dashboards need to match service ownership. Alerts need to mean something to end users. Telemetry should connect to deployments and incidents. Measure how quickly engineers spot the root cause, not just that you have the data somewhere.

CNCF talks about newer models of unified telemetry and proactive troubleshooting for a reason. All the dashboards in the world don’t help when your team has to play detective during an outage.

Upgrades: Don’t wing it

Kubernetes upgrades catch people out. The CNCF Maturity Model says: Kubernetes drops three big releases a year, so maintenance is part of life—not a once-in-a-blue-moon project.

Upgrading at enterprise scale can involve everything: workloads, admission controllers, CI/CD, service mesh, ingress, storage drivers, monitoring, security, custom controllers. Version skew policies keep you between the lines, but that’s just the beginning. The real question is: can you test your whole stack?

Good upgrade programs need a repeatable process, staging environments that actually look like production, and clear communication so teams know what to expect. The worst upgrade process is the one that relies on heroes to pull it off at the last second. A strong platform turns upgrades into routine.

Reliability: Kubernetes helps, but it doesn’t guarantee it

Yes, Kubernetes restarts crashed containers, reschedules pods and does rolling deployments. But it doesn’t make a bad app reliable.

A poorly coded app will fail on Kubernetes just like anywhere else. Bad readiness or liveness probes? Your app gets traffic too soon. No graceful shutdown? Requests drop during deploy. Forgot pod disruption budgets? The app goes down during node maintenance. A flaky dependency? It will cascade through your services even if all your pods look healthy.

The mature approach is setting service-level objectives and making reliability a product of both platform and engineering. Cluster health isn’t user experience. That green status page can hide a lot of pain.

The platform team is a product team

Here’s the biggest lesson I’ve picked up is that running Kubernetes at enterprise scale isn’t really about the tech. One cluster? Maybe one expert can handle that. But for a full enterprise platform, you need a product mindset. The platform team serves customers such as engineers, security, compliance, finance and business. Everyone wants something a bit different.

Developers want speed and reliability. Security wants oversight. Finance wants transparency. Compliance wants proof. Ops wants predictability. The business wants all of those.

The platform team has to pull those threads together with APIs, docs, dashboards, paved roads, support and feedback. That also means saying “no” to the unique snowflake patterns that create chaos later. Kubernetes is powerful. But it doesn’t replace organizational discipline. That’s still on the shoulders of engineering leaders. The real challenge at enterprise scale isn’t memorizing every API object. It’s building a system where any team can ship safely without needing to be Kubernetes experts themselves.

When you reach that point, Kubernetes stops being just a cluster. It becomes your platform.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

Danish multinational pharmaceutical Novo Nordisk is very interested in speeding up the time it takes to get drugs to market as patents expire. “If you have a blockbuster drug, a one-week delay can be $10 to $100 million,” says Stephanie Bova, the company’s digital transformation officer. “It’s massive money because you have less time on patent.”

Gen AI offered the possibility of dramatically speeding up multiple steps in the drug development process. And since Novo Nordisk was already carefully tracking how long its key processes took, it had an advantage that many companies didn’t. So it should’ve been relatively simple to sprinkle in some gen AI, see productivity improve, and watch the money roll in. But it wasn’t that easy. A drug development process has many parts, happening at different times in different departments.

“People are experts in their own domains but don’t necessarily know the next domain and how it all fits together,” Bova says. “The system is so big and complex that you’re not able to see all the performance at once.”

Process documentation might not match what people actually do in practice, and different people might do the same task in different ways. And some crucial tasks might be nearly invisible from the outside. The manufacturing team, for example, might sit in a completely different group and not be aware the drug is getting ready for FDA submission, and don’t have all their documents ready yet.

“So you’ve run very fast only to have to wait for them to catch up,” Bova adds.

This is just one of many challenges companies face when trying to measure the results of AI projects, and why surveys are so contradictory.

Looking at individual tasks, Novo Nordisk can show productivity improvements and clear positive benefits to its use of AI. But stepping back and looking at the company’s bottom line, the picture gets murkier. First, if critical steps are missed, then time to market won’t improve. It also takes years for a new drug to get to customers, so any positive bottom-line effects won’t be felt for a while. And that’s just the start of the ROI measurement problem.

Process measurement

To address its process blind spots, Novo Nordisk turned to the new generation of process mining: AI-powered real-time digital twins of operations.

“We partnered with process intelligence company Celonis to get a digital twin of our process data,” Bova says. “We were the first in the industry to apply it to the clinical setting.” The tool collects information from enterprise systems to track what employees actually do, rather than using surveys to collect information on what a fraction of employees remembered doing at some point.

The first project was a simple, seven-step process, and in creating a digital twin of it, Novo Nordisk discovered that, depending on who was doing it, it could be a five- or nine-step process. “If you get 10 different subject matter experts in a room, you get all kinds of interpretations, and you have drift over time,” she says.

The project exposed multiple flaws in existing processes. In some cases, employees needed to be retrained. In one, the user interface had to be updated. Once a process is standardized, though, there’s an opportunity to take the before picture, so there’s something to compare to afterward, to see if the AI augmentation or automation show any results.

Another thing they had to figure out ahead of time was decide what to do with any time savings that showed up.

“You don’t want to lay people off,” Bova says. “These are highly technical, hard-to-find talent. Maybe we want to think about redistributing teams a bit.”

Today, the company has several hundred AI agents in active deployment, tagged inside the digital twin infrastructure so they can be identified.

“If something screws up, we know exactly where to fix it,” she says, adding that the next phase is multi-agent orchestration. “Today, we have them connected, but we don’t have agents of agents.”

It’s too early to say if there’s ROI yet because, for drug development, the process takes years. “But by looking at the end-to-end process, my hope is we’ll find two years of cycle time to engineer out,” she says. “Two years quicker to market, compared to where we are now.”

Drugs that are already in the final phase of development won’t see as much acceleration, but those just starting out will benefit the most. The bottom line results, however, won’t show up for several years.

The pharmaceutical industry isn’t the only one where true value comes from optimizing multiple interconnected processes at once. According to PwC, tactical AI projects often don’t deliver measurable value, with tangible returns coming from enterprise-scale deployments consistent with business strategy.

In fact, many companies have seen neither increased revenue nor decreased costs from AI in the last 12 months despite nearly universal adoption of AI. Still, enterprise spending on AI is set to nearly double by the end of the year compared to last year, according to KPMG.

Productivity measurement

Most companies start on a smaller scale, rolling out AI chatbots to employees to help improve productivity. And the pace of adoption here has been staggeringly high, matched only by a lack of ability to measure the productivity gains that are supposed to be achieved.

Having a baseline is key, says Anand Rao, professor of AI at Carnegie Mellon University, but it’s difficult to measure in some cases, and all but impossible in others. Take for example insurance decisions where results can take years to show up. With life insurance, it could be decades, he says. And for some types of decisions, companies don’t have any measurements at all.

“There’s a social stigma to saying that I’m trying to look at your decision-making and how well you’re making the decisions,” he says. “As humans, we don’t like to be measured for our decisions.”

Then, when a decision turns out well in the end, people are happy to take credit. “If the decision goes badly, it’s something outside,” he says.

But even for specific tasks where measurement is possible, companies often don’t put in the work to make the measurements prior to rolling out AI tools. “We didn’t start with a baseline,” says Julie Averill, former EVP and global CIO of fashion retailer Lululemon. Averill is now CEO at Gold Thread, a digital transformation consultancy.

“We started with the assumption that AI was going to help people make better decisions,” she says. “And that sets you up to not being able to measure well.”

There are alternative metrics that a company can look at instead, she adds, like usage rates or user satisfaction. “This is happening, and it’s bringing benefits,” she says, “some of which you can see, and some you can’t. You have to trust the process. It’s just like the cloud. You know it’s the way of the future and you can see the benefits, but it’s hard to get there, and there’s a lot of change required. But the sooner you do that, the sooner you’re in the new way of operating and can really take advantage of it.”

There are other areas where hard metrics are more readily available, like customer service. “These are repeatable tasks, and it’s usually the first place companies automate with AI,” Averill says. “There are very tangible results you can measure, and you can have a very good baseline.”

Lululemon has also been using AI for years for better personalization and recommendations, and that’s also an area that can be quantified. And automation can reduce manual data entry, reducing error rates. AI can also be used to help with compliance monitoring, fraud detection, and predictive maintenance for equipment, which are all use cases that can be quantified.

But employee productivity in general? That’s a tough one to measure, and not just for Lululemon. One obvious way might be to look at layoffs in professions exposed to AI. After all, the headlines are everywhere. But in a report released in March, Anthropic found no signs of an increase in unemployment in highly exposed professions, those in which people are most likely to be laid off due to AI.

In early 2025, research firm METR attempted to quantify developer productivity by comparing how fast experienced developers were able to achieve tasks with AI and without. The result? Developers said they were expecting AI to speed them up by 24%, and estimated that AI had actually sped them up by 20%. But the data showed an altogether different story. Their use of AI actually slowed them down by 19%.

Of course, AI tools are getting better. METR attempted to do a follow-up study, again tracking tasks done with and without AI, but they couldn’t find enough developers willing to go back to the no-AI approach, even though the researchers were paying them to participate in the study.

There are anecdotal reports of companies where one engineer does the work of a hundred by using AI. Or that time the entire half-million-line Claude Code codebase was accidentally leaked and Korean developer Sigrid Jin created a clean-room rebuild in two hours, which he then pushed to GitHub, where it became the fastest project in history to hit 100,000 stars.

But as with anything else having to do with AI, the real picture is more complicated. With software development in particular, typing the code is actually just a fraction of what’s involved in developing software.

Research firm DX recently analyzed key engineering metrics from 400 companies, and in a recent report found that AI usage increased by 65% since November 2024, but AI-related productivity was just under 10%.

Hidden costs

Just as it’s difficult to measure the productivity benefits of AI, it can also be tricky to measure the costs. When a company first starts using AI, costs might be relatively simple to estimate. What’s the total monthly subscription charges for the AI chatbots that employees are using? What’s the cost of training or fine-tuning a custom model? But when you move on to more complex use cases, the calculations get more difficult, says Averill.

“Now there are all the systems around the AI,” she says. “Those are harder to measure, but the impact is bigger.”

For example, if AI is embedded into business processes using RAG, there’s the ongoing expense of the API calls, but also the changes that need to be made to other systems, she says. And it just keeps getting more complicated every day.

“We haven’t taken a very concerted effort to putting telemetry and instrumentation in place,” says Swaminathan Chandrasekaran, global head of AI and data labs at KPMG. He says that getting a comprehensive picture of the total costs of AI in an enterprise is like predicting the weather.

“The reason we have a pretty awesome weather prediction system in this country is because we have tens of thousands of weather stations that aggregate data,” he says. “Without that, we wouldn’t know the weather.”

Companies need to set up instrumentation to measure all the aspects of AI-related consumption, he says, starting with the number of tokens used, who’s using them, and how it correlates to work output.

“That measurement is fundamentally lacking,” he says.

At least when humans are using AI chatbots, there’s a limit to how many questions they’re physically able to ask, combined with predictable subscription costs. And when business processes are AI-enabled via RAG, the API calls to LLMs are being made by predictable, traditionally-scripted business systems.

But now, agentic AI is making everything worse because the agents can act unpredictably, and the number of API calls can quickly spiral out of control. In a report by the Boston Consulting Group, two-thirds of companies are reporting uncontrollable AI scaling expenses.

Another cost some companies might not anticipate well, or not track because it’s part of a different budget, is data-related cost. Whether preparing data for training or fine-tuning, using RAG embeddings, or setting up direct MCP access via agents, these costs can quickly add up when AI comes into the picture.

“Egress fees are one of the big ones,” says Tom Coughlin, IEEE fellow and president of consulting firm Coughlin Associates. “If you have to bring data out of the cloud, those egress fees could be considerable.”

Then there are all the human costs of deploying AI, he adds.

“There’ll be a lot of value that people get out of AI in the long run, but they need to know how to use it properly,” he says. “If they don’t have those skills, you’ll be at a disadvantage.”

Solutions and mixed messages

Then there’s fixing problems. A majority of companies have had at least one AI-related incident in the last 18 months, with most resulting in financial loss, some over $500,000. Then there’s the AI that’s being embedded in everything.

“We know our direct costs,” says Andrew Johnson, CIO at Brownstein Hyatt Farber Schreck, a leading national law firm. “But where it becomes more difficult to measure is with platforms we already have in place, and SaaS applications that didn’t have AI capabilities,” he says. “They’re asking for extraordinary increases and attribute them to new capabilities due to AI. How much should be ascribed to AI? That’s a little wishy-washy.”

Even when AI saves money, there are often extra costs associated with that. For example, the firm was spending about $70,000 a year on a contract management platform. Building their own version with AI took about $40,000 in labor costs and another $3,000 a year for hosting. Ongoing maintenance will be minor for that particular application, he adds, totaling another couple of thousand a year.

But there are also other indirect costs that come with running your own applications, including security audits, vulnerability assessments, penetration tests, and code review.

“The more complex and riskier the platform, the less appetite there is for trying to create an in-house solution,” he says.

Still, the software development team is now dramatically more productive as a result of AI, with four or five developers able to do the work of 20 or 30.

But the productivity improvements don’t translate to labor savings, since there’s plenty of new work for the developers to do. “We have an enormous backlog of opportunities to develop solutions,” he says.

The tendency of work to expand to fill the time available isn’t just true for software development, says Carnegie Mellon’s Rao.

Say for example, AI is expected to lead to a 20% improvement in productivity, he says. “There were a hundred people doing it, and now we only need 80.” But at the end of the year, headcount hasn’t changed. “The tasks they were doing, there’s improvement,” he adds “But humans will add tasks to supplement or complement that 20%. It’s not that they’re going home an hour early, but they’re finding other value-generating activities.”

In fact, in some cases, increased productivity at a company can actually hurt the bottom line. Lawyers, for example, bill by the hour.

“Efficiency runs counter to our traditional ways of making money,” says Brownstein’s Johnson. “We have to think past that. It’s not detrimental to our long-term interest, but it’s a challenge in the short term. If we don’t do this, though, it’s likely we won’t be competitive in the mid- to long-term.”

So if a new AI tool helps an attorney with due diligence, there’s no straight line between the investment in that tool and increased revenues.

“It’s a given that it’s directionally right,” Johnson says. “But we can’t say it’s going to lead to a particular return.”

AI agents, and the large language models (LLMs) that power them, have short memories. That’s by design. There is only so much conversation that can be encoded into tokens and accessed reliably by the LLM. Retrieval-augmented generation, or RAG, can be used to give agents and LLMs memories larger than their context windows. But how agents use RAG, or other mechanisms for retaining the details of a conversation, can make all the difference.

With the rise of AI agents, there has been a corresponding rise in complementary software tools that give both agents and LLMs expanded memory capabilities. Most of the time, this means giving an agent or model persistent memory across sessions, so that previous context can be restored automatically. But, again, how that’s done can vary tremendously with each tool.

Here are some of the major projects in the AI agent memory space, each with their own particular spins, strengths, and orientations.

Graphiti

Graphiti is billed as “the open-source temporal knowledge graph framework.” The project is available on GitHub, or as the underpinning of the Zep ageny memory service. “Temporal” means information stored in Graphiti is re-evaluated over time to keep its context properly framed, and “graph framework” means the data is stored as a set of graphs. The other solutions profiled here use graph storage as part of their approach, but Graphiti makes that a front-and-center part of its design.

Graphiti supports a range of common LLM providers out of the box: Anthropic, Azure OpenAI, Google Gemini, and Groq. Any Ollama and OpenAI-compatible APIs also work, so Graphiti can be used with locally hosted LLMs as well. Connectors for third-party storage services let you ingest data from places like GitHub, Gmail, and OneDrive, as well as from applications like Notion.

Using Graphiti locally requires you set up or connect to a graph database. Neo4j is the default and most broadly supported of the bunch, but Amazon Neptune, FalkorDB, and KuzuDB will also work. Postgres with pgvector is not listed as an option.

Hindsight

Hindsight, available as both a cloud service and a locally hostable project, stores details about agent sessions into four types of memory with four types of storage and retrieval strategies. All of these are handled through three programmatic interfaces: retain for storing content, either a single fact or a whole conversation; recall for retrieving content; and reflect for running an agentic loop over a query that uses previously stored data.

Hindsight comes with a broad range of first-party and third-party integrations with existing LLMs and agent toolkits. For instance, if you’re using the Continue extension with Visual Studio Code to talk to a locally hosted LLM, you can use Hindsight’s Continue integration to add long-term memory to your interactions. You can use the @hindsight keyword in your query to inject relevant memory into the agent’s context, or use auto-injection rules (which can be edited) to do most of that heavy lifting automatically.

Mem0

Mem0 is a little like Hindsight in that it has four basic kinds of memory, although they are labeled and organized differently. For instance, Mem0 has a separate type of memory called organizational memory that’s intended to store data to be shared between multiple agents or different teams, something that is not normally done by default. Each memory added is passed through a distillation process and stored in a different way (vector DB, graph DB, SQL DB) depending on how it will be used. Older data, instead of being overwritten, gets deprecated rather than deleted, as a strategy for preserving larger long-term context. (Hindsight does this as well.)

Mem0 supports a smaller range of LLMs than Hindsight, but all the major options are available: Anthropic, Google Gemini, OpenAI, and self-hosted options like LangChain, LiteLLM, LM Studio, and Ollama. If you intend to use Mem0 locally rather than as a service, you’ll need to provide a Python instance and your own vector database. For the latter, Postgres with the pgvector extension is a common and simple choice; it can even be installed inside a Python venv.

Supermemory

Supermemory ingests data from many common sources—supporting plaintext, structured data, common document file formats like PDF and Microsoft Office, video and audio, images—and uses them to build a context graph to inform agent conversations. Among its most promoted features is its content-extraction tools.

Supermemory is available as a cloud service or as open-source software you can run locally. The open-source edition lacks the scaling services and third-party service connectors (Gmail, Google Drive, Notion, etc.) provided with the enterprise edition, but it has one big advantage: it consists of a single, self-contained binary, so it can be deployed on one’s own hardware with very little effort. No external databases need to be provisioned for Supermemory, either, so it’s well-suited to quick experimentation.

Power consumption worldwide for data centers is projected to grow to 565 terawatt hours (TWh) in 2026, up 26% from 447 TWh in 2025, with AI-oriented data centers taking up an increasing amount of the pie.

Worldwide data center power demand is expected to rise 27% in 2026 and reach 133 gigawatts (GW), up from 105GW in 2025. It is projected to reach 291GW by 2030, which reflects the unprecedented scale and pace of GenAI boosting demand.

Those figures consider variables like parts and supply shortages, delayed or cancelled data center projects, and the impact of the conflict with Iran, said Linglan Wang, director analyst and lead economist at Gartner.

AI-optimized servers are a relatively new phenomenon but they have rapidly gained uh traditional data centers in terms of power use. Gartner estimates AI-optimized server adoption will account for 31% of data center power consumption in 2026, and that by 2027 their power consumption will surpass that of conventional servers.

“Surging demand for compute-intensive AI workloads is driving unprecedented data center power growth, while AI capacity is now constrained by power availability, making data center power security the new battle ground for scaling and protecting margins in the global AI race,” said Wang in a statement.

Wang said of the 565TWh consumed this year, the U.S. will account for about 204TWh, or 36% of the total amount consumed. And of the 204TWh consumed this year, dedicated AI data centers will consume 68TWh, or one-third of the total. So in just five years, AI data centers have gone from zero to of the total power consumption in the US.

Non-AI data center growth has been minimal by comparison.

The difference in growth of power consumption between conventional servers and AI-optimized servers is remarkable. Worldwide, conventional servers consumed 193 terawatt hours (TWh) of power in 2025 and are projected to rise 1.2% to 195 TWh in 2026 and another 2.4% in 2027 to 200 TWh This 3% basic growth will continue to 2030.

Now compare that to the AI-optimized servers. They consumed 95 TWh of power in 2025, rose 84.2% to 175 TWh in 2026 and another 47.8% to 258 TWh in 2027. By 2030, Wang estimates AI-optimized servers will account for near half of all power consumed by data centers worldwide.

With data center power electricity consumption estimated to reach over 1,200TWh by 2030, grid supply will be insufficient to meet the demands of future data center construction, affecting all data center users.

“Infrastructure and operations leaders must prioritize efficiency upgrades and secure grid access. They also need to invest in high-efficiency cooling systems and edge computing to mitigate power constraints and ensure sustainable, scalable growth,” Wang said.

The world is advancing toward a future in which over 10 billion humans coexist with trillions of autonomous agents in a superintelligent universe. However, the cloud-hosted systems that currently dominate AI’s operational models lack the architectural elasticity to support this growing demand for compute resources. Championed by managed GPU Clusters and centralized data centers, cloud AI relies on infrastructure that expands the operational scope of AI, requiring users to literally “rent” intelligence or the tools to develop it.

Tether argues that this system has a weak advantage, similar to scaling a database by simply buying a bigger server. AI scaling, in contrast, amplifies intelligence and availability. Cloud-hosted AI falters in both cases. Infinite scalability and universality in AI are therefore driven by the ability to deploy intelligent systems in any environment using readily available toolsets.

Tether’s AI research and development team believes that this “ability” is inherent in edge-optimized, local AI: self-hosted infrastructure for AI inference, training, and development on user-grade devices. Essentially, local AI converts intelligence into a portable capital asset readily available to the user, rather than a rented utility, as with cloud-hosted AI.

Operational constraints for AI developers and businesses.

Over 4,200 (43% of the world’s data centers) are located in the United States; eight times more than second-placed UK and third-placed Germany, which hosts more than twice as many data centers as all of Africa. This availability bias cuts across several other core infrastructure for AI development and routine use, impacting cost-effectiveness, performance, and data sovereignty.

Furthermore, data centers and other AI infrastructure, swamped with resource demands from unicorns and AI startups, continually adjust rental fees to offset operating costs and generate revenue. By extension, the high capital expenditure (CapEx) required for AI infrastructure is forcing companies to restructure their balance sheets. Major AI companies are expected to spend $500 billion on capital costs this year, a 30% increase from 2025 records. This is projected to reach $1.3 trillion by 2030, growing at 25% per annum.

Beyond availability and cost-efficacy, reliance on third-party infrastructure introduces additional operational factors and points of failure. Unplanned outages and abrupt changes in usage terms could significantly affect developers and end users.

In contrast, local AI operates autonomously, runs on infrastructure available to everyone, and works on any system. Plainly, they are agnostic, run on-premise, and eliminate barriers to availability.

Reputation capital of centralized AI

In an ideal scenario, anyone should be able to confidently use AI tools without worrying about what happens to their data post-execution. However, third-party access to user data opens channels for data mismanagement, this time, more advanced due to the quality of data unintentionally supplied by users during model training, fine-tuning, and inference.

34% of cybersecurity leaders identified “data leaks through generative AI” as their top concern for 2026, surpassing hacker capabilities for the first time. Elsewhere, the majority of the 670 data breach incidents reported in the first quarter of 2026 are either directly AI-driven or involve centralized data management infrastructure.

“Third-party” in this context includes AI companies and as-a-service infrastructure providers contracted to serve as a liaison between AI tools and users. Tens of the former are already headed to court in major class-action lawsuits over the handling of user data.

Local AI positions users as the only control point. User data is stored on-device and managed by software that has zero contact with external systems.

Tether AI’s research and development focuses on advancing machine intelligence as a readily available utility worldwide through technologies that let anyone build or use AI tools anywhere.

Universality for superintelligence and agnostic, on-premise AI.

Tether believes that efficient, self-hosted AI can transform machine intelligence into a new element of the periodic table that powers new possibilities in dynamic systems. This (self-hosted AI) will set in a new paradigm in which superintelligence is a foundational element owned by the user. However, effective agnostic, on-premise AI can only be achieved through creative engineering. This includes modifications from the model level to the complete architecture that accommodate design differences. Tether is leading innovations in pursuit of this. It is also contributing to open-source efforts to localize AI and abstract its complexities. This expands opportunities for even more advancements in local and edge-first AI.

The idea is to decouple AI from the current siloed, controlled, and fragile model. Tether is re-engineering Artificial Intelligence and modifying existing technologies to achieve infinite, scalable intelligence.

The first task here is to build a base infrastructure that operates as a self-governed unit. To this end, Tether developed the Pear runtime and co-founded Holepunch. Pear Runtime and Holepunch employ decentralized resource networks, databases, and communication protocols to achieve a serverless P2P backend for edge applications.

Next, Tether addresses the heavy computational overhead of AI models by developing resource-efficient models and infrastructure that run locally on user-grade devices and across heterogeneous environments. It launched QVAC (QuantumVerse Automatic Computer), an AI research team, and a development framework for local-first and edge-first AI research and development.

This unit has led the development of:

• A fine-tuning framework for Bitnet’s 13-billion-parameter LLM on regular devices, bypassing the GPU limitations of the ternary quantized model
• QVAC Fabric LLM: A high-throughput local-first AI framework that transforms regular devices into sovereign compute machines for AI development, model training, and inference.
• An Edge-first Parameter-efficient fine-tuning framework for training the QVAC Fabric LLM locally on everyday devices and heterogeneous GPUs

Building on the QVAC framework, Tether’s AI coverage has expanded to include tools for deploying intelligence across diverse systems, from personal computers to interfaces for controlling smart homes and appliances. This includes runtime environments, training data, fine-tuning frameworks, and edge-optimized AI applications.

Tether has built a suite of tools that put local AI into practice across every layer of the stack, including:

• QVAC Genesis I & II: Synthetic datasets for training AI models on STEM disciplines.
• WDK: AI-ready wallet development framework that enables autonomous agents to build local and edge-first cryptocurrency wallets.
• QVAC MedPsy: A range of (1.7B and 4B parameter) local-first medical AI models that run on heterogeneous everyday devices and produce more accurate and precise results than some larger medical AI models.
• QVAC Workbench: A unique general-purpose AI tool for researching, coding, and execution on edge devices.

Developers equipped with these can implement local AI integrations across diverse systems through a serverless backend, models that can run on resource-limited systems, and UI modules that simplify usage. This is further reinforced by the QVAC SDK, which consolidates all of Tether’s AI-related achievements to date. QVAC SDK is a toolkit of prebuilt modules for components of the QVAC AI infrastructures. It provides usage guides, integration contexts, and functional samples. This enables developers to build intelligent on-premises applications for any system without requiring permissions.

Committing to a human-centric future for AI

Artificial intelligence is arguably the most human-targeted internet-based technology in history. In an AI-dominated future, the current user base will be only a fraction of the demand scale. However, Institutional capital expenditure capacity isn’t unlimited, and the bloat in rental costs has no ceiling.

Tether’s local-first approach to AI acknowledges the relevance of machine intelligence to humans and its deep connection to everyday life. In response, it is dedicated to developing a universally accessible AI that is modular enough to be embedded in the fabric of any device, system, or environment. This ranges from industrial servers to the smallest chip in a light bulb.

In all of these cases, the ‘users’ own their AI, can build on their own terms, without permission or external constraints, choose their own biases, and control how their data is used. Practically, this is the only way to ensure that superintelligence is successfully delivered to the billions of humans it is meant for.

Subscribe to the QVAC newsletter to learn more about Tether’s breakthroughs in AI

Revised transaction structure enables immediate closing, accelerating the Company’s strategic pivot toward AI data centers, enterprise GPU compute, and digital power infrastructure.

Envirotech Vehicles, Inc. (NASDAQ: EVTV) (“EVTV” or the “Company”) today announced the successful completion of its merger with Azio AI Corporation (“Azio AI”) on July 2, 2026, paving the way for the Company to transform to an AI Datacenter Provider and meeting the growing market demand for artificial intelligence (“AI”) infrastructure, enterprise GPU compute, digital power solutions, data center development, and digital asset infrastructure; a market that the International Data Corporation (IDC) projects will reach $487 billion in global spending in 2026 and exceed $1 trillion by 2029.[1] The transaction marks a defining milestone in the Company’s strategic transformation and establishes the foundation for its next phase of commercial execution and long-term growth.

The parties amended the proposed transaction structure to expedite the closing timeline, allowing the combined company to begin operating as a fully integrated public company significantly sooner than originally anticipated. The accelerated closing enables management to immediately focus on commercialization across its expanding AI Datacenter strategy.

With the merger complete and the combined company operating as one organization, management is now fully focused on commercial execution, infrastructure deployment, strategic growth initiatives, and creating long-term shareholder value.

Over the past several months, the Company advanced development activities at its South Texas site and deployed six megawatts of off-grid power for its modular data centers. The Company further secured rights to a 548-acre site with the capacity to scale up to 500 MW, supporting the future development of AI hyperscale data centers.

Management believes these achievements demonstrate that the combined company is entering its next phase with meaningful operational momentum already in place rather than beginning from a standing start. Infrastructure deployment is underway, customer commitments have already been established, commercial execution is actively progressing, and the Company’s corporate structure is now aligned with an operating platform built to support long-term expansion.

The completion of the merger comes at a time when investment in AI infrastructure continues to accelerate globally as enterprises increasingly require access to high-performance computing resources, GPU infrastructure, and scalable digital power solutions. Management believes the combined company is well positioned to capitalize on these long-term industry trends through a diversified infrastructure strategy designed to monetize power assets across multiple complementary revenue streams, including AI data centers, enterprise compute infrastructure, power hosting, and digital asset mining operations.

Following the closing of the transaction, the Company intends to continue expanding its AI Infrastructure strategy through AI data center development, enterprise GPU compute solutions, power hosting services, digital asset mining operations, strategic infrastructure investments, and additional commercial partnerships designed to maximize utilization of its power resources while creating multiple long-term revenue opportunities.

In connection with the closing of the merger, Phillip Oldridge has stepped down as Chief Executive Officer. Jason Maddox vacates the President position and is now the Chief Financial Officer. The Company’s Board of Directors appointed Simon Yu as President and Chris Young as Chief Executive Officer, effective immediately.

Mr. Yu is a serial entrepreneur and public markets operator with almost a decade of experience taking companies public, executing capital raises, and scaling businesses. He has previously served in founder, C-suite, and board roles at three publicly traded companies, two of which reached market capitalizations in excess of $1 billion. Mr. Yu has led legal, accounting, and advisory teams through Regulation A+ Tier 2 offerings, PCAOB audits, and public company reporting, alongside leading M&A transactions. As an active early-stage venture investor, he has evaluated investment opportunities across artificial intelligence, SaaS, and B2B technology.

Mr. Young brings extensive experience in launching and leading public companies and investing in and advising emerging technology companies, with a particular focus on artificial intelligence, software innovation, and strategic growth initiatives. Prior to joining EVTV, he served as Chief Executive Officer of Clubhouse Media Group, a publicly traded social media company and an Entrepreneur in Residence at Amplify, where he worked alongside founders and venture-backed technology companies to accelerate commercialization and support the development of high-growth technology businesses.

“Today’s announcement represents far more than the completion of a merger—it marks the beginning of our next chapter,” said Chris Young, Chief Executive Officer of EVTV. “Over the past several months, our teams have been building the operational foundation of this business while simultaneously working toward completing this transaction. With the merger now finalized, we move forward as one company with one leadership team and one strategy, focused on executing against the opportunities in front of us. We believe demand for AI infrastructure, enterprise compute, and digital infrastructure will continue expanding for years to come. Our objective is to build a scalable platform capable of serving that demand while creating long-term value for our shareholders.”

Jason Maddox, Chief Financial Officer of EVTV, added, “Completing this transaction under the amended merger structure allows us to immediately focus on execution. We have already established meaningful operational momentum, and we believe operating as a unified public company enhances our ability to deploy infrastructure, serve customers, pursue strategic growth opportunities, and continue building long-term shareholder value.”

The transaction establishes a unified operating platform designed to support the Company’s long-term growth strategy through continued investment in AI infrastructure, enterprise computing, digital power assets, and digital infrastructure development. Management believes the completion of the merger provides the operational and organizational foundation necessary to pursue the next phase of commercialization while expanding its presence across some of the fastest-growing sectors of the global technology market.

Transaction and Operational Highlights

• Successfully completed the merger with Azio AI pursuant to an amended and restated merger agreement.
• Approximately six megawatts of off-grid digital infrastructure deployed at the Company’s South Texas development site.
• Development footprint exceeding 548 acres with the potential to support up to 500 MW of AI infrastructure capacity.
• Combined company positioned to accelerate commercialization across AI infrastructure, enterprise GPU compute, digital power solutions, and digital asset mining operations.
• Merger consideration consisted of 2,655,157 shares of common stock and 973,450 shares of non-voting convertible preferred stock in exchange for 100% of outstanding capital stock of Azio AI, of which 194,807 shares of common stock were reserved for convertible notes of Azio AI assumed by the Company upon closing.
• Each share of preferred stock convertible into 100 shares of Company common stock subject to stockholder approval.
• Chris Young appointed Chief Executive Officer and Chairman of the Board.
• Simon Yu appointed President.
• Jason Maddox appointed Chief Financial Officer.
• Phillip Oldridge stepped down as Chief Executive Officer.

About Envirotech Vehicles, Inc.

Envirotech Vehicles, Inc. (NASDAQ: EVTV) is a technology infrastructure company focused on developing, owning, and operating artificial intelligence data centers, enterprise GPU compute infrastructure, digital power solutions, and digital asset mining operations. Following its acquisition of Azio AI, the Company operates an integrated AI infrastructure business encompassing AI data center development, the sale and distribution of enterprise GPU systems and server infrastructure, high-performance computing solutions, power hosting, and strategic technology investments, serving enterprise and institutional customers across domestic and international markets. Through this diversified AI infrastructure strategy, the Company is positioned to capitalize on the rapidly expanding global demand for AI infrastructure, compute capacity, digital power, and next-generation AI technologies.

For more information please visit: www.azioai.ai and for potential partnerships contact: AI@PhoenixMGMTconsulting.com

Forward-Looking Statements

This press release contains forward-looking statements within the meaning of the Private Securities Litigation Reform Act of 1995. In some cases, you can identify forward-looking statements by words such as “may,” “will,” “could,” “expect,” “anticipate,” “believe,” “estimate,” “project,” “intend,” “continue,” “potential,” “ongoing,” or the negative of these terms or other comparable terminology, although not all forward-looking statements contain these words. Forward-looking statements include statements regarding the Company’s ability to capitalize on accelerating demand for AI infrastructure, enterprise GPU compute, digital power solutions, data center development, and digital asset infrastructure; the Company’s plans to continue expanding its digital infrastructure platform through AI data center development, enterprise GPU compute solutions, power hosting services, digital asset mining operations, strategic infrastructure investments, and additional commercial partnerships; the Company’s ability to maximize utilization of its power resources while creating multiple long-term revenue opportunities; the ability to continue deploying modular digital infrastructure at the Company’s South Texas site; the anticipated deployment and scaling of NVIDIA B200 and B300 GPU systems; the ability to advance and execute against the Company’s commercial infrastructure pipeline; the anticipated development of the Company’s footprint; the ability to monetize power assets across multiple complementary revenue streams, including AI data centers, enterprise compute infrastructure, power hosting, and digital asset mining operations; customer demand for AI infrastructure, enterprise compute, and digital infrastructure; the Company’s ability to build a scalable platform designed to serve that demand and create long-term shareholder value; and the Company’s broader business strategy and long-term growth objectives.

These statements are based on current expectations and assumptions that involve risks and uncertainties that could cause actual results to differ materially. Most of these factors are outside the Company’s control and are difficult to predict. Factors that may affect actual results include, but are not limited to, the Company’s limited operating history within AI infrastructure and compute operations, project scope, engineering challenges, supply chain constraints, installation timelines, energy availability, finalization of site usage rights, regulatory considerations, equipment performance, ability to raise capital required for expansion activities, changes in digital asset markets, evolving compute demand, market conditions, the Company’s ability to successfully integrate the combined business following the completion of the merger, the risk that the anticipated benefits and synergies of the merger are not realized, the risk of unexpected costs, charges, or expenses resulting from or relating to the merger, potential adverse reactions or changes to business relationships resulting from the completion of the merger, risks related to the diversion of management’s attention from ongoing business operations during the post-closing integration period, the risk that required stockholder approval for the conversion of preferred stock issued in the merger as required by rules of The Nasdaq Stock Market LLC (the “Conversion Proposal”) is not obtained, and additional risks and uncertainties described in the Company’s most recent Annual Report on Form 10-K and subsequent Quarterly Reports on Form 10-Q filed with the SEC, which are available at www.sec.gov. The Company undertakes no obligation to update forward-looking statements except as required by law.

Important Information About the Merger and Where to Find it

The Company expects to file a proxy statement with the SEC relating to the Conversion Proposal. The definitive proxy statement will be sent to all Company stockholders. Before making any voting decision, investors and security-holders of the Company are urged to read the proxy statement and all other relevant documents filed or that will be filed with the SEC in connection with the Conversion Proposal as they become available because they will contain important information about the amended and restated merger agreement between the parties and the related transactions and the Conversion Proposal to be voted upon by the Company’s stockholders. Investors and security-holders will be able to obtain free copies of the proxy statement and all other relevant documents filed or that will be filed with the SEC by the Company through the website maintained by the SEC at www.sec.gov.

Participants in the Solicitation

The Company and its directors and executive officers may be considered participants in the solicitation of proxies from EVTV’s stockholders with respect to the Conversion Proposal under the rules of the SEC. Information about the directors and executive officers of EVTV is set forth in its Annual Report on Form 10-K for the year ended December 31, 2025, which was filed with the SEC on April 13, 2026, and in subsequent Quarterly Reports on Form 10-Q and other documents filed by the Company from time to time with the SEC. Additional information regarding the persons who may be deemed participants in the proxy solicitation and a description of their direct and indirect interests, by security holdings or otherwise, will also be included in the proxy statement, and other relevant materials to be filed with the SEC when they become available. You may obtain free copies of these documents as described above.

¹ Source: International Data Corporation (IDC), “AI Infrastructure Spending Caps Historic Year at ~$90 Billion in Q4 2025; 2029 Spending to Eclipse $1 Trillion,” April 16, 2026. The Company has not independently verified the data or projections contained in this report, and there can be no assurance that the projections will be realized.

Contact

Phoenix MGMT & Consulting

Press@PhoenixMGMTConsulting.com

Revised transaction structure enables immediate closing, accelerating the Company’s strategic pivot toward AI data centers, enterprise GPU compute, and digital power infrastructure.

Envirotech Vehicles, Inc. (NASDAQ: EVTV) (“EVTV” or the “Company”) today announced the successful completion of its merger with Azio AI Corporation (“Azio AI”) on July 2, 2026, paving the way for the Company to transform to an AI Datacenter Provider and meeting the growing market demand for artificial intelligence (“AI”) infrastructure, enterprise GPU compute, digital power solutions, data center development, and digital asset infrastructure; a market that the International Data Corporation (IDC) projects will reach $487 billion in global spending in 2026 and exceed $1 trillion by 2029.[1] The transaction marks a defining milestone in the Company’s strategic transformation and establishes the foundation for its next phase of commercial execution and long-term growth.

The parties amended the proposed transaction structure to expedite the closing timeline, allowing the combined company to begin operating as a fully integrated public company significantly sooner than originally anticipated. The accelerated closing enables management to immediately focus on commercialization across its expanding AI Datacenter strategy.

With the merger complete and the combined company operating as one organization, management is now fully focused on commercial execution, infrastructure deployment, strategic growth initiatives, and creating long-term shareholder value.

Over the past several months, the Company advanced development activities at its South Texas site and deployed six megawatts of off-grid power for its modular data centers. The Company further secured rights to a 548-acre site with the capacity to scale up to 500 MW, supporting the future development of AI hyperscale data centers.

Management believes these achievements demonstrate that the combined company is entering its next phase with meaningful operational momentum already in place rather than beginning from a standing start. Infrastructure deployment is underway, customer commitments have already been established, commercial execution is actively progressing, and the Company’s corporate structure is now aligned with an operating platform built to support long-term expansion.

The completion of the merger comes at a time when investment in AI infrastructure continues to accelerate globally as enterprises increasingly require access to high-performance computing resources, GPU infrastructure, and scalable digital power solutions. Management believes the combined company is well positioned to capitalize on these long-term industry trends through a diversified infrastructure strategy designed to monetize power assets across multiple complementary revenue streams, including AI data centers, enterprise compute infrastructure, power hosting, and digital asset mining operations.

Following the closing of the transaction, the Company intends to continue expanding its AI Infrastructure strategy through AI data center development, enterprise GPU compute solutions, power hosting services, digital asset mining operations, strategic infrastructure investments, and additional commercial partnerships designed to maximize utilization of its power resources while creating multiple long-term revenue opportunities.

In connection with the closing of the merger, Phillip Oldridge has stepped down as Chief Executive Officer. Jason Maddox vacates the President position and is now the Chief Financial Officer. The Company’s Board of Directors appointed Simon Yu as President and Chris Young as Chief Executive Officer, effective immediately.

Mr. Yu is a serial entrepreneur and public markets operator with almost a decade of experience taking companies public, executing capital raises, and scaling businesses. He has previously served in founder, C-suite, and board roles at three publicly traded companies, two of which reached market capitalizations in excess of $1 billion. Mr. Yu has led legal, accounting, and advisory teams through Regulation A+ Tier 2 offerings, PCAOB audits, and public company reporting, alongside leading M&A transactions. As an active early-stage venture investor, he has evaluated investment opportunities across artificial intelligence, SaaS, and B2B technology.

Mr. Young brings extensive experience in launching and leading public companies and investing in and advising emerging technology companies, with a particular focus on artificial intelligence, software innovation, and strategic growth initiatives. Prior to joining EVTV, he served as Chief Executive Officer of Clubhouse Media Group, a publicly traded social media company and an Entrepreneur in Residence at Amplify, where he worked alongside founders and venture-backed technology companies to accelerate commercialization and support the development of high-growth technology businesses.

“Today’s announcement represents far more than the completion of a merger—it marks the beginning of our next chapter,” said Chris Young, Chief Executive Officer of EVTV. “Over the past several months, our teams have been building the operational foundation of this business while simultaneously working toward completing this transaction. With the merger now finalized, we move forward as one company with one leadership team and one strategy, focused on executing against the opportunities in front of us. We believe demand for AI infrastructure, enterprise compute, and digital infrastructure will continue expanding for years to come. Our objective is to build a scalable platform capable of serving that demand while creating long-term value for our shareholders.”

Jason Maddox, Chief Financial Officer of EVTV, added, “Completing this transaction under the amended merger structure allows us to immediately focus on execution. We have already established meaningful operational momentum, and we believe operating as a unified public company enhances our ability to deploy infrastructure, serve customers, pursue strategic growth opportunities, and continue building long-term shareholder value.”

The transaction establishes a unified operating platform designed to support the Company’s long-term growth strategy through continued investment in AI infrastructure, enterprise computing, digital power assets, and digital infrastructure development. Management believes the completion of the merger provides the operational and organizational foundation necessary to pursue the next phase of commercialization while expanding its presence across some of the fastest-growing sectors of the global technology market.

Transaction and Operational Highlights

• Successfully completed the merger with Azio AI pursuant to an amended and restated merger agreement.
• Approximately six megawatts of off-grid digital infrastructure deployed at the Company’s South Texas development site.
• Development footprint exceeding 548 acres with the potential to support up to 500 MW of AI infrastructure capacity.
• Combined company positioned to accelerate commercialization across AI infrastructure, enterprise GPU compute, digital power solutions, and digital asset mining operations.
• Merger consideration consisted of 2,655,157 shares of common stock and 973,450 shares of non-voting convertible preferred stock in exchange for 100% of outstanding capital stock of Azio AI, of which 194,807 shares of common stock were reserved for convertible notes of Azio AI assumed by the Company upon closing.
• Each share of preferred stock convertible into 100 shares of Company common stock subject to stockholder approval.
• Chris Young appointed Chief Executive Officer and Chairman of the Board.
• Simon Yu appointed President.
• Jason Maddox appointed Chief Financial Officer.
• Phillip Oldridge stepped down as Chief Executive Officer.

About Envirotech Vehicles, Inc.

Envirotech Vehicles, Inc. (NASDAQ: EVTV) is a technology infrastructure company focused on developing, owning, and operating artificial intelligence data centers, enterprise GPU compute infrastructure, digital power solutions, and digital asset mining operations. Following its acquisition of Azio AI, the Company operates an integrated AI infrastructure business encompassing AI data center development, the sale and distribution of enterprise GPU systems and server infrastructure, high-performance computing solutions, power hosting, and strategic technology investments, serving enterprise and institutional customers across domestic and international markets. Through this diversified AI infrastructure strategy, the Company is positioned to capitalize on the rapidly expanding global demand for AI infrastructure, compute capacity, digital power, and next-generation AI technologies.

For more information please visit: www.azioai.ai and for potential partnerships contact: AI@PhoenixMGMTconsulting.com

Forward-Looking Statements

This press release contains forward-looking statements within the meaning of the Private Securities Litigation Reform Act of 1995. In some cases, you can identify forward-looking statements by words such as “may,” “will,” “could,” “expect,” “anticipate,” “believe,” “estimate,” “project,” “intend,” “continue,” “potential,” “ongoing,” or the negative of these terms or other comparable terminology, although not all forward-looking statements contain these words. Forward-looking statements include statements regarding the Company’s ability to capitalize on accelerating demand for AI infrastructure, enterprise GPU compute, digital power solutions, data center development, and digital asset infrastructure; the Company’s plans to continue expanding its digital infrastructure platform through AI data center development, enterprise GPU compute solutions, power hosting services, digital asset mining operations, strategic infrastructure investments, and additional commercial partnerships; the Company’s ability to maximize utilization of its power resources while creating multiple long-term revenue opportunities; the ability to continue deploying modular digital infrastructure at the Company’s South Texas site; the anticipated deployment and scaling of NVIDIA B200 and B300 GPU systems; the ability to advance and execute against the Company’s commercial infrastructure pipeline; the anticipated development of the Company’s footprint; the ability to monetize power assets across multiple complementary revenue streams, including AI data centers, enterprise compute infrastructure, power hosting, and digital asset mining operations; customer demand for AI infrastructure, enterprise compute, and digital infrastructure; the Company’s ability to build a scalable platform designed to serve that demand and create long-term shareholder value; and the Company’s broader business strategy and long-term growth objectives.

These statements are based on current expectations and assumptions that involve risks and uncertainties that could cause actual results to differ materially. Most of these factors are outside the Company’s control and are difficult to predict. Factors that may affect actual results include, but are not limited to, the Company’s limited operating history within AI infrastructure and compute operations, project scope, engineering challenges, supply chain constraints, installation timelines, energy availability, finalization of site usage rights, regulatory considerations, equipment performance, ability to raise capital required for expansion activities, changes in digital asset markets, evolving compute demand, market conditions, the Company’s ability to successfully integrate the combined business following the completion of the merger, the risk that the anticipated benefits and synergies of the merger are not realized, the risk of unexpected costs, charges, or expenses resulting from or relating to the merger, potential adverse reactions or changes to business relationships resulting from the completion of the merger, risks related to the diversion of management’s attention from ongoing business operations during the post-closing integration period, the risk that required stockholder approval for the conversion of preferred stock issued in the merger as required by rules of The Nasdaq Stock Market LLC (the “Conversion Proposal”) is not obtained, and additional risks and uncertainties described in the Company’s most recent Annual Report on Form 10-K and subsequent Quarterly Reports on Form 10-Q filed with the SEC, which are available at www.sec.gov. The Company undertakes no obligation to update forward-looking statements except as required by law.

Important Information About the Merger and Where to Find it

The Company expects to file a proxy statement with the SEC relating to the Conversion Proposal. The definitive proxy statement will be sent to all Company stockholders. Before making any voting decision, investors and security-holders of the Company are urged to read the proxy statement and all other relevant documents filed or that will be filed with the SEC in connection with the Conversion Proposal as they become available because they will contain important information about the amended and restated merger agreement between the parties and the related transactions and the Conversion Proposal to be voted upon by the Company’s stockholders. Investors and security-holders will be able to obtain free copies of the proxy statement and all other relevant documents filed or that will be filed with the SEC by the Company through the website maintained by the SEC at www.sec.gov.

Participants in the Solicitation

The Company and its directors and executive officers may be considered participants in the solicitation of proxies from EVTV’s stockholders with respect to the Conversion Proposal under the rules of the SEC. Information about the directors and executive officers of EVTV is set forth in its Annual Report on Form 10-K for the year ended December 31, 2025, which was filed with the SEC on April 13, 2026, and in subsequent Quarterly Reports on Form 10-Q and other documents filed by the Company from time to time with the SEC. Additional information regarding the persons who may be deemed participants in the proxy solicitation and a description of their direct and indirect interests, by security holdings or otherwise, will also be included in the proxy statement, and other relevant materials to be filed with the SEC when they become available. You may obtain free copies of these documents as described above.

¹ Source: International Data Corporation (IDC), “AI Infrastructure Spending Caps Historic Year at ~$90 Billion in Q4 2025; 2029 Spending to Eclipse $1 Trillion,” April 16, 2026. The Company has not independently verified the data or projections contained in this report, and there can be no assurance that the projections will be realized.

Contact

Phoenix MGMT & Consulting

Press@PhoenixMGMTConsulting.com

Revised transaction structure enables immediate closing, accelerating the Company’s strategic pivot toward AI data centers, enterprise GPU compute, and digital power infrastructure.

Envirotech Vehicles, Inc. (NASDAQ: EVTV) (“EVTV” or the “Company”) today announced the successful completion of its merger with Azio AI Corporation (“Azio AI”) on July 2, 2026, paving the way for the Company to transform to an AI Datacenter Provider and meeting the growing market demand for artificial intelligence (“AI”) infrastructure, enterprise GPU compute, digital power solutions, data center development, and digital asset infrastructure; a market that the International Data Corporation (IDC) projects will reach $487 billion in global spending in 2026 and exceed $1 trillion by 2029.[1] The transaction marks a defining milestone in the Company’s strategic transformation and establishes the foundation for its next phase of commercial execution and long-term growth.

The parties amended the proposed transaction structure to expedite the closing timeline, allowing the combined company to begin operating as a fully integrated public company significantly sooner than originally anticipated. The accelerated closing enables management to immediately focus on commercialization across its expanding AI Datacenter strategy.

With the merger complete and the combined company operating as one organization, management is now fully focused on commercial execution, infrastructure deployment, strategic growth initiatives, and creating long-term shareholder value.

Over the past several months, the Company advanced development activities at its South Texas site and deployed six megawatts of off-grid power for its modular data centers. The Company further secured rights to a 548-acre site with the capacity to scale up to 500 MW, supporting the future development of AI hyperscale data centers.

Management believes these achievements demonstrate that the combined company is entering its next phase with meaningful operational momentum already in place rather than beginning from a standing start. Infrastructure deployment is underway, customer commitments have already been established, commercial execution is actively progressing, and the Company’s corporate structure is now aligned with an operating platform built to support long-term expansion.

The completion of the merger comes at a time when investment in AI infrastructure continues to accelerate globally as enterprises increasingly require access to high-performance computing resources, GPU infrastructure, and scalable digital power solutions. Management believes the combined company is well positioned to capitalize on these long-term industry trends through a diversified infrastructure strategy designed to monetize power assets across multiple complementary revenue streams, including AI data centers, enterprise compute infrastructure, power hosting, and digital asset mining operations.

Following the closing of the transaction, the Company intends to continue expanding its AI Infrastructure strategy through AI data center development, enterprise GPU compute solutions, power hosting services, digital asset mining operations, strategic infrastructure investments, and additional commercial partnerships designed to maximize utilization of its power resources while creating multiple long-term revenue opportunities.

In connection with the closing of the merger, Phillip Oldridge has stepped down as Chief Executive Officer. Jason Maddox vacates the President position and is now the Chief Financial Officer. The Company’s Board of Directors appointed Simon Yu as President and Chris Young as Chief Executive Officer, effective immediately.

Mr. Yu is a serial entrepreneur and public markets operator with almost a decade of experience taking companies public, executing capital raises, and scaling businesses. He has previously served in founder, C-suite, and board roles at three publicly traded companies, two of which reached market capitalizations in excess of $1 billion. Mr. Yu has led legal, accounting, and advisory teams through Regulation A+ Tier 2 offerings, PCAOB audits, and public company reporting, alongside leading M&A transactions. As an active early-stage venture investor, he has evaluated investment opportunities across artificial intelligence, SaaS, and B2B technology.

Mr. Young brings extensive experience in launching and leading public companies and investing in and advising emerging technology companies, with a particular focus on artificial intelligence, software innovation, and strategic growth initiatives. Prior to joining EVTV, he served as Chief Executive Officer of Clubhouse Media Group, a publicly traded social media company and an Entrepreneur in Residence at Amplify, where he worked alongside founders and venture-backed technology companies to accelerate commercialization and support the development of high-growth technology businesses.

“Today’s announcement represents far more than the completion of a merger—it marks the beginning of our next chapter,” said Chris Young, Chief Executive Officer of EVTV. “Over the past several months, our teams have been building the operational foundation of this business while simultaneously working toward completing this transaction. With the merger now finalized, we move forward as one company with one leadership team and one strategy, focused on executing against the opportunities in front of us. We believe demand for AI infrastructure, enterprise compute, and digital infrastructure will continue expanding for years to come. Our objective is to build a scalable platform capable of serving that demand while creating long-term value for our shareholders.”

Jason Maddox, Chief Financial Officer of EVTV, added, “Completing this transaction under the amended merger structure allows us to immediately focus on execution. We have already established meaningful operational momentum, and we believe operating as a unified public company enhances our ability to deploy infrastructure, serve customers, pursue strategic growth opportunities, and continue building long-term shareholder value.”

The transaction establishes a unified operating platform designed to support the Company’s long-term growth strategy through continued investment in AI infrastructure, enterprise computing, digital power assets, and digital infrastructure development. Management believes the completion of the merger provides the operational and organizational foundation necessary to pursue the next phase of commercialization while expanding its presence across some of the fastest-growing sectors of the global technology market.

Transaction and Operational Highlights

• Successfully completed the merger with Azio AI pursuant to an amended and restated merger agreement.
• Approximately six megawatts of off-grid digital infrastructure deployed at the Company’s South Texas development site.
• Development footprint exceeding 548 acres with the potential to support up to 500 MW of AI infrastructure capacity.
• Combined company positioned to accelerate commercialization across AI infrastructure, enterprise GPU compute, digital power solutions, and digital asset mining operations.
• Merger consideration consisted of 2,655,157 shares of common stock and 973,450 shares of non-voting convertible preferred stock in exchange for 100% of outstanding capital stock of Azio AI, of which 194,807 shares of common stock were reserved for convertible notes of Azio AI assumed by the Company upon closing.
• Each share of preferred stock convertible into 100 shares of Company common stock subject to stockholder approval.
• Chris Young appointed Chief Executive Officer and Chairman of the Board.
• Simon Yu appointed President.
• Jason Maddox appointed Chief Financial Officer.
• Phillip Oldridge stepped down as Chief Executive Officer.

About Envirotech Vehicles, Inc.

Envirotech Vehicles, Inc. (NASDAQ: EVTV) is a technology infrastructure company focused on developing, owning, and operating artificial intelligence data centers, enterprise GPU compute infrastructure, digital power solutions, and digital asset mining operations. Following its acquisition of Azio AI, the Company operates an integrated AI infrastructure business encompassing AI data center development, the sale and distribution of enterprise GPU systems and server infrastructure, high-performance computing solutions, power hosting, and strategic technology investments, serving enterprise and institutional customers across domestic and international markets. Through this diversified AI infrastructure strategy, the Company is positioned to capitalize on the rapidly expanding global demand for AI infrastructure, compute capacity, digital power, and next-generation AI technologies.

For more information please visit: www.azioai.ai and for potential partnerships contact: AI@PhoenixMGMTconsulting.com

Forward-Looking Statements

This press release contains forward-looking statements within the meaning of the Private Securities Litigation Reform Act of 1995. In some cases, you can identify forward-looking statements by words such as “may,” “will,” “could,” “expect,” “anticipate,” “believe,” “estimate,” “project,” “intend,” “continue,” “potential,” “ongoing,” or the negative of these terms or other comparable terminology, although not all forward-looking statements contain these words. Forward-looking statements include statements regarding the Company’s ability to capitalize on accelerating demand for AI infrastructure, enterprise GPU compute, digital power solutions, data center development, and digital asset infrastructure; the Company’s plans to continue expanding its digital infrastructure platform through AI data center development, enterprise GPU compute solutions, power hosting services, digital asset mining operations, strategic infrastructure investments, and additional commercial partnerships; the Company’s ability to maximize utilization of its power resources while creating multiple long-term revenue opportunities; the ability to continue deploying modular digital infrastructure at the Company’s South Texas site; the anticipated deployment and scaling of NVIDIA B200 and B300 GPU systems; the ability to advance and execute against the Company’s commercial infrastructure pipeline; the anticipated development of the Company’s footprint; the ability to monetize power assets across multiple complementary revenue streams, including AI data centers, enterprise compute infrastructure, power hosting, and digital asset mining operations; customer demand for AI infrastructure, enterprise compute, and digital infrastructure; the Company’s ability to build a scalable platform designed to serve that demand and create long-term shareholder value; and the Company’s broader business strategy and long-term growth objectives.

These statements are based on current expectations and assumptions that involve risks and uncertainties that could cause actual results to differ materially. Most of these factors are outside the Company’s control and are difficult to predict. Factors that may affect actual results include, but are not limited to, the Company’s limited operating history within AI infrastructure and compute operations, project scope, engineering challenges, supply chain constraints, installation timelines, energy availability, finalization of site usage rights, regulatory considerations, equipment performance, ability to raise capital required for expansion activities, changes in digital asset markets, evolving compute demand, market conditions, the Company’s ability to successfully integrate the combined business following the completion of the merger, the risk that the anticipated benefits and synergies of the merger are not realized, the risk of unexpected costs, charges, or expenses resulting from or relating to the merger, potential adverse reactions or changes to business relationships resulting from the completion of the merger, risks related to the diversion of management’s attention from ongoing business operations during the post-closing integration period, the risk that required stockholder approval for the conversion of preferred stock issued in the merger as required by rules of The Nasdaq Stock Market LLC (the “Conversion Proposal”) is not obtained, and additional risks and uncertainties described in the Company’s most recent Annual Report on Form 10-K and subsequent Quarterly Reports on Form 10-Q filed with the SEC, which are available at www.sec.gov. The Company undertakes no obligation to update forward-looking statements except as required by law.

Important Information About the Merger and Where to Find it

The Company expects to file a proxy statement with the SEC relating to the Conversion Proposal. The definitive proxy statement will be sent to all Company stockholders. Before making any voting decision, investors and security-holders of the Company are urged to read the proxy statement and all other relevant documents filed or that will be filed with the SEC in connection with the Conversion Proposal as they become available because they will contain important information about the amended and restated merger agreement between the parties and the related transactions and the Conversion Proposal to be voted upon by the Company’s stockholders. Investors and security-holders will be able to obtain free copies of the proxy statement and all other relevant documents filed or that will be filed with the SEC by the Company through the website maintained by the SEC at www.sec.gov.

Participants in the Solicitation

The Company and its directors and executive officers may be considered participants in the solicitation of proxies from EVTV’s stockholders with respect to the Conversion Proposal under the rules of the SEC. Information about the directors and executive officers of EVTV is set forth in its Annual Report on Form 10-K for the year ended December 31, 2025, which was filed with the SEC on April 13, 2026, and in subsequent Quarterly Reports on Form 10-Q and other documents filed by the Company from time to time with the SEC. Additional information regarding the persons who may be deemed participants in the proxy solicitation and a description of their direct and indirect interests, by security holdings or otherwise, will also be included in the proxy statement, and other relevant materials to be filed with the SEC when they become available. You may obtain free copies of these documents as described above.

¹ Source: International Data Corporation (IDC), “AI Infrastructure Spending Caps Historic Year at ~$90 Billion in Q4 2025; 2029 Spending to Eclipse $1 Trillion,” April 16, 2026. The Company has not independently verified the data or projections contained in this report, and there can be no assurance that the projections will be realized.

Contact

Phoenix MGMT & Consulting

Press@PhoenixMGMTConsulting.com

Revised transaction structure enables immediate closing, accelerating the Company’s strategic pivot toward AI data centers, enterprise GPU compute, and digital power infrastructure.

Envirotech Vehicles, Inc. (NASDAQ: EVTV) (“EVTV” or the “Company”) today announced the successful completion of its merger with Azio AI Corporation (“Azio AI”) on July 2, 2026, paving the way for the Company to transform to an AI Datacenter Provider and meeting the growing market demand for artificial intelligence (“AI”) infrastructure, enterprise GPU compute, digital power solutions, data center development, and digital asset infrastructure; a market that the International Data Corporation (IDC) projects will reach $487 billion in global spending in 2026 and exceed $1 trillion by 2029.[1] The transaction marks a defining milestone in the Company’s strategic transformation and establishes the foundation for its next phase of commercial execution and long-term growth.

The parties amended the proposed transaction structure to expedite the closing timeline, allowing the combined company to begin operating as a fully integrated public company significantly sooner than originally anticipated. The accelerated closing enables management to immediately focus on commercialization across its expanding AI Datacenter strategy.

With the merger complete and the combined company operating as one organization, management is now fully focused on commercial execution, infrastructure deployment, strategic growth initiatives, and creating long-term shareholder value.

Over the past several months, the Company advanced development activities at its South Texas site and deployed six megawatts of off-grid power for its modular data centers. The Company further secured rights to a 548-acre site with the capacity to scale up to 500 MW, supporting the future development of AI hyperscale data centers.

Management believes these achievements demonstrate that the combined company is entering its next phase with meaningful operational momentum already in place rather than beginning from a standing start. Infrastructure deployment is underway, customer commitments have already been established, commercial execution is actively progressing, and the Company’s corporate structure is now aligned with an operating platform built to support long-term expansion.

The completion of the merger comes at a time when investment in AI infrastructure continues to accelerate globally as enterprises increasingly require access to high-performance computing resources, GPU infrastructure, and scalable digital power solutions. Management believes the combined company is well positioned to capitalize on these long-term industry trends through a diversified infrastructure strategy designed to monetize power assets across multiple complementary revenue streams, including AI data centers, enterprise compute infrastructure, power hosting, and digital asset mining operations.

Following the closing of the transaction, the Company intends to continue expanding its AI Infrastructure strategy through AI data center development, enterprise GPU compute solutions, power hosting services, digital asset mining operations, strategic infrastructure investments, and additional commercial partnerships designed to maximize utilization of its power resources while creating multiple long-term revenue opportunities.

In connection with the closing of the merger, Phillip Oldridge has stepped down as Chief Executive Officer. Jason Maddox vacates the President position and is now the Chief Financial Officer. The Company’s Board of Directors appointed Simon Yu as President and Chris Young as Chief Executive Officer, effective immediately.

Mr. Yu is a serial entrepreneur and public markets operator with almost a decade of experience taking companies public, executing capital raises, and scaling businesses. He has previously served in founder, C-suite, and board roles at three publicly traded companies, two of which reached market capitalizations in excess of $1 billion. Mr. Yu has led legal, accounting, and advisory teams through Regulation A+ Tier 2 offerings, PCAOB audits, and public company reporting, alongside leading M&A transactions. As an active early-stage venture investor, he has evaluated investment opportunities across artificial intelligence, SaaS, and B2B technology.

Mr. Young brings extensive experience in launching and leading public companies and investing in and advising emerging technology companies, with a particular focus on artificial intelligence, software innovation, and strategic growth initiatives. Prior to joining EVTV, he served as Chief Executive Officer of Clubhouse Media Group, a publicly traded social media company and an Entrepreneur in Residence at Amplify, where he worked alongside founders and venture-backed technology companies to accelerate commercialization and support the development of high-growth technology businesses.

“Today’s announcement represents far more than the completion of a merger—it marks the beginning of our next chapter,” said Chris Young, Chief Executive Officer of EVTV. “Over the past several months, our teams have been building the operational foundation of this business while simultaneously working toward completing this transaction. With the merger now finalized, we move forward as one company with one leadership team and one strategy, focused on executing against the opportunities in front of us. We believe demand for AI infrastructure, enterprise compute, and digital infrastructure will continue expanding for years to come. Our objective is to build a scalable platform capable of serving that demand while creating long-term value for our shareholders.”

Jason Maddox, Chief Financial Officer of EVTV, added, “Completing this transaction under the amended merger structure allows us to immediately focus on execution. We have already established meaningful operational momentum, and we believe operating as a unified public company enhances our ability to deploy infrastructure, serve customers, pursue strategic growth opportunities, and continue building long-term shareholder value.”

The transaction establishes a unified operating platform designed to support the Company’s long-term growth strategy through continued investment in AI infrastructure, enterprise computing, digital power assets, and digital infrastructure development. Management believes the completion of the merger provides the operational and organizational foundation necessary to pursue the next phase of commercialization while expanding its presence across some of the fastest-growing sectors of the global technology market.

Transaction and Operational Highlights

• Successfully completed the merger with Azio AI pursuant to an amended and restated merger agreement.
• Approximately six megawatts of off-grid digital infrastructure deployed at the Company’s South Texas development site.
• Development footprint exceeding 548 acres with the potential to support up to 500 MW of AI infrastructure capacity.
• Combined company positioned to accelerate commercialization across AI infrastructure, enterprise GPU compute, digital power solutions, and digital asset mining operations.
• Merger consideration consisted of 2,655,157 shares of common stock and 973,450 shares of non-voting convertible preferred stock in exchange for 100% of outstanding capital stock of Azio AI, of which 194,807 shares of common stock were reserved for convertible notes of Azio AI assumed by the Company upon closing.
• Each share of preferred stock convertible into 100 shares of Company common stock subject to stockholder approval.
• Chris Young appointed Chief Executive Officer and Chairman of the Board.
• Simon Yu appointed President.
• Jason Maddox appointed Chief Financial Officer.
• Phillip Oldridge stepped down as Chief Executive Officer.

About Envirotech Vehicles, Inc.

Envirotech Vehicles, Inc. (NASDAQ: EVTV) is a technology infrastructure company focused on developing, owning, and operating artificial intelligence data centers, enterprise GPU compute infrastructure, digital power solutions, and digital asset mining operations. Following its acquisition of Azio AI, the Company operates an integrated AI infrastructure business encompassing AI data center development, the sale and distribution of enterprise GPU systems and server infrastructure, high-performance computing solutions, power hosting, and strategic technology investments, serving enterprise and institutional customers across domestic and international markets. Through this diversified AI infrastructure strategy, the Company is positioned to capitalize on the rapidly expanding global demand for AI infrastructure, compute capacity, digital power, and next-generation AI technologies.

For more information please visit: www.azioai.ai and for potential partnerships contact: AI@PhoenixMGMTconsulting.com

Forward-Looking Statements

This press release contains forward-looking statements within the meaning of the Private Securities Litigation Reform Act of 1995. In some cases, you can identify forward-looking statements by words such as “may,” “will,” “could,” “expect,” “anticipate,” “believe,” “estimate,” “project,” “intend,” “continue,” “potential,” “ongoing,” or the negative of these terms or other comparable terminology, although not all forward-looking statements contain these words. Forward-looking statements include statements regarding the Company’s ability to capitalize on accelerating demand for AI infrastructure, enterprise GPU compute, digital power solutions, data center development, and digital asset infrastructure; the Company’s plans to continue expanding its digital infrastructure platform through AI data center development, enterprise GPU compute solutions, power hosting services, digital asset mining operations, strategic infrastructure investments, and additional commercial partnerships; the Company’s ability to maximize utilization of its power resources while creating multiple long-term revenue opportunities; the ability to continue deploying modular digital infrastructure at the Company’s South Texas site; the anticipated deployment and scaling of NVIDIA B200 and B300 GPU systems; the ability to advance and execute against the Company’s commercial infrastructure pipeline; the anticipated development of the Company’s footprint; the ability to monetize power assets across multiple complementary revenue streams, including AI data centers, enterprise compute infrastructure, power hosting, and digital asset mining operations; customer demand for AI infrastructure, enterprise compute, and digital infrastructure; the Company’s ability to build a scalable platform designed to serve that demand and create long-term shareholder value; and the Company’s broader business strategy and long-term growth objectives.

These statements are based on current expectations and assumptions that involve risks and uncertainties that could cause actual results to differ materially. Most of these factors are outside the Company’s control and are difficult to predict. Factors that may affect actual results include, but are not limited to, the Company’s limited operating history within AI infrastructure and compute operations, project scope, engineering challenges, supply chain constraints, installation timelines, energy availability, finalization of site usage rights, regulatory considerations, equipment performance, ability to raise capital required for expansion activities, changes in digital asset markets, evolving compute demand, market conditions, the Company’s ability to successfully integrate the combined business following the completion of the merger, the risk that the anticipated benefits and synergies of the merger are not realized, the risk of unexpected costs, charges, or expenses resulting from or relating to the merger, potential adverse reactions or changes to business relationships resulting from the completion of the merger, risks related to the diversion of management’s attention from ongoing business operations during the post-closing integration period, the risk that required stockholder approval for the conversion of preferred stock issued in the merger as required by rules of The Nasdaq Stock Market LLC (the “Conversion Proposal”) is not obtained, and additional risks and uncertainties described in the Company’s most recent Annual Report on Form 10-K and subsequent Quarterly Reports on Form 10-Q filed with the SEC, which are available at www.sec.gov. The Company undertakes no obligation to update forward-looking statements except as required by law.

Important Information About the Merger and Where to Find it

The Company expects to file a proxy statement with the SEC relating to the Conversion Proposal. The definitive proxy statement will be sent to all Company stockholders. Before making any voting decision, investors and security-holders of the Company are urged to read the proxy statement and all other relevant documents filed or that will be filed with the SEC in connection with the Conversion Proposal as they become available because they will contain important information about the amended and restated merger agreement between the parties and the related transactions and the Conversion Proposal to be voted upon by the Company’s stockholders. Investors and security-holders will be able to obtain free copies of the proxy statement and all other relevant documents filed or that will be filed with the SEC by the Company through the website maintained by the SEC at www.sec.gov.

Participants in the Solicitation

The Company and its directors and executive officers may be considered participants in the solicitation of proxies from EVTV’s stockholders with respect to the Conversion Proposal under the rules of the SEC. Information about the directors and executive officers of EVTV is set forth in its Annual Report on Form 10-K for the year ended December 31, 2025, which was filed with the SEC on April 13, 2026, and in subsequent Quarterly Reports on Form 10-Q and other documents filed by the Company from time to time with the SEC. Additional information regarding the persons who may be deemed participants in the proxy solicitation and a description of their direct and indirect interests, by security holdings or otherwise, will also be included in the proxy statement, and other relevant materials to be filed with the SEC when they become available. You may obtain free copies of these documents as described above.

¹ Source: International Data Corporation (IDC), “AI Infrastructure Spending Caps Historic Year at ~$90 Billion in Q4 2025; 2029 Spending to Eclipse $1 Trillion,” April 16, 2026. The Company has not independently verified the data or projections contained in this report, and there can be no assurance that the projections will be realized.

Contact

Phoenix MGMT & Consulting

Press@PhoenixMGMTConsulting.com

As intelligent systems move into production environments and begin taking actions, organizations quickly discover that accountability becomes much harder. Unlike traditional enterprise software, these tools can produce unpredictable outcomes as they interact dynamically with data, APIs, and business workflows.

“When something goes wrong with AI, it is generally assigned to whoever was closest to the pain point,” says David DuChene, manager of data and AI pre-sales at SHI International, which works with enterprises on AI deployments and governance.

As these systems shift from advisor to actor within workflows, accountability becomes harder to enforce through policies alone. IT leaders must build it directly into the fabric of their operations through clear ownership, continuous observability, defined escalation paths, and infrastructure designed to make responsibility visible when things go wrong.

Here are six ways to make AI accountability enforceable in production.

1. Assign direct ownership from the beginning

Many enterprises still view AI accountability as a shared responsibility, but some experts argue that this is the first assumption to fail when systems enter production.

“Shared accountability is not accountability,” says Joe Wilson, SVP and CIO of CSG, a customer experience, billing, and payments software provider. “You need a direct owner.”

He says that at CSG, AI initiatives go through governance reviews involving executive leadership, and direct ownership is assigned at the start of projects. Wilson, who oversees the AI governance and deployment strategy for CSG, says the company also created “CIO reps” embedded inside business units and product groups to ensure accountability spans the entire lifecycle of AI initiatives.

According to SHI’s DuChene, many enterprises still lack formalized accountability structures for those environments. “They may have responsible parties on paper, but once a system actually breaks down, everything gets relitigated,” he says. “It goes back to who’s closest to the pain point.”

One diagnostic question, he argues, reveals whether organizations are truly prepared: “If your AI deployment generates a wrong answer and costs the business money tomorrow, who’s going to write the postmortem?”

If leaders cannot answer that question quickly, accountability structures likely don’t yet exist in practice.

2. Build governance before scaling deployments

In the past few years, many enterprises deployed AI systems before establishing the governance and operational foundations necessary to support them safely. “The biggest gap we see is a sequencing problem,” says DuChene. “We’ve gone around and built a bunch of houses where we’re standing up the walls before we’re pouring the foundations.”

That sequencing problem creates expensive retrofitting efforts later. DuChene says teams frequently discover they lack data classification systems, AI-aware identity and access controls, lineage and provenance tracking, audit capabilities, and escalation channels for failures.

According to Seth Dobrin, CEO of deterministic AI model maker Arya Labs and former global AI leader at IBM, governance often fails because organizations treat it as a policy layer rather than something embedded directly into operational workflows. “How do you integrate it into the workflow?” he asks. “If you don’t get that right, it’s going to fall apart.”

Dobrin recalls working with an insurance company that spent 18 months building an intelligent system before legal teams blocked deployment entirely. The problem was not the technology itself, but the absence of governance early in the process. “They had to throw it away,” Dobrin says. “Had they started earlier, they would have steered it to a place where they could have gotten to yes.”

Dobrin says governance should not slow projects down. Instead it should be integrated deeply enough into workflows that teams can move quickly without downstream compliance or operational failures. “The objective should never be to say no,” he says. “It should always be to figure out how to say yes.”

Wilson at CSG makes a similar point, arguing that governance should help teams absorb complexity rather than simply restrict what they can do. He compares it to a vehicle suspension system rather than a braking mechanism. “Our intention is not to slow things down,” he says. “Our intention is to speed stuff up, but also when you get into rough terrain, to be able to navigate that terrain.”

3. Treat data governance as the foundation of accountability

According to Wilson, CSG focused on governing its data before scaling AI initiatives across the business. Those efforts started with data synchronization and privacy impact assessments.

“The foundation is data,” Wilson says. “If we don’t have clean, synchronized, and governed data across the board, we’re not going to win this battle.”

Many organizations underestimate how difficult it becomes to maintain accountability once AI systems begin interacting with fragmented enterprise data environments, says Quais Taraki, CTO of EnterpriseDB, a company that works with enterprises on data infrastructure and governance.

An AI assistant summarizing customer interactions, for example, may pull regulated or confidential data from systems that were never intended to feed generative AI tools.

Strong data governance practices — including lineage, provenance tracking, classification systems, and access controls — not only help head off such problems but also create the foundation for accountability when something does go wrong. Otherwise, teams struggle to determine what data an AI system accessed, how outputs were generated, and whether sensitive information influenced a decision.

“Without lineage and provenance, you can’t do root-cause analysis,” Taraki says. “You won’t know what to change, or how things mutated in ways you didn’t expect.”

Taraki argues that accountability should follow governed data products rather than organizational silos. When ownership is split across infrastructure teams, data scientists, and application developers, responsibility can become difficult to establish after failures occur. Assigning clear ownership to the data products that feed AI systems helps create accountability throughout the AI lifecycle.

4. Build observability into (and beyond) AI systems

Traditional enterprise monitoring systems were designed primarily to track uptime, infrastructure health, and application performance. AI introduces a different challenge: tracing reasoning paths, decision chains, and behavioral drift.

Nik Kale, a member of the Coalition for Secure AI (CoSAI) and participant in AI security and agent identity standards efforts, describes this through what he calls an “Investigation Graph.” This is a reasoning trail showing what an AI system observed, what tools it accessed, what conclusions it reached, and what actions it ultimately took.

“When something breaks, the first instinct is always to ask, ‘Why did the AI make that decision?’” Kale says. “Honestly, I think that’s the wrong question. The right question is, ‘What did the system actually do?’”

That distinction is increasingly important because AI failures rarely originate from a model alone. Instead, they emerge from interactions between models, credentials, APIs, workflows, policies, and downstream systems.

“The model didn’t act,” Kale says. “The system around the model acted.”

That broader view of accountability is also changing how IT leaders think about observability. Rather than monitoring AI models in isolation, enterprises increasingly need visibility across the systems those models interact with, including data sources, APIs, applications, security controls, and downstream workflows.

In practice, that starts with comprehensive logging of prompts, model outputs, tool calls, data access events, and agent actions. Combined with traditional application and infrastructure telemetry, those logs create an auditable record of how AI systems behaved and why decisions were made.

That visibility becomes especially important when IT leaders try to identify unauthorized AI usage. While governance policies define which tools employees should use, observability helps reveal which tools they are actually using. Unusual data access patterns, unexpected API calls, traffic to external AI services, and unexplained movement of sensitive data can all be indicators of shadow AI.

Even well-governed organizations can struggle when employees adopt unauthorized AI tools outside approved workflows. “If it’s shadow IT, we don’t even know it exists,” says DuChene. “We don’t know what data of ours is going into it, how it’s being used, or how it’s being distributed.”

By extending observability beyond AI models to the broader enterprise environment, IT can detect those activities earlier, investigate them more quickly, and reduce the accountability gaps that shadow AI creates.

5. Create ‘escalate’ and ‘stop’ mechanisms

The most important accountability question may not be what an AI system can see or do, but when it should stop and ask for help.

According to Kale, that’s often the most underdeveloped part of enterprise AI deployments. “Most enterprises have figured out how to monitor their AI systems,” he says. “But nobody has really built the third piece, which is, when does the system actually stop and ask for help?”

Kale argues that enterprises need explicit escalation paths, human decision points, and clearly defined stop mechanisms for systems operating in production.

“You don’t want a rubber stamp — you want a human in the loop,” he says, adding that the human should be named and have the authority to say no.

According to Wilson, incident response processes also need to evolve, because AI failures behave differently from traditional IT outages. “A traditional IT incident typically looks like it’s an up or down scenario,” he says. “AI failures are a little more subtle than that.”

Models may drift gradually, outputs may degrade over time, or workflows may begin producing unexpected results without systems technically failing. The result, says Wilson, is a growing need for multidisciplinary response processes involving legal, communications, security, audit, business teams, and IT operations simultaneously.

6. Treat AI systems more like workers than software

Some enterprises still govern AI like traditional applications. But according to Kale, AI systems behave more like workers and less like deterministic software.

“You cannot just deploy once and be done,” he says. “Like workers, they need ongoing oversight.”

That ongoing oversight is becoming a core accountability function. Employees are not hired, trained, and then left unsupervised indefinitely. Managers monitor performance, provide feedback, evaluate changing responsibilities, and intervene when behavior drifts from expectations. Kale argues that AI systems increasingly require similar treatment.

Traditional software can often be reviewed and approved at release time because its behavior remains relatively stable between versions. AI systems are different. Models evolve, prompts change, retrieval systems are updated, and the information available to agents changes continuously.

That challenge extends beyond internally developed systems. Enterprises must also monitor the third-party AI services they rely on. Not only do vendor models evolve on their own, but vendors also update software and capabilities behind the scenes.

“The vendor we approved last quarter is functionally a different vendor this quarter,” Kale says.

As a result, accountability cannot end when a system is deployed. Someone must remain responsible for monitoring performance, reviewing changes, assessing risk, and determining whether systems continue to operate within acceptable boundaries. Kale points to CoSAI’s AI Shared Responsibility Framework as one emerging effort to clarify those responsibilities across enterprises, software vendors, model providers, and infrastructure operators.

The organizations making the most progress are discovering that accountability cannot be assigned on paper and forgotten. As AI systems become more autonomous, accountability is becoming an operational capability built into data governance, observability, escalation processes, and ongoing oversight. For IT leaders, the challenge is no longer defining responsibility. It is making responsibility enforceable.

Related reading:

• CIOs plagued by growing AI accountability gap
• AI is spreading decision-making, but not accountability
• Who authorized the AI agent? Breaking the blame loop in agentic AI
• Why AI adoption keeps outrunning governance — and what to do about it
• 5 ways to curb AI sprawl without stifling innovation

Over the past two years, I have spent a significant amount of time discussing artificial intelligence with technology leaders, business executives and teams across my own organization. Most conversations begin with questions about the use cases, tools, governance and return on investment. Leaders want to know which technologies are creating the most value, where to invest next and how quickly they should scale adoption.

Those are important questions, but I have noticed another pattern emerging as organizations move beyond experimentation and begin embedding AI into everyday work. In many cases, the technology itself is not the primary obstacle to success. Instead, AI is exposing organizational challenges that have existed for years. Processes that were already inefficient become more visible. Ambiguous decision-making structures become harder to ignore. Accountability gaps that once slowed projects quietly now become more apparent as work accelerates.

This has led me to a simple conclusion: AI does not eliminate inefficiency. It amplifies it.

That observation should not be interpreted as a criticism of AI. In fact, it highlights just how powerful the technology can be. AI accelerates workflows, shortens analysis cycles, improves access to information and increases employee productivity. However, because it accelerates the way work gets done, it also magnifies the strengths and weaknesses of the operating environment in which it is deployed. Organizations with strong processes and clear accountability often realize value quickly. Organizations with operational complexity frequently discover that technology alone cannot overcome management challenges.

AI accelerates existing operating models

Many organizations approach AI as a technology initiative. They evaluate platforms, launch pilots and identify tasks that can be automated. While those activities are important, they can also create a false impression that AI itself is the primary driver of transformation.

In my experience, the greatest value comes not from the technology alone but from the willingness to rethink how work gets done. AI can automate tasks, but it cannot redesign a broken workflow. If a process contains unnecessary approvals, duplicate activities, conflicting priorities or poorly defined handoffs, those issues remain regardless of how sophisticated the technology becomes.

This idea is consistent with a broader lesson I explore in my latest book, Digital Inside Out: digital transformation succeeds when organizations focus first on how work gets done, how decisions are made and how accountability is established. Technology can accelerate performance, but it rarely compensates for weaknesses in the underlying operating model. In many cases, new technologies simply make those weaknesses more visible.

Researchers at the MIT Sloan School of Management have reached a similar conclusion. Their work suggests that organizations generate the greatest value from AI when they redesign workflows rather than simply automate individual tasks. In other words, the most significant gains come from rethinking how work flows through the organization rather than accelerating isolated activities.

I have seen this pattern repeatedly throughout my career. Enterprise systems did not fix poor business processes. Collaboration platforms did not automatically improve communication. Analytics tools did not create accountability. Each technology delivered substantial benefits, but only when accompanied by process redesign, governance improvements and leadership commitment. AI follows the same pattern.

Organizations that simply layer AI on top of existing complexity often find themselves completing inefficient work faster. Employees may generate reports in minutes instead of hours, produce presentations more quickly and analyze larger volumes of information. Yet the underlying process may still contain the same bottlenecks that limited performance before AI was introduced. The technology increases speed, but it does not automatically improve effectiveness.

Why decision-making becomes the new bottleneck

One of the most interesting effects of AI is how it changes the nature of organizational constraints. Historically, many companies struggled because information was difficult to access. Data was fragmented across systems, reporting cycles were slow and analysis required significant manual effort. Leaders frequently spent considerable time gathering information before they could make decisions.

AI is rapidly reducing those barriers. Teams can now summarize large volumes of information, identify patterns, generate recommendations and produce insights in a fraction of the time previously required. Access to information is becoming less of a competitive differentiator because the effort required to generate it continues to decline.

As this happens, another challenge becomes more visible. Many organizations discover that their greatest constraint is no longer information. It is decision-making.

When ownership is unclear, faster insights do not necessarily produce faster outcomes. Teams may have access to excellent recommendations yet still struggle to determine who is responsible for acting on them. Multiple stakeholders may believe they have authority over a decision. Escalations become more common. Consensus-driven cultures can become overwhelmed by the volume of information being generated.

Some of the most difficult conversations I have encountered in AI initiatives have had little to do with models, prompts or technical architecture. Instead, they involve governance, ownership, accountability and decision rights. These challenges existed before AI, but the technology makes them more visible because it removes many of the delays previously associated with gathering and analyzing information.

This trend is likely to become even more pronounced as organizations adopt AI agents capable of executing tasks and workflows. While technology can automate actions, accountability remains a leadership responsibility. Leaders must still determine who owns outcomes, who approves actions and who is responsible when decisions create unintended consequences.

What leaders should fix before scaling AI

Deloitte’s annual State of AI in the Enterprise research highlights the challenges organizations face when attempting to scale AI beyond pilots and isolated use cases. This finding reinforces a lesson many leaders are learning firsthand: realizing value from AI requires organizational change, process redesign and strong leadership, not just new technology

For CIOs and business leaders, one of the most important priorities should be simplifying processes before automating them. AI can reduce manual effort, but it rarely eliminates complexity that has been embedded into a process over many years. Organizations often achieve greater value by removing unnecessary steps before introducing automation.  As Jon McNeill writes in his book, The Algorithm, “No need to waste time speeding up the old process. Instead, design, simplify, optimize and begin to work your new process. Then speed it up.”

Leaders should also establish clear decision rights before scaling AI-enabled workflows. As information becomes easier to generate, organizations need clarity regarding who is accountable for making decisions and driving action. Without that clarity, AI can create more recommendations than the organization is capable of acting upon.

Another important consideration is measurement. Many organizations continue to evaluate AI success through adoption rates, license utilization or employee engagement metrics. While these measures provide useful signals, they do not necessarily reflect business value. Leaders should focus on outcomes such as productivity improvements, revenue growth, cost reduction, customer experience enhancements and risk mitigation.

Most importantly, leaders should recognize that AI adoption is fundamentally a leadership challenge. Technology can accelerate work, but leaders determine how work is organized, governed, measured and improved. Organizations that treat AI solely as a technology initiative often struggle to move beyond experimentation. Organizations that use AI as an opportunity to improve processes, clarify accountability and modernize operating models are more likely to achieve sustainable results.

As AI adoption continues to accelerate, I believe the organizations that realize the greatest value will not necessarily be those with the largest investments or the most advanced models. They will be the organizations willing to address the management and operational issues that AI brings into focus. In many cases, AI is not creating new problems. It is revealing existing ones with greater speed and clarity.

That may be one of the most valuable contributions AI can make. By exposing inefficiencies that organizations have learned to tolerate, it creates an opportunity for leaders to address them directly. The companies that seize that opportunity will be better positioned not only to benefit from AI, but also to improve the way their organizations operate long after the current wave of innovation has passed.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

Most executives approach AI cautiously, like people trying to stretch one bankroll across an entire night on the casino floor. They spread their chips, hedge every move, celebrate the occasional small win, and tell themselves they played wisely because they didn’t lose much. It feels disciplined and responsible. But in a market shifting this quickly, it can become managed irrelevance.

The real question is how to win so decisively that the house starts treating you differently, says Nimesh Mehta. As EVP and chief information and strategy officer at National Life Group, one of the nation’s largest life insurers, Mehta sees AI less as a controlled technology program and more as a sequence of bets that reveal how leadership thinks about risk, conviction, and competitive advantage. In his view, the organizations that pull ahead are the ones willing to place smarter, more consequential bets that reshape how the business operates, competes, and grows.

Stop insuring every move

Mehta’s framing exposes a trap many leadership teams still don’t recognize. A surprising number of organizations believe they’re being strategic with AI when they’re actually over-insuring every decision. They hedge every initiative, over-govern every experiment, over-analyze every downside, and under-commit to anything that might actually matter.

As a result, they reduce the upside to the point of insignificance. Mehta argues that many companies insure the bet so thoroughly that even when they win, the upside is negligible and moves are designed to eliminate discomfort, not win.

That’s what makes the casino analogy useful. In a casino, sitting on your chips can feel safe. In business, that same instinct creates drift. Markets move, competitors learn, and capabilities compound whether you’re ready or not. “Sometimes not betting can, in itself, become a losing strategy,” says Mehta, which strikes the heart of the moment facing CIOs. Waiting may feel like discipline in the short term, but over time it becomes a tax on relevance. The organizations creating separation are those that understand uncertainty, contain it, and move anyway.

Trade certainty for probability

The deeper leadership shift Mehta is calling for is about changing the mental model from deterministic thinking to probabilistic thinking. Most enterprises still want AI to behave like a traditional technology investment. If we spend X, we should get Y. If the model isn’t fully accurate, it’s not ready, and if meaningful risk remains, deployment should wait. That logic made sense in a world built on structured systems and predictable workflows. But it becomes far less useful in a world where advantage comes from learning faster than rivals and improving in motion.

Most organizations still treat AI decisions like fixed equations rather than probabilistic plays, says Mehta. That distinction matters because it changes the questions leaders ask. A deterministic mindset looks at a customer service use case and asks whether the model is accurate enough to be trusted in every case. A probabilistic mindset asks whether the model can handle enough interactions well enough to free human judgment for the moments that matter most. A deterministic leader wants guaranteed ROI before scaling copilots. A probabilistic leader sees that modest improvements, repeated across marketing, operations, distribution, and service, can produce a compounding advantage long before any single use case looks perfect on paper. In that sense, imperfection may be leverage.

Nobody goes to a casino expecting certainty. The energy comes from reading the table, understanding the odds, and knowing that context changes the right move. AI operates in much the same way. “Leaders don’t need to become reckless gamblers,” says Mehta, “They need to become more fluent in uncertainty, more comfortable making directional decisions, and more disciplined about learning from each hand they play.”

When you’re holding 17

Mehta’s blackjack metaphor captures the exact moment where many enterprises stall. With a 17, the dealer will ask if you want to hit or stand. It’s paralyzing, but it’s the position many CIOs are in with AI today. The use case works as it produces value, but it isn’t perfect. The organization can see the upside, but it can still see the gaps, too. So many leaders choose to stand. They wait for better accuracy, cleaner governance, stronger confidence, or a more complete business case. They tell themselves that holding is the responsible move.

“The real risk, however, isn’t the hit but standing still while the table evolves around you,” says Mehta. That line reframes what prudence means in an AI environment. Hitting means understanding the odds well enough to act, not being careless. It means asking what the downside of moving forward actually is, what guardrails are needed, and what the cost of waiting might be if others are learning faster.

The strongest leaders understand that a good but not perfect hand can still be the right time to lean in. They know that learning in production, within bounds, often reveals more than another quarter spent polishing the slide deck.

Bet where the upside compounds

How should CIOs decide where to place bigger bets? Mehta’s answer is to look for asymmetry, where the upside is meaningfully larger than the downside, where learning compounds even if the first outcome is imperfect, and where speed creates an advantage competitors can’t easily copy. Those are better to address than asking which use cases feel safest. Mehta also emphasizes proximity to the business, arguing that the closer an AI use case sits to revenue, customer experience, or core operations, the more valuable the learning becomes. That’s why some of the most important bets may initially feel uncomfortable. But they matter because they produce insight that isolated pilots never can.

This isn’t a call for indiscriminate betting, though. Discipline still matters, and not every initiative deserves to scale, and not every model belongs in production. Good leaders know when to leave the table, reallocate chips, and avoid the sunk-cost logic that keeps weaker organizations trapped in bad hands. At National Life, that means thinking about AI as a portfolio of bets — some exploratory ones, some scaled with intent, and all assessed not only on immediate return but on how they expand capabilities. Positioning the enterprise for its next move is an important lesson for CIOs. “The goal isn’t to win every hand, but build a system to place better bets over time,” says Mehta.

Lessons for CIOs playing to win

For CIOs, the takeaway is clear. Stop defining success as the absence of loss and define it as the presence of disproportionate upside. Shift your decision model from deterministic certainty to probabilistic advantage. Build a portfolio of bets tied closely to the business with enough governance to manage risk, but not so much that governance becomes an excuse for inaction.

Know when to press on emerging momentum and walk away from bets that don’t compound value. Most of all, recognize that AI leadership is about demonstrating you can read the table, understand the odds, and move with conviction before the rest of the market catches up, not just proving you can keep the lights on while experimenting at the edges.

Systems integrators (SIs) have been integral to IT projects for decades, providing consulting services and helping enterprises build and launch technology tools.

Now, as organizations move to deploy agentic AI, top large language model (LLM) providers are looking to get in on that action. A proliferation of Forward Deployed Engineer (FDE) services embeds AI experts directly into customer teams to help create, customize, and launch AI services.

For instance, this week, Microsoft launched a $2.5 billion venture, Microsoft Frontier Company, that the tech giant says “goes beyond” FDE, and Amazon Web Services (AWS) announced its own $1 billion investment into a new AWS FDE platform.

Both projects will integrate thousands of Microsoft and AWS engineers into customer environments to help them not only build AI tools, but learn essential skills to handle projects on their own going forward. Other big model players, including Anthropic, are also getting into the game with their own FDE services.

The gap between AI investment and ROI is growing, noted Thomas Randall, research director at Info-Tech Research Group, and organizations are under pressure to show production value from AI deployments.

This is the context in which vendor FDEs such as those from Microsoft and AWS will become relevant to “compress learning curves from their deep product knowledge, establish reusable processes, and build capabilities that can then be transferred,” he said.

Frontier transformation

Microsoft Frontier Company will place 6,000 experts with customers to “co-design, co-innovate, deploy and continuously improve” AI systems based on their specific business goals, Judson Althoff, CEO of Microsoft Commercial Business, wrote in a blog post.

The new offering focuses on what Microsoft calls “Frontier Transformation,” helping customers build an intelligence platform based on their proprietary data and internal expertise, workflows, and decision-making processes. Based on FinOps principles, the offering helps users “observe, govern, manage, and secure” AI tools across their stacks, and their intelligence compounds over time, Althoff said.

Microsoft Frontier Company is a “model-diverse, open, heterogeneous” platform, Althoff noted; customers can choose their own models: ChatGPT, Claude, Microsoft Copilot, or other open source or industry-specific models.

“Customers shouldn’t be locked into a single model any more than they should be locked into a single technology vendor,” Althoff noted. Further, he emphasized, customer data and IP are protected, and are not used to train Microsoft’s models.

The tech giant says it will leverage its SI and FDE partnerships with Accenture, Capgemini, EY, KPMG, PwC, and others to help scale the platform. Early users including London Stock Exchange Group (LSEG), Land O’Lakes, Unilever, and Novo Nordisk are already seeing “measurable outcomes,” Althoff said.

For instance, AI embedded into LSEG Workspace helps finance experts ask complex questions and get quick answers based on structured and unstructured financial data. The underlying foundation is “iteratively refined” through client feedback and real-time user testing, Althoff explained. This accelerates each cycle and improves model quality and scope.

This is the value of FDEs, he contended: “Enterprise AI engineering expertise with deep industry knowledge is required to build a system that acts as a continuous loop of improvement,”

Compressing timelines

Like Microsoft Frontier Company, AWS FDE embeds its experienced engineers into customers’ business, engineering, and security teams to help them build and launch agents purpose-built on their specific data, processes, and governance frameworks, AWS’ VP of frontier AI engineering and services Francessca Vasquez explained in a blog post.

“Unlike traditional consulting that assesses, recommends, and treats each deployment as a standalone project, AWS FDE builds for the long term,” she noted. Customers become “self-sufficient with AI,” moving from “observers to co-builders to autonomous operators” as they learn AI skills, workflows, and patterns that they can use to build AI going forward.

The platform is agentic-first and designed to compress timelines “from months to days,” and the derived business intelligence compounds to support future projects, Vasquez said.

Embedded engineers, many of whom build AWS AI services, verify and guide projects; AWS says it is also investing in training, tools, and resources for partners, to bolster the platform.

Customers gain access to runbooks, and architectural documentation, and a semantic layer connects to their data sources to create a knowledge graph that AI agents can reason over, Vasquez said.

She emphasized that domain expertise resides in the customer’s code, agents, and systems, so institutional knowledge does not get lost with employee turnover. Further, security tools provide hardware-based isolation and end-to-end encryption.

AWS FDE is not intended for those merely experimenting with AI, Vasquez noted, it is “built for organizations that have moved past experimentation and need production AI systems running real business processes.”

Still a market for SIs

SIs have enjoyed decades of high-margin relationships with their customers, so it makes “eminent sense” for hyperscalers to try to grab some of that business for themselves, noted technology analyst Carmi Levy.

“Both Microsoft and Amazon are aggressively looking for ways to tighten customer lock-in and open up more opportunities to get inside both their clients’ operations and decision making apparatus,” he pointed out.

In addition, Randall said, Info-Tech’s research reveals that 77% of organizations do not have a corporate-wide AI strategy. FDEs will address this by being narrow and specific to the customer’s working AI systems, reference architecture, runbooks, and other deliverables.

SIs, however, provide a different service, he said. Their relevance will be in broader integration knowledge across systems, managing change, and scaling programs. “Their deliverables will be more strategic and broader in scope.”

Of course, there is overlap, he said, and Microsoft will work closely with global SI partners. The investment gap and implementation complexity put hyperscalers under pressure to “provide more white-glove services to pull their customers along.”

Considerations for enterprises

Levy noted that, for customers who have already decided on a particular AI stack, these platforms may be worthwhile as long as they’re comfortable taking a single-vendor route.

“Assuming Microsoft and Amazon are price- and service-competitive with systems integrators, they may represent a compelling alternative,” he said. Still, using their services could come at a cost of potentially reduced choice, which could limit longer-term options.

It remains to be seen whether these types of platform are better for the customer or the vendor, and deliver more value than existing alternatives, he said, but the market will ultimately decide.

With that in mind, he advised IT decision makers to deep-dive not only into Microsoft’s and Amazon’s agentic delivery competencies compared to those of SIs, but into whether their underlying motivations are “truly in the customers’ best interests.”

Info-Tech’s Randall also advised enterprises to consider the output they’re looking for. FDEs will fast-track accurate builds on specific platforms they specialize in, while SIs will then help make the platform work across an enterprise context.

FDE options are best for organizations looking past AI pilots to quick, effective product buildouts, he said. SIs are needed when those organizations need to scale that pattern across messy enterprise processes.

Another factor to consider: “FDEs are not suitable for organizations still working on basic AI strategy questions or that want to remain cloud neutral,” said Randall.

This article originally appeared on CIO.com.

Systems integrators (SIs) have been integral to IT projects for decades, providing consulting services and helping enterprises build and launch technology tools.

Now, as organizations move to deploy agentic AI, top large language model (LLM) providers are looking to get in on that action. A proliferation of Forward Deployed Engineer (FDE) services embeds AI experts directly into customer teams to help create, customize, and launch AI services.

For instance, this week, Microsoft launched a $2.5 billion venture, Microsoft Frontier Company, that the tech giant says “goes beyond” FDE, and Amazon Web Services (AWS) announced its own $1 billion investment into a new AWS FDE platform.

Both projects will integrate thousands of Microsoft and AWS engineers into customer environments to help them not only build AI tools, but learn essential skills to handle projects on their own going forward. Other big model players, including Anthropic, are also getting into the game with their own FDE services.

The gap between AI investment and ROI is growing, noted Thomas Randall, research director at Info-Tech Research Group, and organizations are under pressure to show production value from AI deployments.

This is the context in which vendor FDEs such as those from Microsoft and AWS will become relevant to “compress learning curves from their deep product knowledge, establish reusable processes, and build capabilities that can then be transferred,” he said.

Frontier transformation

Microsoft Frontier Company will place 6,000 experts with customers to “co-design, co-innovate, deploy and continuously improve” AI systems based on their specific business goals, Judson Althoff, CEO of Microsoft Commercial Business, wrote in a blog post.

The new offering focuses on what Microsoft calls “Frontier Transformation,” helping customers build an intelligence platform based on their proprietary data and internal expertise, workflows, and decision-making processes. Based on FinOps principles, the offering helps users “observe, govern, manage, and secure” AI tools across their stacks, and their intelligence compounds over time, Althoff said.

Microsoft Frontier Company is a “model-diverse, open, heterogeneous” platform, Althoff noted; customers can choose their own models: ChatGPT, Claude, Microsoft Copilot, or other open source or industry-specific models.

“Customers shouldn’t be locked into a single model any more than they should be locked into a single technology vendor,” Althoff noted. Further, he emphasized, customer data and IP are protected, and are not used to train Microsoft’s models.

The tech giant says it will leverage its SI and FDE partnerships with Accenture, Capgemini, EY, KPMG, PwC, and others to help scale the platform. Early users including London Stock Exchange Group (LSEG), Land O’Lakes, Unilever, and Novo Nordisk are already seeing “measurable outcomes,” Althoff said.

For instance, AI embedded into LSEG Workspace helps finance experts ask complex questions and get quick answers based on structured and unstructured financial data. The underlying foundation is “iteratively refined” through client feedback and real-time user testing, Althoff explained. This accelerates each cycle and improves model quality and scope.

This is the value of FDEs, he contended: “Enterprise AI engineering expertise with deep industry knowledge is required to build a system that acts as a continuous loop of improvement,”

Compressing timelines

Like Microsoft Frontier Company, AWS FDE embeds its experienced engineers into customers’ business, engineering, and security teams to help them build and launch agents purpose-built on their specific data, processes, and governance frameworks, AWS’ VP of frontier AI engineering and services Francessca Vasquez explained in a blog post.

“Unlike traditional consulting that assesses, recommends, and treats each deployment as a standalone project, AWS FDE builds for the long term,” she noted. Customers become “self-sufficient with AI,” moving from “observers to co-builders to autonomous operators” as they learn AI skills, workflows, and patterns that they can use to build AI going forward.

The platform is agentic-first and designed to compress timelines “from months to days,” and the derived business intelligence compounds to support future projects, Vasquez said.

Embedded engineers, many of whom build AWS AI services, verify and guide projects; AWS says it is also investing in training, tools, and resources for partners, to bolster the platform.

Customers gain access to runbooks, and architectural documentation, and a semantic layer connects to their data sources to create a knowledge graph that AI agents can reason over, Vasquez said.

She emphasized that domain expertise resides in the customer’s code, agents, and systems, so institutional knowledge does not get lost with employee turnover. Further, security tools provide hardware-based isolation and end-to-end encryption.

AWS FDE is not intended for those merely experimenting with AI, Vasquez noted, it is “built for organizations that have moved past experimentation and need production AI systems running real business processes.”

Still a market for SIs

SIs have enjoyed decades of high-margin relationships with their customers, so it makes “eminent sense” for hyperscalers to try to grab some of that business for themselves, noted technology analyst Carmi Levy.

“Both Microsoft and Amazon are aggressively looking for ways to tighten customer lock-in and open up more opportunities to get inside both their clients’ operations and decision making apparatus,” he pointed out.

In addition, Randall said, Info-Tech’s research reveals that 77% of organizations do not have a corporate-wide AI strategy. FDEs will address this by being narrow and specific to the customer’s working AI systems, reference architecture, runbooks, and other deliverables.

SIs, however, provide a different service, he said. Their relevance will be in broader integration knowledge across systems, managing change, and scaling programs. “Their deliverables will be more strategic and broader in scope.”

Of course, there is overlap, he said, and Microsoft will work closely with global SI partners. The investment gap and implementation complexity put hyperscalers under pressure to “provide more white-glove services to pull their customers along.”

Considerations for enterprises

Levy noted that, for customers who have already decided on a particular AI stack, these platforms may be worthwhile as long as they’re comfortable taking a single-vendor route.

“Assuming Microsoft and Amazon are price- and service-competitive with systems integrators, they may represent a compelling alternative,” he said. Still, using their services could come at a cost of potentially reduced choice, which could limit longer-term options.

It remains to be seen whether these types of platform are better for the customer or the vendor, and deliver more value than existing alternatives, he said, but the market will ultimately decide.

With that in mind, he advised IT decision makers to deep-dive not only into Microsoft’s and Amazon’s agentic delivery competencies compared to those of SIs, but into whether their underlying motivations are “truly in the customers’ best interests.”

Info-Tech’s Randall also advised enterprises to consider the output they’re looking for. FDEs will fast-track accurate builds on specific platforms they specialize in, while SIs will then help make the platform work across an enterprise context.

FDE options are best for organizations looking past AI pilots to quick, effective product buildouts, he said. SIs are needed when those organizations need to scale that pattern across messy enterprise processes.

Another factor to consider: “FDEs are not suitable for organizations still working on basic AI strategy questions or that want to remain cloud neutral,” said Randall.

AWS has increased key Amazon Bedrock AgentCore runtime quotas by up to fivefold, enabling enterprises to support more concurrent AI agents and user interactions without going through the quota-increase process that often slows production deployments.

While quota increase service requests are free themselves, the added capacity is more likely to translate into higher underlying compute and runtime consumption as enterprises expand AI deployments.

“The new default limits support up to 5,000 active concurrent sessions in US East (N. Virginia) and US West (Oregon), and 2,500 in all other supported Regions (previously 1,000 and 500 respectively),” AWS wrote in its release notes.

The hyperscaler has also increased the number of interactions each AI agent can handle from 25 tokens per second to 200 tokens per second across all supported regions, which it says will enable enterprises to support more simultaneous user requests.

Further, to help enterprises scale AI applications faster during periods of peak demand, the hyperscaler also quadrupled the rate at which new AI agent sessions can be created for container deployments, increasing the limit from 100 TPM to 400 TPM.

Why the higher quotas matter for enterprise AI deployments

The change in AgentCore Runtime quotas, according to Charlie Dai, principal analyst at Forrester, is the hyperscaler’s response to enterprises rapidly shifting AI-agent experiments to production deployments: “In our client conversations, the bigger change is not the number of agents but the move from single-task copilots to multiple production-grade agents serving larger user populations.”

That means that AWS is seeing higher concurrency, longer-running agents, and more complex orchestration patterns that exceed earlier default assumptions, Dai said.

For enterprises making that transition, the higher default quotas, according to Ashish Banerjee, senior principal analyst at Gartner, will help reduce the operational friction of scaling AI agents from pilot projects to production deployments.

Large-scale AI deployments, especially multi-agent systems, are becoming an operational consideration as they outgrow default runtime quotas quickly, requiring enterprises to seek quota increases, echoed Amit Chandak, chief analytics officer at IT Consulting firm Kanerika.

“That quota increase request in an enterprise environment means a support ticket, a business justification, and a review cycle. That’s days or weeks of overhead on something that shouldn’t block a deployment,” Chandak said.

“A quota beyond the process cost, teams design architectures around whatever the default ceiling is. Higher defaults change what teams are willing to attempt without triggering an exceptions process, and that shapes architectural decisions, not just day-to-day operations,” Chandak added.

The benefits extend beyond reducing administrative overhead, Chandak further added, as exhausting runtime quotas in production can interrupt customer-facing applications and multi-agent workflows.

“Agent sessions are stateful. When a session gets throttled mid-task, the agent can lose intermediate context, and reconstructing that state is significantly harder than retrying a stateless API call,” Chandak pointed out.

“In multi-agent pipelines, one rejected session stalls the entire workflow. You get orphaned sessions, incomplete tool calls, and gaps in monitoring that are hard to diagnose after the fact,” Chandak added.

These gains, however, are unlikely to be uniform across enterprises. Enterprises running high-concurrency, transaction-intensive AI workloads, according to Gaurav Dewan, research director at Avasant, stand to benefit the most from the higher default quotas.

These include customer service and contact centers, software engineering and DevOps automation, IT operations, financial services process automation, healthcare administration, supply chain coordination, and security operations, where AI agents often operate simultaneously at scale, Dewan added.

Hyperscalers are taking different paths to production AI

AWS, however, is not alone in adapting its infrastructure for helping enterprises scale AI agents in production, and rival hyperscalers, such as Microsoft and Google, are approaching the challenge in different ways.

Microsoft’s approach with the Azure Foundry Agent Service, according to Chandak, differs from AWS: “Many of its agent runtime limits are fixed by design; they cannot be increased even on request.”

“Instead, Microsoft puts the scaling flexibility at the model deployment layer, where quotas are adjustable, rather than at the agent runtime layer. That’s a deliberate architectural difference from what AWS is doing with AgentCore: raising the floor on concurrent sessions at the runtime level,” Chandak pointed out.

The updated quota limits for Bedrock AgentCore will automatically apply to all enterprise accounts, AWS said.

The PC was heralded as revolutionary; it was going to save time, revolutionize our work… But it became an opportunity lost. Paper became digital files. Filing cabinets became shared drives. Memos became email. We sometimes worked faster. We did not necessarily work differently. And we certainly did not work more efficiently. The underlying logic: approval chains, reporting cycles, hierarchies and incentives remained intact.

The internet and smartphones followed the same pattern, compressing time and distance. But neither forced enterprise changes. The tools changed. The organizational model did not. This stagnation is referred to as the Solow Productivity Paradox, a historic mismatch between massive technology investments and flat corporate productivity. And while the Internet boom did see a raise in productivity, it was due to investment in hardware, not so much due to a change in how we worked, as explained by Robert Gordon in The New Economy: What Productivity Miracle?

And now there’s Artificial Intelligence, AI. AI presents a different kind of challenge because it intervenes in cognition itself. It reaches much closer to the operating logic of the enterprise than previous technology waves.

Yet, once again, the response is surface adaptation rather than structural reinvention. AI is layered onto inherited workflows, old approval thresholds, unclear accountability structures and sprawling software, then expecting cost savings to follow. And again, it is the investments in AI that garner any growth, not changes in corporate infrastructure.

This is not transformation. It is acceleration without reform. And this “slap on AI” will have as much long-term impact as the PC.

Automation = efficiency? Wrong

Chief information officers are under intense pressure to turn AI into measurable financial outcomes. In boardrooms, expectations are explicit: deploy AI, automate, reduce operating cost and show results within a budget cycle.

A central misunderstanding in AI programs is the assumption that if a process is costly and labour-intensive, automation creates efficiency. Unfortunately, what appears as inefficiencies are normalized fragmentations. With AI, hidden workflow contradictions become both significant and visible. Organizations discover it wasn’t running a slow but clean process. It was running an incoherent process that relied on human buffering to keep it functioning. This is precisely why so many AI efforts disappoint immediately after a dazzling pilot, degenerate into AI strategy theatre and fail to scale.

When one part of the workflow becomes lightning-fast, but the surrounding process remains fractured, escalations multiply and the IT department, despite having done its job perfectly, is asked to fix the operational fallout with more tooling, more integration, more controls and more spend. The problem is rarely technical. But it becomes so very quickly.

I increasingly think the more useful concept here is process debt. CIOs are already comfortable talking about technical debt and its complexities. Process debt is the upstream generator of that complexity. It accumulates when temporary fixes become permanent, when controls are added without removing older ones and when incidents leave behind workflows nobody dares to challenge. Over time, the process stops reflecting deliberate design and starts reflecting institutional memory, risk aversion and unresolved negotiations between functions.

Case study 1: The regulated approval-heavy process

I was brought into a regulated organization that wanted to identify opportunities for automation. The assumption was that technology was the main constraint. Workflows involved multiple reviews, approvals and handovers between departments. From a distance, it looked like an obvious candidate for automation.

It was a familiar situation: delays, duplicated effort and frustration with how long routine work was taking to complete. The process seemed overstaffed and underdesigned. The natural conclusion was that automation could remove unnecessary tasks and improve speed.

But as I began interviewing the stakeholders, a different picture emerged. Every group could explain its role in the workflow. But the more I listened, the clearer it became that nobody could describe the process as a coherent whole.

What appeared to be an inefficient process was a process that had accumulated layers of governance without ever being reassembled into a consistent operating model. One approval had been added after an audit finding. Another had been introduced during a restructuring. A third existed because of a past incident. None of those approvals looked unreasonable in isolation. Together, they produced a workflow that nobody owned and with approval layers nobody could justify.

From the CIO’s perspective, this translated into technology sprawl. Unaligned and multiple IT systems were being used to support adjacent parts of the workflow. Software had been purchased to manage steps that shouldn’t have existed in the first place. This meant the entire nature of the automation discussion shifted. The strategic question was no longer which step should be automated first. It was whether those steps deserved to exist at all.

Only after the CIO and I brought the business units together to confront these structural dependencies did the process align and technology become part of the answer. Without that preliminary work, automation would simply have moved a poorly understood process faster while expanding the expensive software estate needed to govern it.

That engagement reinforced my conviction that many workflows presented as automation candidates are not ready for automation because they are not sufficiently coherent to automate.

Uncomfortable questions

Because these questions are operationally and politically sensitive, businesses will try to avoid them and hand the unmapped mess directly to IT. As a strategic partner, the CIO must guide the C-suite through these uncomfortable but necessary inquiries before deploying AI into enterprise workflows:

• Does this process need to exist at all?
• Where are decisions actually made in day-to-day practice? Not according to policy documentation, but according to the informal networks of people who actually know how to navigate the exceptions.
• Which parts of the workflow exist because of corporate history rather than necessity?
• Where do decision rights shift between teams without anyone acknowledging it?

AI systems do not handle ambiguities gracefully. Answering these questions upfront determines whether implementing AI will mean genuine savings or simply move organizational incoherence through the enterprise at lightning speed.

Three-layer governance

Governance is the ultimate reason why AI cannot be treated as a traditional technology delivery program with a bit of business input tacked on at the end. Because AI fundamentally alters how enterprise decisions are informed and executed, its deployment must be shaped by an integrated operating and governance framework.

CIOs can evaluate an organization’s true AI readiness based on three interdependent governance layers. By mastering these, the technology stack is protected from being forced to compensate for bad business design.

1. Organizational governance. Core questions: Is this workflow genuinely needed, who actually owns it and what risk or quality definitions are binding across separate business functions? This is a cross-departmental leadership question. It must be resolved by the business units first, or IT inevitably inherits the resulting operational complexity.
2. Endpoint or tool governance. Core questions: How are outputs interpreted when cognitive work is partially or fully delegated to machines? This layer defines exactly where a human-in-the-loop remains mandatory, how exceptions are escalated to specialists and how accountability is maintained when an AI agent makes an optimized operational prediction.
3. Platform governance. Core questions: What is the foundational security, privacy and technical guardrails? This includes LLM/model selection, vendor standards, data privacy compliance, integration rules and continuous monitoring. Paradoxically, this is the layer most organizations focus on first—yet, because it exists entirely to support the processes and tools above it, it should actually be the last to be set in stone.

These layers interlinked. A weakness in one undermines the others. This is where CIOs become strategically important. They are the executives who see when process incoherence is converted into architectural complexity, application sprawl, higher license costs and long-term support burdens. AI decisions without that perspective and organizations will once again confuse digitization with transformation.

Case Study 2: A downstream bottleneck and the structural solution

In another engagement, the business pushed for an AI-driven intake solution. Frontline teams were spending massive amounts of time on repetitive customer data coordination and document verification. On paper, it was an outright victory: IT delivered an AI agent that dropped data extraction times by 85% with an exceptional accuracy rate. In every sense of the word – the pilot was a triumph. And it was phased to implementation.

Within six weeks, the illusion shattered. While the intake layer was now running at lightning speed, the downstream validation process still relied on traditional compliance handoffs, manual fraud checks and legacy database updates. The AI didn’t solve the operational problem; it simply shoved massive volumes of data into a rigid pipeline that was never designed for that velocity.

Escalation queues exploded. The operations team, buried under an unprecedented backlog, began making manual bypass decisions just to keep up, creating immense operational risk.

Rather than allowing IT to be blamed for the downstream chaos, the CIO and I suggested a structural solution. First, we halted further automated intake scaling and used visual process-mapping data to show the rest of the C-suite exactly where the digital pipeline was hitting an analogue wall.

Second, we championed a cross-functional “value stream” redesign. After much negotiation, we managed to leverage the AI’s data-validation outputs to eliminate three manual review steps downstream and replace them with exception-only automated alerts. Finally, we renegotiated the risk-threshold parameters with the legal and compliance teams, shifting accountability from a multi-stage sign-off to a centralized, systemic audit log.

The solution wasn’t adding more software; it was picking the process apart, data point by data point, to align the business rules with machine capabilities. The result was a substantially trimmer, automated end-to-end stream that freed up human resources, allowed redundant software licenses to be safely withdrawn and actually realized the promised financial savings.

Conclusion

Every CIO knows that AI matters. The real challenge facing enterprises whether the executive leadership team is willing to confront what AI inevitably reveals about the fragmented processes, legacy habits and siloed systems organizations have been carrying for decades.

This is why the broad promise of immediate AI savings is overstated. Automation can produce staggering enterprise value, but it cannot create structural coherence on its own. If a workflow is fractured, historically layered and dependent on invisible human intervention, adding AI will not turn it into an efficient system. It will simply scale, cement and automate the weaknesses that were already there.

The CIO’s ultimate responsibility is to ensure that technically incoherent processes do not get permanent residency in the business architecture. This is why the CIO must have a leading seat at the strategic table. Incoherent processes invariably turn into application sprawl, redundant tooling, excess licensing costs, integration debt and massive security exposure.

To avoid this trap, enterprise AI deployment requires cross-departmental leadership willing to examine which work should be automated, which must be completely redesigned and which should be eliminated. 

If not, we will simply repeat the costly errors of past technology shifts: preserve the outdated operating logic, throw a shiny new layer of tooling on top and call the expensive result “transformation.” This time, the bill will be significantly larger. Not because AI is mysterious, but because it is brutally efficient at exposing the waste that organizations used to hide inside their people, their processes and their software.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?