As enterprises rush to build AI agents that can reason over business data and take action, Databricks argues that the long-standing practice of separating operational and analytical data systems is turning into a liability.

That separation, the cloud-based data warehouse provider says, is becoming increasingly strained as AI agents require simultaneous access to live operational data and historical context to make decisions and take actions in real time, unlike humans, who traditionally can work with data that is minutes or hours old.

At its annual Data + AI Summit, the data warehouse provider introduced Lake Transactional and Analytical Processing (LTAP), a new architecture designed to unify transactional and analytical data on a single storage layer.

The new approach, according to Databricks, differs from traditional online transaction processing (OLTP) and online analytical processing (OLAP) architectures, which typically store operational and analytical data in separate systems.

Traditionally, OLTP databases are optimized for running day-to-day business operations such as order processing, payments, and inventory updates, while OLAP systems are designed for large-scale analytical queries and reporting.

As a result, enterprises often need to rely on ETL pipelines, data replication, and separate infrastructure to move information between the two environments.

LTAP, Databricks said, seeks to eliminate the reliance on ETL pipelines, replicated databases or separate data copies by storing data once in a shared lakehouse layer while allowing dedicated compute engines to handle transactional and analytical workloads independently.

This approach, the company argued, provides AI-driven agents and applications access to both live operational data and historical analytical context without requiring data movement or duplicate copies.

Developer simplicity in the agentic era

Analysts, too, agree with Databricks’ contention that AI agents place new demands on enterprise data architectures.

“Agents don’t behave like people, or even like the apps we built for people. They read for context, loop, try things, then write something back, thousands of times over in ways you can’t fully predict. At that volume, the constant bouncing between production and analytics systems starts becoming the bottleneck. The pressure to collapse that gap is real, and LTAP is one way to approach it,” said Michael Leone, principal analyst at Moor Insights and Strategy.

Bhupendra Chopra, cofounder and CRO at IT consulting firm Kanerika, pointed out that an autonomous agent’s data access pattern makes the traditional architectures brittle: “We’re seeing this directly with clients deploying multi-agent systems, the pipeline layer becomes the ceiling almost immediately as an agent runs hundreds of times per task.”

The analysts also pointed out that the ability to collapse the gap between OLAP and OLTP is likely to help developers design more robust AI agents or applications that enterprises are currently targeting to deploy.

“The most interesting workflow or application patterns are real-time, context-aware applications that combine transactions, analytics, and AI in one flow,” said Stephanie Walter, practice leader of AI stack at HyperFRAME Research.

“Examples include AI agents that update customer workflows while seeing historical account context and fraud systems that act on live transactions and long-term behavioral patterns,” Walter added.

Designing such applications today, however, according to Leone, would require developers to pull together data from transactional systems, data warehouses, vector databases, and other sources through custom integrations, creating significant engineering complexity and maintenance overhead.

Operational simplicity and governance gains for CIOs

For CIOs,  LTAP’s ability to reduce that engineering complexity, according to Ashish Chaturvedi, leader of executive research at HFS Research, will result in operational simplicity as well as cost savings.

“Most prominent advantage would be fewer data pipelines and everything that cascades from eliminating them. Most enterprises don’t realize how much of their data engineering budget is pure plumbing maintenance,” Chaturvedi said.

Kanerika’s Chopra pointed out that a substantial portion of data engineering capacity in mid-to-large enterprises today is consumed by maintaining synchronization between transactional and analytical systems.

The implications, however, Chaturvedi noted, are not limited to developer productivity, architectural simplicity, or cost savings: “The strategic prize is simplified governance. When you have one copy of data under one governance model instead of the same data scattered across operational stores, replicas, warehouses, and vector databases, you’ve solved the governance fragmentation problem.”

That simplification, according to Chopra, will matter operationally for enterprises deploying multiple AI agents, as these workflows can amplify governance gaps at a speed and scale that no human workflow ever did.

LTAP versus HTAP

Despite all its benefits, though, LTAP isn’t the first effort to unify operational and analytical workloads under a single architecture and for years.

The industry has pursued a similar goal through Hybrid Transactional and Analytical Processing (HTAP) architecture, which sought to combine operational and analytical workloads on tightly coupled infrastructure to serve both workload types from the same system.

LTAP, in contrast, separates storage from compute, allowing different engines to access a common data layer while remaining independently scalable, Databricks said.

That separation of compute engines is why analysts think that LTAP might be a better bet than HTAP.

“HTAP never took off because asking one tightly bound system to be great at transactions and great at analytics usually left it mediocre at both, so customers ended up paying a premium for that compromise,” Leone said.

“I think separating storage from compute is the right instinct, and it’s the same move that made the modern cloud data world work in the first place. It matters because the thing that sank HTAP was one workload starving the other, and giving each side its own dedicated engine is exactly how you keep that from happening,” Leone added.

Another reason for HTAP’s failure, according to David Menninger, executive director of software research at ISG, was its requirement for enterprises to replace existing data platforms with a new architecture.

LTAP, by contrast, builds on the now-common practice of separating compute and storage, making the addition of an operational layer less of an architectural transformation and potentially lowering the barrier to adoption, Menninger added.

Not yet the default architecture for AI agents

However, despite the enthusiasm around LTAP, analysts warned CIOs against viewing this as the inevitable successor to existing data architectures.

“CIOs will still need to choose their data architecture based on latency, reliability, ecosystem fit, cost, compliance, and developer experience,” Walter said.

Echoing Walter, Chaturvedi pointed out that for LTAP to become the de facto standard for the industry, Databricks will need more than architectural elegance: “The architecture looks sound on paper. The proof will be in the commit-to-query latency numbers under real load.”

LTAP, Databricks said, is expected to be released soon as part of Lakebase, without providing any specific timelines.

Every organization has data scattered across data warehouses, data lakes, SaaS platforms, cloud drives, and data centers. Data fabrics enable organizations to centralize and control data access, making it easier for users, such as data scientists and citizen data analysts, to find and use trusted and governed data sources. 

Data fabrics, data meshes, and distributed data clouds are all platforms to help IT and data teams put some order to the chaos around the myriad of data sources they support. Large companies need data fabrics due to the volume and variety of their data sources.

“A data fabric can be thought of as the connective tissue that ensures consistent accessibility, availability, and understanding of data across an organization,” says Dominic Wellington, data and AI expert at SnapLogic. “Individual siloed platforms may have their own internal data transfer systems, and particular teams or departments may adopt interchanges that work for that domain, but a data fabric operates at a higher level, ensuring that unified data policies are applied end-to-end across the entire enterprise.”

Types of data fabrics

When reviewing data fabrics, it’s important to consider their primary use cases, supported data types, data processing capabilities, data management structures, and governance functions. Below are some considerations when reviewing data fabrics as features, platforms, and stand-alone products.

• Some data fabrics are optimized for analytics and machine learning use cases and may have limited support for unstructured data.
• Other data fabrics extend the functionality of data governance platforms beyond data cataloging and metadata management and now include persistent data management, data quality, and dataops capabilities.
• Many data integration and API connectivity platforms go beyond proxying, pipelining, and transforming data to include search, governance, and other capabilities from data centralization.
• Some SaaS platforms are extending their connectivity and data integration capabilities, enabling multicloud portability and persistent data.
• The more advanced data fabrics support features needed for AI agents and AI model training. These platforms create a semantic context layer for structured and unstructured data sources, support Model Context Protocol (MCP) integrations, have real-time query capabilities, centralize policy-driven governance, and track data lineage.    

Why data fabrics are needed for AI

Data fabrics are not just for enterprises, and today, even smaller companies need them as part of their AI democratization programs. Here are a few reasons why:

• AI agents in enterprise SaaS solutions need access to broader data sets than those core to their workflows. Platforms such as Adobe, Appian, Oracle, Salesforce, ServiceNow, SAP, and Workday offer data fabric capabilities to bring data outside of the business processes they manage into scope for their AI agents.
• Unstructured data is important for setting the context for AI agents, and data fabrics are now used to provide access to documents, emails, transcripts, and other media formats.
• Data fabrics provide data access standards for the devops teams experimenting with AI code generators, vibe coding tools, and spec-driven development approaches to develop applications and AI agents. 
• As companies use MCP servers to connect AI agents, data fabrics provide a standardized way for the agents to access governed, trusted data sources.

“As AI agents move from generating insights to taking action, the data fabric becomes foundational in the agentic era,” says Irfan Kahn, president and chief product officer of SAP Data & Analytics. “Most enterprises operate across scattered data sources and diverse data landscapes, and what’s needed is shared business context, governed access, and clear accountability for how data is used in decision-making. Without that context, agents can’t fully understand or coordinate across the enterprise to deliver meaningful value.”

Sanjay Koppikar, chief product officer and cofounder of EvoluteIQ, adds, “Multi-agent architectures become untrustworthy when a unifying data fabric architecture is missing, since agents will often work against each other in the service of their own objectives.”

Delivering context to AI agents

AI agents need a combination of real-time data, user information, problem details, and historical context to guide their decision-making. Vishal Sood, president of research and development at Typeface, says, “MCP and data fabrics give agents access, but the harder problem is contextualizing data across multiple sources and ensuring the underlying content, media, and unstructured data are trustworthy.”

Data fabrics are the foundational elements for providing current information and long-term memory to AI agents. They simplify the many-to-many problem of connecting multiple AI models, AI agents, and MCP server integrations to multiple structured and unstructured data sources.

“The data fabric does a beautiful job of encompassing three concepts needed to create applications and processes: the data catalog, the data model, and data access,” says Sanat Joshi, executive vice president of product and innovations at Appian. “But now add business rules, process models, APIs, security groups, the organizational model, and their interrelationships into one unified view of the enterprise, and that becomes your context layer.” 

Integrations with data fabrics

Devops teams just getting started on an AI agent proof of concept may want to connect directly to the optimal data sources and APIs. Michel Tricot, CEO and cofounder at Airbyte, says connecting agents to live APIs is a great start, but it creates two big problems: APIs only return data that an agent already knows to ask for, and every query is an expensive API call chain that, with overhead, can overwhelm infrastructure in production volumes.

Tricot says the data fabric for AI use cases must be dynamic, leveraging discovery of available information from replicated data, fetching live contextual information, and writing the data back to business applications to update records.

Moving data in and out of the data fabric requires an integration strategy. Zero-ETL (extract, transform, load) is one low-cost, efficient approach for connecting to structured data sourced without replicating information. Once information is accessed centrally, it also enables streamlined security and governance.

“The promise of AI agents breaks down when they’re stuck waiting on brittle ETL, dealing with poor data quality, and lacking the right context to perform analysis,” says Preston Wood, chief security and strategy officer at Databahn. “Generating AI-ready data within a data fabric gives agents real-time access to operational data without the latency and drift that undermine decision quality. A well-architected data fabric provides the governance and lineage controls that let you deploy agents confidently, knowing exactly what data they’re touching and why.”

Centralizing AI-ready data

Data fabrics centralize AI-ready data and help data governance teams address data quality issues, biased data concerns, privacy compliance, and other data governance non-negotiables. Data fabrics also help address integration issues, monitor for data pipeline errors, and report on performance latencies. The result is that AI agents, models, and other analytics capabilities can then connect to trusted data sources with consistency.

“As AI agents and MCP architectures increasingly rely on data fabrics as their golden source of truth, data quality stops being a hygiene problem and becomes a trust problem, as we all know that trust is foundational to autonomous decision-making,” says Kellyn Gorman, database and AI advocate and engineer at Redgate Software. “Organizations that invest now in semantic consistency, lineage tracking, and observable data contracts across data fabrics will be the ones whose AI agents can be trusted to act without constant human correction.”

Data fabrics that support zero-ETL and other bidirectional integrations with sources thus become an organizational knowledge base, the data source for training AI models, and a foundation for producing data metrics.

“AI agents are only as reliable as the data they’re built on, and most organizations underestimate how much implicit tribal knowledge lives in their transformation logic rather than their source systems,” says Tobias Ostwald, director of analytics at NMI. “If you’re exposing a data fabric to agents or MCP integrations, you need lineage, testing, and metric definitions baked into the layer itself, not just documented somewhere, because the agent can’t call a colleague to gut-check a number.”

Streamlining security and governance

With a data fabric in place, governance, security, and other risk management leaders have a central location to manage data security, centralize access controls, and fulfill other governance responsibilities. Miles Ward, CTO of AI in Solution Lines at Insight, says, “We have to move past security by isolation to a governance model where the fabric itself enforces the pavement and walls of compliance.”

The data fabric also governs entitlements for AI agents and their users. Centralizing these business rules can help organizations avoid creating AI debt, a risk if controls are implemented directly in data sources or consumers.

“The convergence of AI-generated code sprawl and autonomous MCP connectivity creates a ‘perfect storm’ of architectural drift and toxic permission combinations,” says Karen Cohen, vice president of product at Apiiro. “Effective governance requires a security data fabric that monitors these autonomous connections in real time to enforce intent-based policies and strictly limit agent scope to its specific purpose. By integrating guardrails that align AI-assisted development with secure architecture principles, enterprises can proactively secure their expanding attack surface without sacrificing developer velocity.”

Future considerations for data fabrics

Expect vendors to expand the scope of their data fabrics beyond text and documents. Some will include specialized document processing for common formats such as invoices, contracts, and product documentation. There will be skills and tools to support industry-specific documents such as health records and construction documents. Others will support multimedia file types and provide metadata extraction and search capabilities. 

“Enterprises are asking agents to reason across contracts, images, PDFs, and video, and this is where most data fabrics break,” says Dave Shuman, chief data officer at Precisely. “Multimodal data must be chunked, embedded, and governed with the same rigor as structured data, including lineage and access controls.”

Several other emerging capabilities include:

• Extended support for AI agent interfaces to aid in data discovery, and with greater contextual controls on where and when AI agents can access sensitive data
• Business ontologies, semantic layers, and knowledge graph capabilities, with management tools or integrations with third-party platforms
• Support for data contracts, service-level agreements, centralized data observability, auditing, and other functions that will enhance explainable AI capabilities
• Finops functions to track costs for data owners and consumers

As more companies depend on AI agents in their operations, expect top data fabric platforms to release capabilities to expand scope, scale, use cases, and governance.  

AIs struggle to understand documents designed for humans; the DocLang working group seeks to flip that imbalance with its specification for machine-readable business documents “built from the ground up for LLM tokenizers.”

The working group, founded by IBM, Nvidia, and Red Hat and hosted by the Linux Foundation’s LF AI & Data project, aims to create an open, universal, AI-native document format designed to improve how enterprises prepare, exchange, and govern document data for AI systems. ABBYY and Human Signal will also be involved in its development, and other contributors are welcome.

“Enterprises today work across a fragmented landscape of document formats, including PDFs, JPEGs, and other file types built primarily for human consumption rather than AI interpretation,” the group said in its launch announcement.

“This disconnect can introduce complexity, raise costs, and reduce reliability when extracting meaning from business documents,” as organizations increasingly rely on generative AI and agentic systems, it said.

Mark Collier, executive director of LF AI & Data, said the goal of the DocLang Specification Working Group is to “develop a vendor-neutral, interoperable standard that helps organizations prepare document data for AI more reliably, transparently, and at scale.”

DocLang defines a structured, machine-readable format for documents of any type, like JSON for data, that any tool can implement and any pipeline can consume. It builds on DocLing, a document processing toolkit hosted by LF AI & Data that can transform human-readable PDFs, word processor documents or spreadsheets into structured data.

Standards must evolve for AI

Something like DocLang is needed, said independent technology analyst Carmi Levy. “Existing document standards have done an admirable job allowing global stakeholders to confidently collaborate for decades, but it’s becoming increasingly clear that they are in desperate need of an update as AI reshapes the rules around how work gets done,” he explained.

Largely static document types, he said, “can be somewhat limiting when AI is redefining the very word, ‘document.’ In many ways. AI-age documents are far more iterative and dynamic than what they once were, and the definitions need to evolve with the times. The documents we currently live with simply weren’t designed for the AI age.”

Within that context, Levy said, “DocLang represents an early, best hope of achieving some kind of foundational baseline for document standards, one that will hopefully allow more intelligent, more efficient, lower-risk workflows than is currently the case.”

Taking an open-source, vendor-agnostic approach to the process ensures the collective will take precedence over the needs of specific vendors, he said, adding, “earlier standards-setting efforts around networking, documentation, the web, and the cloud powered the free-flowing digital landscape that defines modern life.”

An AI-centric documentation standard will carry that reality into the next generation of technology, said Levy.

A question of governance

The entire concept of LLMs, Jason Andersen, principal analyst at Moor Insights & Strategy said, “involves using natural human languages. The computer is supposed to understand us without us changing our syntax or language. Forcing a syntax on users is exactly what we have today with SEO and more advanced programming languages.”

With something like DocLang, where the standard can be applied to content ingestion, he said, “I would be OK with that being automated, which seems to be the intent. The use case I envision is that when I upload a document to an agent, a skill can be run to preprocess the document into the DocLang standard format, saving tokens.”

That makes sense, he said, adding that he thinks it’s good “if it can help generate outputs, like a visualization, that can be shared outside an AI tool. On that front, that is also why I am liking Web MCP, since you are just adding some code to the page, like CSS or JavaScript, and the consumer, in this case, an AI browser or skill, is better equipped to handle the site.”

The point, he said, is, “these standards need to preserve the fact that humans can still do what they want, and do not need to know any coding to be proficient. In terms of governance, I am not sure if it matters.”

But one analyst did foresee governance problems arising from DocLang’s use.

Yaz Palanichamy, senior research analyst at Info-Tech Research Group, said DocLang adoption will require organizations to implement and review controls in order to scale its use accountably and securely.

This article first appeared on CIO, on June 10, 2026.

For years, the cloud market has made a simple promise: Move workloads to large-scale platforms, gain better resilience, and worry less about downtime. That promise was never entirely wrong, but it is becoming less complete. The latest findings from Uptime Institute’s seventh Annual Outage Analysis suggest that the outage landscape is changing in ways that should concern both cloud providers and cloud customers. The biggest risks are no longer limited to broken physical infrastructure. They are increasingly tied to the complexity of the systems used to run, coordinate, update, and recover that infrastructure.

The most alarming number in the report is that IT and networking issues accounted for 23% of impactful outages in 2024. Uptime Institute links these increases to growing IT and network complexity; the long-term shift toward colocation, cloud, and third-party digital services; and the resulting increase in change-management failures and misconfigurations. That number is more than a statistical footnote. It points to a structural change in how outages happen and why cloud outages are becoming such a stubborn problem.

Hardware redundancy can protect against component failures, but it doesn’t help much when the outage stems from a bad configuration, an automation error, a faulty network change, or an underappreciated control-plane dependency. In those cases, the infrastructure itself may remain intact while the system that governs it breaks down. The industry is learning that resiliency is less about duplicating equipment and more about managing complexity. Today’s increasingly distributed and software-defined environments cannot operate safely at scale.

Failures at the operational level

Uptime’s findings show that power remains the leading cause of major outages, underscoring that traditional infrastructure engineering still matters a great deal. But even as providers continue to improve physical resilience, outages can still arise from the digital and procedural layers above it. Cloud platforms are now dense stacks of services, APIs, orchestration systems, software-defined networks, identity controls, failover logic, and third-party dependencies. That complexity creates more possible points of interaction and more opportunities for an error in one layer to cascade into several others.

This helps explain why outages can feel more surprising today than they did a decade ago. In older data center models, an outage often had a more apparent root cause, such as a power event, a cooling failure, or a hardware fault. In cloud environments, the trigger may be a small configuration change that propagates across regions, a policy update that unintentionally blocks service communication, or a network control failure that affects seemingly unrelated services. These are not failures of raw infrastructure capacity. They are failures of complexity management.

The report’s language around change management and misconfiguration is especially important because it challenges one of the most common assumptions in the cloud market: that scale automatically produces better operational outcomes. The reality? Scale can magnify both strengths and weaknesses. Large cloud providers have more engineering talent, more sophisticated tools, and more redundancy than almost any enterprise customer. But they also run far more interconnected systems at far greater speeds with far more automation. A single process failure can have a wider blast radius.

Another important lesson from the Uptime analysis is that automation has not removed the human factor. If anything, it has changed its form. Even in highly automated environments, human error remains central to the problem. The report notes that in 2025, the share of outages caused by human failure to follow procedures rose by 10 percentage points compared with 2024. A related industry summary of the report notes that 58% of human error-related outages were caused by staff failing to follow established procedures.

That matters because cloud providers often position automation as the answer to reliability. Automation is essential, but it only works as well as the operational model that surrounds it. If teams deploy changes too quickly, rollback paths are weak, approval chains are bypassed, or procedures are incomplete, automation can accelerate failure rather than prevent it. In a modern cloud environment, a human mistake is rarely just a single keystroke. It is more often a design weakness in process, governance, testing, or accountability.

This is also why customers should resist the comforting notion that outages are somebody else’s problem once workloads move to the cloud. Provider-side mistakes remain real, but customer architectures are increasingly entangled with provider networking, identity, observability, and platform services. When an outage occurs, the customer may not have caused it, but they still bear the business impact. The shared responsibility model does not end with security. It extends to resilience planning as well.

Better change management

The Uptime data points to a clear conclusion: Cloud providers need to treat operational discipline as a first-class design requirement. That starts with better change management. High-risk changes should be tested more aggressively, staged more gradually, and accompanied by stronger rollback mechanisms. Providers also need better dependency mapping to understand how a change in one control layer can affect services far beyond its immediate scope. If the system is too complex to clearly explain, it is too complex to operate.

Providers also need to improve procedural quality. The rise in outages caused by failing to follow procedures suggests that procedures are being ignored under operational pressure or that they are too cumbersome, outdated, or unclear for real production conditions. Neither explanation is comforting. Stronger runbooks, better training, more realistic failure drills, and tighter operational guardrails are not glamorous investments; they are increasingly central to resilience.

Another pressure point is visibility. Uptime notes that software-based and distributed resiliency tools can improve availability, but they also introduce new risks and complicate root-cause analysis. Cloud providers need more transparent and faster incident diagnosis, not just more layers of abstraction. Customers cannot build trust in resilience if every major incident becomes a long exercise in reconstructing opaque service dependencies after the fact.

Design with outages in mind

What’s the financial impact of more frequent problems? Uptime’s 2024 analysis found that 54% of respondents reported that their most recent significant outage cost more than $100,000, and 20% said it cost more than $1 million. These are not edge-case losses. They show that outages remain costly even if they are less frequent than in earlier years.

Customers need to stop evaluating cloud resilience through uptime promises and start evaluating it through failure behavior. How does a provider isolate faults? How transparent is incident communication? How portable are workloads if a major service degrades? How dependent is the architecture on a single region, network path, identity service, or control plane? These are not just technical questions; they are now critical business questions.

The core lesson from Uptime’s data is simple. Outages are becoming a bigger problem for cloud providers and customers because the cloud’s biggest vulnerabilities are increasingly tied to complexity, process failures, and control-plane mistakes, not just broken infrastructure. In addition to adding redundancy, the next phase of cloud improvement will focus on building systems that are easier to understand, safer to change, and more disciplined to operate.

For years, the cloud market has made a simple promise: Move workloads to large-scale platforms, gain better resilience, and worry less about downtime. That promise was never entirely wrong, but it is becoming less complete. The latest findings from Uptime Institute’s seventh Annual Outage Analysis suggest that the outage landscape is changing in ways that should concern both cloud providers and cloud customers. The biggest risks are no longer limited to broken physical infrastructure. They are increasingly tied to the complexity of the systems used to run, coordinate, update, and recover that infrastructure.

The most alarming number in the report is that IT and networking issues accounted for 23% of impactful outages in 2024. Uptime Institute links these increases to growing IT and network complexity; the long-term shift toward colocation, cloud, and third-party digital services; and the resulting increase in change-management failures and misconfigurations. That number is more than a statistical footnote. It points to a structural change in how outages happen and why cloud outages are becoming such a stubborn problem.

Hardware redundancy can protect against component failures, but it doesn’t help much when the outage stems from a bad configuration, an automation error, a faulty network change, or an underappreciated control-plane dependency. In those cases, the infrastructure itself may remain intact while the system that governs it breaks down. The industry is learning that resiliency is less about duplicating equipment and more about managing complexity. Today’s increasingly distributed and software-defined environments cannot operate safely at scale.

Failures at the operational level

Uptime’s findings show that power remains the leading cause of major outages, underscoring that traditional infrastructure engineering still matters a great deal. But even as providers continue to improve physical resilience, outages can still arise from the digital and procedural layers above it. Cloud platforms are now dense stacks of services, APIs, orchestration systems, software-defined networks, identity controls, failover logic, and third-party dependencies. That complexity creates more possible points of interaction and more opportunities for an error in one layer to cascade into several others.

This helps explain why outages can feel more surprising today than they did a decade ago. In older data center models, an outage often had a more apparent root cause, such as a power event, a cooling failure, or a hardware fault. In cloud environments, the trigger may be a small configuration change that propagates across regions, a policy update that unintentionally blocks service communication, or a network control failure that affects seemingly unrelated services. These are not failures of raw infrastructure capacity. They are failures of complexity management.

The report’s language around change management and misconfiguration is especially important because it challenges one of the most common assumptions in the cloud market: that scale automatically produces better operational outcomes. The reality? Scale can magnify both strengths and weaknesses. Large cloud providers have more engineering talent, more sophisticated tools, and more redundancy than almost any enterprise customer. But they also run far more interconnected systems at far greater speeds with far more automation. A single process failure can have a wider blast radius.

Another important lesson from the Uptime analysis is that automation has not removed the human factor. If anything, it has changed its form. Even in highly automated environments, human error remains central to the problem. The report notes that in 2025, the share of outages caused by human failure to follow procedures rose by 10 percentage points compared with 2024. A related industry summary of the report notes that 58% of human error-related outages were caused by staff failing to follow established procedures.

That matters because cloud providers often position automation as the answer to reliability. Automation is essential, but it only works as well as the operational model that surrounds it. If teams deploy changes too quickly, rollback paths are weak, approval chains are bypassed, or procedures are incomplete, automation can accelerate failure rather than prevent it. In a modern cloud environment, a human mistake is rarely just a single keystroke. It is more often a design weakness in process, governance, testing, or accountability.

This is also why customers should resist the comforting notion that outages are somebody else’s problem once workloads move to the cloud. Provider-side mistakes remain real, but customer architectures are increasingly entangled with provider networking, identity, observability, and platform services. When an outage occurs, the customer may not have caused it, but they still bear the business impact. The shared responsibility model does not end with security. It extends to resilience planning as well.

Better change management

The Uptime data points to a clear conclusion: Cloud providers need to treat operational discipline as a first-class design requirement. That starts with better change management. High-risk changes should be tested more aggressively, staged more gradually, and accompanied by stronger rollback mechanisms. Providers also need better dependency mapping to understand how a change in one control layer can affect services far beyond its immediate scope. If the system is too complex to clearly explain, it is too complex to operate.

Providers also need to improve procedural quality. The rise in outages caused by failing to follow procedures suggests that procedures are being ignored under operational pressure or that they are too cumbersome, outdated, or unclear for real production conditions. Neither explanation is comforting. Stronger runbooks, better training, more realistic failure drills, and tighter operational guardrails are not glamorous investments; they are increasingly central to resilience.

Another pressure point is visibility. Uptime notes that software-based and distributed resiliency tools can improve availability, but they also introduce new risks and complicate root-cause analysis. Cloud providers need more transparent and faster incident diagnosis, not just more layers of abstraction. Customers cannot build trust in resilience if every major incident becomes a long exercise in reconstructing opaque service dependencies after the fact.

Design with outages in mind

What’s the financial impact of more frequent problems? Uptime’s 2024 analysis found that 54% of respondents reported that their most recent significant outage cost more than $100,000, and 20% said it cost more than $1 million. These are not edge-case losses. They show that outages remain costly even if they are less frequent than in earlier years.

Customers need to stop evaluating cloud resilience through uptime promises and start evaluating it through failure behavior. How does a provider isolate faults? How transparent is incident communication? How portable are workloads if a major service degrades? How dependent is the architecture on a single region, network path, identity service, or control plane? These are not just technical questions; they are now critical business questions.

The core lesson from Uptime’s data is simple. Outages are becoming a bigger problem for cloud providers and customers because the cloud’s biggest vulnerabilities are increasingly tied to complexity, process failures, and control-plane mistakes, not just broken infrastructure. In addition to adding redundancy, the next phase of cloud improvement will focus on building systems that are easier to understand, safer to change, and more disciplined to operate.

Under-the-hood AI changes and efficiency improvements at the OS layer across Apple’s platforms are certainly the highlights at WWDC 2026. But there have also been significant changes IT admins will need to prepare for, particularly around Declarative Device Management (DDM). 

The Intel age is over

Apple warned us this was coming, but macOS 27 will not support Intel at all. The company will deliver three more years of security updates for those devices, and you will still be able to use Rosetta to get Intel app binaries to run legacy apps on Apple Silicon. But if you still rely on any Intel apps or Macs, it really is time to plan your upgrade.

DDM becomes the present

It was the future once, but when it comes to Declarative Device Management (DDM) that future is now. Apple is removing all its legacy MDM mechanisms to replace them with DDM. “For IT admins, WWDC 2026 is a migration year,” wrote Fleet. “Apple is removing legacy MDM mechanisms and replacing them with Declarative Device Management (DDM). Some of it is urgent. Some of it just needs a plan.”

It’s a great step, though IT admins will need to ensure they aren’t relying on legacy MDM to handle any of their device fleets. That’s a particular issue around software and security update management. In most cases, your MDM provider has probably already introduced DDM support. But if you aren’t certain, now is the time to find out before your systems fail.

Apple has also added new DDM tools across various systems, apps, identities and more. Some of the highlights include:

• VPN and Network configurations can be provisioned using DDM; they also become credential-reliant, which should make management more streamlined.
• Apple Intelligence, Siri, and keyboard settings can also be configured via DDM, and admins can manage individual Apple Intelligence tools. 
• Web content filter and content caching both become controllable with DDM.
• A new privacy key lets IT manage things like camera or microphone access.
• Apple has added a device system health reporting function to verify that hardware components on iPhone and iPad are genuine.
• IT will be able to detect whether a device is in Lockdown Mode.

“One of the new features I’m most excited about is the ability to set permission defaults for managed apps and websites viewed in Safari,” said Adam Henry, senior product manager at Iru. “While the user is still prompted to allow these permissions, we can now present those requests as a unified prompt immediately upon app launch, along with a custom explanation as to why those permissions are important — think a teleconferencing app or website that always needs access to camera and microphone.

“Overall, I think this is a much more user-friendly solution that will likely increase permission compliance.”

Siri and AI

Although, Apple has introduced new management tools for AI, it’s important to remember some advice from Joel Rennich, senior vice president for product management at JumpCloud: “Traditional IAM models assume users directly interact with applications, but agentic systems change that assumption. AI intermediaries can now retrieve data, execute workflows, and make decisions across systems. Enterprises will need identity frameworks that govern both human and non-human actors consistently.”

He also noted: “The separation between where data lives and where it is used becomes increasingly invisible to the user. Intent becomes the primary input, not app selection.”

At the same time, the evolution of AI on Apple’s devices promises a lot for enterprise users. Matt Vlasach, Jamf senior vice president, enterprise products and solutions engineering, told me: “Most notable for me was Siri AI and the push towards on-device and more capable models that can do more with user context. While obvious for consumer use cases as illustrated in the keynote, the opportunity to evolve this to the work context using a more advanced Apple Intelligence framework is an exciting evolution.”

Farewell AFP

Apple has finally eradicated Apple Filing Protocol (AFP) in macOS. This will be an issue for any business that uses legacy Time Capsule or NAS storage devices, though in most cases those products are already obsolete and should be replaced. This is unlikely to be a huge challenge for most, given that Apple began using SMB as its primary file sharing protocol back in 2013 and support for AFP server disappeared in 2020. (Time Capsule fans might want to take a look at the TimeCapsuleSMB open-source project.)

Hello AppleCare log collection

Apple will introduce a new remote log collection capability that integrates directly with the company’s support infrastructure. So, when AppleCare support engages with an organization’s IT team, they can provide an enhanced logging token which can be shared to get the device to collect diagnostic logs to upload to AppleCare. You just know this will expedite remedy.

Single Sign-On improvements

As I noted here, there are some significant Single Sign-On (SSO) updates; two that caught my eye include:

• IT can now insist on biometric as well as password ID on managed devices.
• Authenticated Guest Mode with Platform SSO allows users to quickly and securely login to a shared Mac in a temporary session.
• Platform SSO on macOS 27 adds web-based authentication.

Network and more

Another change affects the system processes used in device management at a network level. Apple now requires that you use TLS 1.2 or later. If you or your MDM systems are not doing so, get ready for things to break. (Apple has published a support article to help IT test their network environments in preparation for this change.)

Apple also announced that IT admins will be able to purchase and manage app subscriptions directly in Apple School Manager and Apple Business Manager. And it introduced a managed migration feature that should help migrate data, while preserving device management enrollment and settings. 

More information

I’ve really only offered a flavor of some of the IT improvements introduced at WWDC. To find out more, watch the Apple sessions on “What’s new in managing Apple devices” and take a look at the Apple Platform Deployment guide; it should be updated before the new operating systems ship this fall 

You can follow me on social media! Join me on BlueSky,  LinkedIn, Mastodon and subscribe to The Core.

Databricks on Wednesday unveiled OpenSharing, a new open protocol designed to let enterprises share AI models, agent skills, dashboards, and unstructured data across platforms without having to copy or move those assets.

That sharing is made possible by OpenSharing’s zero-copy credential vending model that allows recipients to securely access shared assets directly from a provider’s cloud storage using temporary, scoped credentials rather than requiring the assets themselves to be copied, moved, or replicated, the company wrote on its GitHub page.

Reducing the integration tax of enterprise AI

The ability to share AI assets without creating duplicate copies could help reduce integration complexity, improve governance, and limit the operational overhead associated with operationalizing AI systems across environments for CIOs, said Ashish Chaturvedi, leader of executive research at HFS Research.

“Every organization building AI, such as multi-agentic systems, is hitting the same wall, i.e., the model, the skill, and the consumer reside on three different platforms. The integration tax is enormous, and it grows exponentially with every new partner, customer, or internal team,” Chaturvedi said.

Echoing Chaturvedi, The Futurum Group’s lead of the CIO practice, Dion Hinchcliffe, pointed out that the reduction in operational overhead could help CIOs cut down on the hidden costs of integration around AI deployments: “Today, hidden costs include more than just model development. It is the endless packaging, translation, sync, and governance effort required to operationalize AI assets across organizational boundaries.”

From data sharing to AI asset sharing

That cost reduction is becoming even more important because enterprises are beginning to treat AI assets as business assets that need to be shared, said Stephanie Walter, practice lead of the AI stack at HyperFRAME Research.

“Enterprises are quickly realizing that the value is no longer just in the dataset. It is in the governed context, logic, and intelligence built around the dataset. Existing approaches can share datasets well, but they often do not address the broader AI package,” Walter said.

“OpenSharing is directionally aligned with that shift because it extends the sharing model beyond tables and files toward the artifacts that power AI workflows,” Walter added.

For Hinchcliffe, that alignment should work in CIOs’ favor, trying to operationalize AI across their systems: “CIOs increasingly want AI supply chains, not isolated data lakes like before.”

Additionally, Chaturvedi pointed out that the new protocol can help CIOs accelerate the monetization of AI investments.

“For CIOs, the speed at which you can share AI assets across partners, subsidiaries, and customers determines the speed at which you can monetize your AI investments. If sharing an agent skill takes six weeks of integration work, you’ve lost the window. If it takes a protocol call, you’ve turned AI into a distribution business,” he said.

How OpenSharing could simplify AI development

Achieving those benefits, however, will require developers to move AI assets across disparate platforms more efficiently, and analysts pointed out that OpenSharing’s ability to reduce integration complexity could significantly improve productivity.

“Developer productivity depends on reducing platform translation work. Developers do not want to rebuild the same asset for every consuming environment, and enterprises do not want every partner or customer interaction to become a platform migration conversation,” Walter said.

In fact, Chaturvedi sees the new protocol as unique in the industry, in the specific sense that “no other open protocol covers agent skills and AI models as shareable, governed objects”.

Walter, in contrast, sees the openness of the protocol as novel: “What is more interesting is the combination: an open protocol, cross-platform interoperability, Linux Foundation governance, and a broader asset model that extends beyond datasets into AI models, agent skills, dashboards, applications, and unstructured data.”

“The novelty is not that Databricks invented sharing, zero-copy access, or marketplace-style distribution. Those capabilities already exist in various forms across the market,” Walter said, pointing towards Snowflake’s offerings, such as the Zero-Copy integrations.

The difference, though, the analyst noted, is that Snowflake allows data to be copied only if both provider and receiver are on Snowflake.

With Databricks’ OpenSharing, data can be copied across platforms, Walter added.

OpenSharing, which is an evolution of Databricks’ existing Delta Sharing protocol, is currently a sandbox project under the Linux Foundation AI & Data Foundation and is available via GitHub.

Its current list of generally available connectors includes Python, Apache Spark, Tableau, PowerBI, Snowflake, DuckDB, Clojure, Node.js, Java, Arcurate, Rust, Go, C++, and R.

Other connectors that are expected to be made generally available soon include Google Spreadsheet, Excel, Airflow, and Lakehouse Sharing.

While AI is proliferating across the workplace, it is introducing a new productivity paradox: While the technology makes work feel faster, it actually pushes more burden onto employees to provide context, perform quality checks, then rinse and repeat across numerous disparate tools.

This, according to a new survey of 6,000 full-time digital workers by Glean’s Work AI Institute, results in two emerging behaviors: “botsitting,” all the unrecognized work that goes into making AI actually usable; and “botshitting,” shipping AI-generated work that is unverified, not that well understood, or perhaps not even trustworthy. The survey report was co-authored by experts from Work AI Institute, Emory University, Stanford University, UC Berkeley, UC Santa Barbara, UNC Charlotte, University College London, and University of Notre Dame.

“It’s definitely in many ways a vicious cycle that feeds itself,” said Rebecca Hinds, head of Glean’s research center the Work AI Institute, a research collaborative of AI experts. Enterprises need to begin understanding and addressing the “massive, massive human labor that’s at the core of this.”

Workers are using AI more, getting more frustrated

There’s no doubt that AI is quickly becoming a central teammate in the workplace. Glean’s Work AI Institute found that 87% of digital workers are using AI: It is already automating more than a quarter of their work and saving about 11 hours a week.

Still, only 13% say the use of AI has significantly improved their company’s performance, and their time savings are being eaten up by the same technology that is producing them. Employees lose about one-third of their work week (6.4 hours) botsitting: feeding AI context, supervising outputs, debugging errors, cleaning up AI-generated work, and switching between AI tools.

“We’re seeing high, high rates of multiple tool usage, and often those tools aren’t connected,” said Hinds.

In terms of context-feeding, large language models (LLMs) are trained on the vast corpus of the internet, but not always on enterprise-specific data. Thus, employees often have to provide additional information around their company’s products, customers, services, or other details.

“They’re often feeling frustrated when the tools don’t understand enough about day to day work to be useful,” said Hinds. Also, because employees are using multiple tools, they often have to repeat the same prompt over and over.

“It’s exhausting for workers to not only do this, but to have the work be unrecognized, often unrewarded and unacknowledged within the organization,” she said.

Similarly, workers are having to catch outputs that might look polished and finished on the surface, but could be wrong, incomplete, or missing important context. Debugging is the biggest driver of exhaustion, because it is often conducted by people who didn’t necessarily contribute to the initial output, Hinds noted, so they first have to dig up background information.

However, “not all botsitting is bad,” Hinds emphasized. “Certainly, we want workers to have some level of ownership and oversight.”

But when it is unnecessary, it can lead to botshitting, where users ship AI-generated work they haven’t verified because they’re overwhelmed or time-constrained. Sixty-nine percent of users admit to doing so, and 41% say they sometimes deliver work they could not explain if asked. Another 28% blame AI for mistakes they themselves caused.

“Botshitting is offloading your critical human thinking, judgment, and understanding,” Hinds explained. “You’re offloading that work that absolutely needs to remain with the human.”

Workers using multiple AI agents are significantly more likely to do this, she added, because agents are so scalable, and can spiral out of control if they don’t have the right controls or permissions built around them, causing overwhelmed users to give up on their verification efforts.

“You don’t often see the negative impacts until 3, 4, 5, steps down the line,” said Hinds. “Then it requires all of this cleanup work, detective work, to understand where did the agent go wrong.”

Using AI … but not too much

Interestingly, more than half of the workers surveyed said they get more day-to-day help from AI than they get from their managers, and consider it easier to collaborate with than humans.

Still, they seem to be facing a Goldilocks problem when it comes to sharing their use of AI. Among self-identified high AI achievers, 54% are using unapproved tools or using approved tools in noncompliant ways, and 36% are hiding how much AI helps them.

As Hinds explained, depending on the context and the level of psychological safety an organization has provided, it can be “differentially beneficial or harmful” to show you’re using AI, and, on the flip side, to conceal that you’re using it too much, because that might make you less valuable, or perceived as less valuable, she said.

It’s a complicated balance, because, she noted, “there’s massive pressure in so many organizations to demonstrate AI fluency, to demonstrate you’re a power user.”

What successful organizations are doing differently

In fact, the report said, “The companies pulling ahead are doing something different. They aren’t spending a greater share of their AI time using AI. They’re spending a greater share on the work around it: setting context, defining what ‘good’ looks like, building judgment, and deciding what should never have been handed to a model in the first place.”

The most transformative organizations are addressing AI challenges proactively: Providing training and support, treating AI as an opportunity to redesign work, and formally rewarding AI skills. In addition, it noted, the hardest skill to build is knowing when not to use AI.

It is “not just clicks of the tool, not just tokens used, but real skills, real learning,” said Hinds. In addition to investing in workers, these organizations are clearly stating AI strategy and clarifying the “why” behind it. Governance should also be “living and breathing,” with companies continuously re-evaluating policies.

And it needs to happen at every level, top execs included, said Hinds: “It’s being able to see the executives use the technology, sharing both the success stories and the failures.”

Successful companies are also actively using metrics anchored in existing key performance indicators (KPIs). They are measuring quality, efficiency, and employee engagement in different ways, and putting data in the hands of employees so they can assess their own adoption and success.

“It’s less about surveillance and more about feedback in terms of how we work collectively,” said Hinds.

What’s “fascinating but perhaps not surprising,” she said, is that workers are increasingly using AI itself as a teacher, and prefer it over other learning channels. This speaks to the importance of low-code, no-code tools, with low learning curves and organizational context, that are embedded directly into workflows.

“It is starkly different from what we’ve seen with previous technologies,” she said.

This article originally appeared on CIO.com.

A US federal judge has ruled that the Trump administration’s $100,000 fee on new H-1B visa petitions was unlawful, giving technology companies temporary relief from a policy that threatened to raise the cost of hiring foreign skilled workers.

The decision removes, at least for now, a major cost burden for employers that use the H-1B program to fill roles in domains including software development, cloud computing, data science, and AI.

US District Judge Leo Sorokin in Boston found that the fee functioned as a tax that the administration did not have authority to impose without congressional approval. The ruling came in a lawsuit brought by 20 Democratic state attorneys general challenging the fee.

Standard employer costs for H-1B petitions typically range from about $2,000 to $5,000, making the proposed $100,000 payment a sharp increase for companies seeking foreign talent.

The ruling is unlikely to end uncertainty for employers, with the Trump administration expected to appeal. But it could allow companies that had paused international hiring plans to resume normal recruitment for the upcoming H-1B cycle, said Pareekh Jain, CEO of Pareekh Consulting. Still, he said, employers should remain cautious because the legal and policy concerns are likely to continue.

“This provides breathing room for CIOs, even though it’s temporary,” said Neil Shah, vice president for research and partner at Counterpoint Research. “They should make the necessary contingency plans, whether that means doing more with less by leveraging AI or relying more on local talent.”

How companies may rethink hiring

If higher H-1B costs return in another form, CIOs will have to be more selective about sponsorship, weighing the added cost against the strategic value of the role and the long-term potential of the employee, Shah said.

“Ultimately, the decision comes down to business unit P&L: whether the unit can absorb the cost of acquiring the talent for that role,” Shah added.

That uncertainty could also lead CIOs to compete for talent from other companies, potentially driving up salaries for skilled workers. Some CIOs may conclude that paying a one-time $100,000 fee, amortized over the employee’s tenure, is still more cost-effective than engaging in a bidding war for scarce local talent.

Danish Faruqui, CEO of Fab Economics, said that CIOs may reserve H-1B sponsorship for a narrower set of mission-critical roles if costs increase.

“If there is such a financial burden, CIOs will justify sponsoring very specific roles,” Faruqui said. “These would be principal enterprise architects, AI, ML, and deep-tech researchers, senior product managers, and regulatory and compliance experts.”

More routine or project-based roles are likely to be treated differently, Faruqui said.

“Junior to mid-level software engineers, entry-level business analysts, and entry-level data scientists would shift from H-1B to domestic hiring,” Faruqui said. “Cloud migration, DevOps, ERP, and CRM implementation could be done through contractors or consulting firms, while QA, product testing, tier-one help desk support, and legacy maintenance are roles that CIOs could prioritize for automation.”

Who would be most affected?

Startups, smaller companies, and enterprise IT departments would have faced the greatest pressure from the fee and stand to benefit most from the ruling, Jain said.

Large technology companies would have been better placed to absorb the $100,000 cost, he said. Meanwhile, companies with mature offshore delivery models may be less likely to increase their reliance on H-1B hiring.

The article originally appeared on CIO.